diff options
| author | Franck Cuny <franckcuny@gmail.com> | 2016-08-04 11:45:44 -0700 |
|---|---|---|
| committer | Franck Cuny <franckcuny@gmail.com> | 2016-08-04 11:45:44 -0700 |
| commit | 585b48b6a605cb71ef99dd767880e1b7ee5bf24e (patch) | |
| tree | c65377350d12bd1e62e0bdd58458c1044541c27b /posts/2015-08-22-deployment-on-friday.org | |
| parent | Use Bullet list for the index. (diff) | |
| parent | Mass convert all posts from markdown to org. (diff) | |
| download | lumberjaph-585b48b6a605cb71ef99dd767880e1b7ee5bf24e.tar.gz | |
Merge branch 'convert-to-org'
Diffstat (limited to 'posts/2015-08-22-deployment-on-friday.org')
| -rw-r--r-- | posts/2015-08-22-deployment-on-friday.org | 36 |
1 files changed, 36 insertions, 0 deletions
diff --git a/posts/2015-08-22-deployment-on-friday.org b/posts/2015-08-22-deployment-on-friday.org new file mode 100644 index 0000000..e3a5691 --- /dev/null +++ b/posts/2015-08-22-deployment-on-friday.org @@ -0,0 +1,36 @@ +There's a lot of reasons to not deploy code to production on a Friday. +If something goes wrong, you might end up spending your Friday night, or +worst, your entire weekend, fixing some issue. But there's no reasons +Friday should be different from any other day. It's not OK to spend a +night during the week fixing an issue in production. + +To be in a place where you can deploy code at any time requires a few +things: tools, automation and culture. + +In my team, every body is on call: SWEs and SREs. We all share the same +responsibilities. There's no rule saying that deploying on Friday is +forbidden. We don't do continuous deployment, and we also don't have a +schedule saying which days of the week we deploy. + +Artifacts are build by our build system and pushed to some archives. We +don't deploy artifacts that we build on a developer laptop. + +Before deploying an artifact to production, we usually run it as a a +canary on some shards. Depending of the service, it can be for a few +hours up to a couple of weeks. Once we are confident in this artifact, +after reviewing our dashboards, we know it's going to be safe to deploy +it. + +We communicate with the team (and outside the team) before doing a +deployment. A deploy starts with a ticket in Jira, saying what we are +going to deploy, how long it will take, and what are the steps to +validate, and do a rollback. At least one another person need to review +the ticket and give his consent. If that person has some concerns, the +deploy is pushed back, and we figure out what's wrong. On-call has to +ACK the procedure before starting too. + +Our deployments are hooked with our alerts. If something goes wrong, the +deployment is paused, or roll backed. + +Once it becomes easy to build test deploy and rollback, then there's no +reasons to not deploy code on Friday. |
