-
Notifications
You must be signed in to change notification settings - Fork 0
Continuous Deployment Workflow
This section may have more to do with our internal processes, but I'm including it here now until we find a better spot for it.
Much of this is pulled from this fantastic presentation from the Envato team: 10 Deploys a Day - A Case Study of Continuous Delivery at Envato - January 2014
It's all about distributed collaboration vs central control.
Our process:_ Pull work > Consult product team > Write code > Test code > Deploy code > Verify production Repeat ... about twice a week per developer.
Thanks to feature toggles (flippers), we Always Deploy It.
Everybody knows what's happening without having to ask. All automated processes feed automated notifications to a centralized IRC channel (or equivalent) — which is also where the team converses.
Things can break ... and do. Require multiple quality checkpoints throughout pipeline and make it easy to rollback.
You build it you run it. Each developer is responsible for ongoing quality assurance for code they produce.
Fail Fast and Loud
Now, in a bit more detail. This process follows GitHub Flow, and is a marked departure from the previous Git-flow process we used on AskNature 1.x:
- Start with the user story
- Flip or no flip? (feature toggles)
- Goal to flip everything
- Create a branch off master
- Write failing test
- This is critical (and something that's been lackluster to date)!!
- Write/edit code
- Run local tests
- Run full personal build
- Create pull request
- Github Pull Request
- This can be done long before branch is ready to be merged
- Advertise pull request
- Currently requests are automatically advertised via a Slack integration
- Optional: invite/assign reviewers
- Mandatory: summarize user story and how it's solved
- Mandatory: indicate whether pull request is ready to be merged
- Wait for code review
- Merge pull request (with master)
- Full master build green
- Notify team
- Deploy master to production
- this happens automatically via a Jenkins integration
- Watch system-monitoring tools
- system monitoring tools have not been identified or set up yet
- Rollback if failed
- Rinse and repeat
Optional:
- Deploy to staging
- Scott H. has set this up somewhere (docs?)
- Show product owner
- Manual test
What we do not do:
- No - testing role or formal (manual) testing gate
- Requires 1000s of automated tests
- Use production users as test team
- Feature toggles help control rollout
- No - change control gate
- Everyone knows of changes before they happen because they review them as pull requests
- Green build = sign off
- Developers have skin in the game so they are incentivized for code to work.
- Small changes are easier to identify and rollback when things go wrong.
- No - formal communication of every change
- Informal and/or automated communication instead
- No - release management
- Small releases don't require extra definition or documentation.
- Instead, commit messages that radiate through IRC (or equivalent).
- No - Separate deployment team or process
- No - Separate operations team
Version Control GitHub. Nuff said.
Continuous Integration Server We use Jenkins CI on a dedicated DigitalOcean Droplet for automated testing and deployment, but may switch to a hosted service like Codeship or CircleCI.
Feature Toggles We are considering options that feature powerful options and a GUI, such as OpenTable's Hobknob.
Local Testing & Building We use Mocha for local asynchronous testing, and may augment it with Chai Assertion Library.
Local Task Automation We use Grunt to automate tasks like builds, tests, and server activities.
Centralized Updates Consider an installation of Hubot on Heroku or our testing server so we can have a centralized activity feed.
Continuous Deployment of Node.js Applications - October 2014
10 Deploys a Day - A Case Study of Continuous Delivery at Envato - January 2014