diff options
| author | Franck Cuny <franckcuny@gmail.com> | 2016-07-02 20:06:31 -0700 |
|---|---|---|
| committer | Franck Cuny <franckcuny@gmail.com> | 2016-07-02 20:06:31 -0700 |
| commit | 4b8e43f75b394a4e6169884fbfb4c606865c6a22 (patch) | |
| tree | 48cae6b8e8f9b68cae29676d8a15cb3ddbfcccda /content/post/2015-08-22-deployment-on-friday.md | |
| parent | Stop using Jekyll. (diff) | |
| download | lumberjaph-4b8e43f75b394a4e6169884fbfb4c606865c6a22.tar.gz | |
Import migration from Jekyll to Hugo.
All the posts were converted, and the layout is created. This looks like
it works just fine.
Diffstat (limited to '')
| -rw-r--r-- | content/post/2015-08-22-deployment-on-friday.md | 36 |
1 files changed, 36 insertions, 0 deletions
diff --git a/content/post/2015-08-22-deployment-on-friday.md b/content/post/2015-08-22-deployment-on-friday.md new file mode 100644 index 0000000..eba7786 --- /dev/null +++ b/content/post/2015-08-22-deployment-on-friday.md @@ -0,0 +1,36 @@ +--- +date: 2015-08-22T00:00:00Z +summary: In which we deploy our code on a Friday afternoon. +title: Deploying to production on a Friday +--- + +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. |