diff options
| author | Franck Cuny <franck.cuny@gmail.com> | 2016-08-10 14:33:04 -0700 |
|---|---|---|
| committer | Franck Cuny <franck.cuny@gmail.com> | 2016-08-10 20:17:56 -0700 |
| commit | 8d7d02f42c3947f756c18cb4d37d9d97fbd0d27d (patch) | |
| tree | a6cecddaaea7e87d901a6c28bebe3a531438f24b /posts/2015-08-22-deployment-on-friday.org | |
| parent | Merge branch 'convert-to-org' (diff) | |
| download | lumberjaph-8d7d02f42c3947f756c18cb4d37d9d97fbd0d27d.tar.gz | |
convert back to md
Diffstat (limited to '')
| -rw-r--r-- | posts/2015-08-22-deployment-on-friday.org | 36 |
1 files changed, 0 insertions, 36 deletions
diff --git a/posts/2015-08-22-deployment-on-friday.org b/posts/2015-08-22-deployment-on-friday.org deleted file mode 100644 index e3a5691..0000000 --- a/posts/2015-08-22-deployment-on-friday.org +++ /dev/null @@ -1,36 +0,0 @@ -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. |