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.
How Gozengo Implemented a Continuous Deployment Culture from Day One
Continuous Deployment at
How we implemented CD as a culture from our inception
Director of QA
What is Gozengo?
Why Continuous Deployment?
Getting Buy In
Challenges to Implementation
Why Selenium WebDriver?
How it works
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.
Our Tech Team
Currently about 12 Devs
3 QA engineers
So why Continuous
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
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
So how does it all work?
Devs work in branches and create pull requests
All PRs are reviewed by at least 1 other Dev. Items
checked for in the PRs
Unit Tests (where applicable)
Feature Flags (where applicable)
So how does it all work? (Part
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
Automation framework - Ruby/Rspec/Page Objects
Use the Selenium Ruby bindings
Rspec – Make for really nice English readable test which are self
Page Objects – Easier code maintainability
CI/CD Server - Jenkins
Manage all our builds/tests
Allows for parallelism (speeds up testing)
Works seamlessly with Saucelabs
CDing Ain’t Easy
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
Make sure build worked and if it did not investigate why via
Improvements - Worked with Dev team to implement
Hubot (https://hubot.github.com/) for deploys via our
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!
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
CDing Ain’t Easy (cont’d)
What to test
Who writes the Selenium tests and why?
Devs can concentrate on writing code/unit tests
QA has a better understanding of the application as a
Write the tests in a way that makes it easy for the Devs to
work with if updates are needed (DSL).
The above PR
1. Unit tests
2. All existing
3. Feature flag
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).
Example Test Output
ENVIRONMENT=staging_customer WHICH_BROWSER=chrome rspec
landing_page_b2c/footer_links_spec.rb --format documentation
Visit footer links
Should display landing page if 'Gozengo.com' is clicked
Should display about page if 'About' is clicked
Should display Terms and Conditions page when 'Terms and
Conditions is clicked
Should display Contact page when 'Contact' is clicked
Should display the Email Sign-up page when 'Email Sign-Up' is
Should take the user the 404 page
Getting to Prod
and new features
are turned off
behind a feature
Mobile Web (Appium)
Native Applications (Appium)
Visual Diff Testing (Applitools)
Improve the Queuing system
Always refining the process (not 1 size fits all)