Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Continuous Deployment at
Gozengo
How we implemented CD as a culture from our inception
Daniel Straus
Director of QA
Linked...
Overview
 What is Gozengo?
 Why Continuous Deployment?
 Getting Buy In
 Challenges to Implementation
 Why Selenium We...
What is Gozengo
 An online vacation shopping site
 We sell hotel and vacation packages
 Currently we offer trips to are...
Our Tech Team
 Currently about 12 Devs
 3 QA engineers
 4 Ops
So why Continuous
Deployment?
 I started 3 months into Gozengo
 No product at that point
 CD was a decision we made bec...
So how does it all work?
 Github
 Devs work in branches and create pull requests
 All PRs are reviewed by at least 1 ot...
So how does it all work? (Part
2)
 Selenium. Why?
 Well supported with a large community
 Supports numerous languages (...
CDing Ain’t Easy
 Launching builds
 To start only 1 dev held the keys. Not very scalable.
 Any dev should be able to de...
CDing Ain’t Easy (cont’d)
 Dev testing responsibility
 Devs write code but what should they test?
 Unit testing is key
...
CDing Ain’t Easy (cont’d)
 What to test
 Test everything?????
 Critical Path
 Who writes the Selenium tests and why?
...
Workflow
Pull
Request
PR
Appro
ved?
Deploy to
Staging using
Hubot
The above PR
approval
process
includes
1. Unit tests
add...
Deploying to Staging
Queue – Devs get in line when. To try and keep the
queue moving as quickly as possible CP must run un...
DEMO
Example Test Output
ENVIRONMENT=staging_customer WHICH_BROWSER=chrome rspec
landing_page_b2c/footer_links_spec.rb --format...
Getting to Prod
Deploy to
Staging
Run Regression
tests (Critical
Path) via
Jenkins/SauceL
abs)
CP
Passed
?
All existing
fu...
The Future
 Mobile Web (Appium)
 Native Applications (Appium)
 Visual Diff Testing (Applitools)
 Improve the Queuing s...
How Gozengo Implemented a Continuous Deployment Culture from Day One
Upcoming SlideShare
Loading in …5
×

How Gozengo Implemented a Continuous Deployment Culture from Day One

651 views

Published on

A case study in setting up a Continuous Deployment process and culture at Gozengo, a small startup, and how they made the decision to implement Continuous Deployment from day one and what they learned along the way.

Published in: Engineering
  • Be the first to comment

How Gozengo Implemented a Continuous Deployment Culture from Day One

  1. 1. Continuous Deployment at Gozengo How we implemented CD as a culture from our inception Daniel Straus Director of QA Linkedin: https://www.linkedin.com/pub/daniel- straus/3/300/8b2
  2. 2. Overview  What is Gozengo?  Why Continuous Deployment?  Getting Buy In  Challenges to Implementation  Why Selenium WebDriver?  Ruby/Rpsec/Page Objects  Jenkins/Saucelabs  How it works  Demo  Code Example  The future
  3. 3. What is Gozengo  An online vacation shopping site  We sell hotel and vacation packages  Currently we offer trips to areas in the Caribbean with more destinations around the world to come.
  4. 4. Our Tech Team  Currently about 12 Devs  3 QA engineers  4 Ops
  5. 5. So why Continuous Deployment?  I started 3 months into Gozengo  No product at that point  CD was a decision we made because:  Would gets us into the habit of working and pushing code quickly (make it the culture).  Would make Devs more responsible for checking their stuff at earlier stages (unit tests, spot checks on local environments, cross browser checks)  Would allow us to be more Agile in our development process (Design, Dev, QA and on to “Prod” quickly so we could iterate).  Every change would be checked so if something breaks it would be easier to track down the source of the breakage and revert or fix quickly.
  6. 6. So how does it all work?  Github  Devs work in branches and create pull requests  All PRs are reviewed by at least 1 other Dev. Items checked for in the PRs  Correctness  Testability  Unit Tests (where applicable)  Feature Flags (where applicable)
  7. 7. So how does it all work? (Part 2)  Selenium. Why?  Well supported with a large community  Supports numerous languages (Ruby, Java, Python, etc)  Supports most browsers (Safari, FF, Chrome, IE, Safari, etc)  Works on Mac, Windows and Linux  SauceLabs  Automation framework - Ruby/Rspec/Page Objects  Use the Selenium Ruby bindings  Rspec – Make for really nice English readable test which are self documenting  Page Objects – Easier code maintainability  CI/CD Server - Jenkins  Manage all our builds/tests  Allows for parallelism (speeds up testing)  Works seamlessly with Saucelabs
  8. 8. CDing Ain’t Easy  Launching builds  To start only 1 dev held the keys. Not very scalable.  Any dev should be able to deploy but how?  Initial solution was a simply shell script that deploys code to a box. Ok but kind of a pain as you had to:  SSH to box  Become a specific user  Run script  Make sure build worked and if it did not investigate why via the console.  Improvements - Worked with Dev team to implement Hubot (https://hubot.github.com/) for deploys via our hipchat client.
  9. 9. CDing Ain’t Easy (cont’d)  Dev testing responsibility  Devs write code but what should they test?  Unit testing is key  Dealing with 3rd party dependencies (Mocks away)  FE devs need to check stuff cross browser  Where to test  Since FE devs need to test cross browser how do we give them access to all versions we support? Saucelabs!  Sandbox environments  Stand alone environments that devs can push local code to  Has a copy of the staging DB (refreshed every evening)  Allows for incremental testing and updating of tests prior to merging code.
  10. 10. CDing Ain’t Easy (cont’d)  What to test  Test everything?????  Critical Path  Who writes the Selenium tests and why?  QA  Centralized ownership  Devs can concentrate on writing code/unit tests  QA has a better understanding of the application as a whole  Write the tests in a way that makes it easy for the Devs to work with if updates are needed (DSL).
  11. 11. Workflow Pull Request PR Appro ved? Deploy to Staging using Hubot The above PR approval process includes 1. Unit tests added 2. All existing unit tests passing. 3. Feature flag created (if needed) Run Regression tests (Critical Path) via Jenkins/SauceL abs)
  12. 12. Deploying to Staging Queue – Devs get in line when. To try and keep the queue moving as quickly as possible CP must run under 8 mins. Devs can agree to push 2 or 3 PRs at one time but one Dev must take ownership of the deploy (with the other Devs available if needed).
  13. 13. DEMO
  14. 14. Example Test Output ENVIRONMENT=staging_customer WHICH_BROWSER=chrome rspec landing_page_b2c/footer_links_spec.rb --format documentation Footer Links Visit footer links Should display landing page if 'Gozengo.com' is clicked Should display about page if 'About' is clicked Should display privacy policy page when 'Privacy Policy' is clicked Should display Terms and Conditions page when 'Terms and Conditions is clicked Should display Contact page when 'Contact' is clicked Email Sign-Up Should display the Email Sign-up page when 'Email Sign-Up' is 404 page Should take the user the 404 page
  15. 15. Getting to Prod Deploy to Staging Run Regression tests (Critical Path) via Jenkins/SauceL abs) CP Passed ? All existing functionality is working properly and new features are turned off behind a feature flag. Deploy to Prod using Hubot
  16. 16. The Future  Mobile Web (Appium)  Native Applications (Appium)  Visual Diff Testing (Applitools)  Improve the Queuing system  Always refining the process (not 1 size fits all)

×