Continuous Deployment is the best!
Continuous Deployment je nejlepší! A short and highly opinionated talk. Proceed with caution: I think almost every team should ship to production on every push.
Deployment vs delivery
Continuous deployment means you deploy the application to production just by pushing to source control. Nothing else. Continuous delivery is the same pipeline with one extra manual step at the end: somebody has to push the button.
When to go with CD?
Always. That was the whole slide.
It doesn’t matter how you deploy. It works with FTP, with sending the source code as a zip over e-mail, GitHub Pages, static pages served from a CDN, serverless, Docker and Docker Compose, Kubernetes, multicloud. The exceptions are mobile and desktop apps, where a store or an installer sits between you and the user.
So why is CD so cool?
Midnight party deployments with confidence. I showed photos from a party on a bus to make the point: when deploying is boring and safe, you can do it at any time, even at midnight in the middle of a party.
The serious list:
- Higher effectiveness and productivity. It saves developers’ time by making processes simpler.
- A shorter feedback loop. I compared two companies: in one, the response to a change took a year, in the other a day.
- It forces best practices on developers: small commits, tests, checking your own work, ownership. It turns people into dream team members.
- Fewer git conflicts.
- Your brain will love you for smaller and faster tasks.
- Imagine being a developer whose code gets deployed 30 days after they wrote it. WTF.
- It’s highly addictive.
One warning, though. CD is not a miracle pill. It can’t fix all your problems and ineffective processes. CD is more about processes than about tooling.
Excuses vs solutions
These are the excuses I hear most often:
- No time to implement something as complicated as CD.
- We don’t know how to implement CD.
- Fear of bugs appearing on production.
- Fear of downtime.
- Fear of losing control over deployments.
- We would lose the overview of what is deployed and when.
- Manual deployment is faster.
- It’s a waste, we are a team of two developers.
- I deploy over FTP, why would I need CD?
- We do “agile”, we release once every 30 days.
- Our features are so complex that we can’t deploy them immediately.
- Management doesn’t want CD (a political decision).
Tooling, the helping hand
Most of the fears above have a known answer:
- A test suite in CI. Obviously.
- Feature flags, for example Flagsmith. Unfinished or complex features can be deployed switched off and turned on later.
- Review apps: a running copy of the app for every branch, so changes get checked before they are merged.
- API versioning, to stay backward compatible with clients.
- Backward and forward compatible database migrations, so the old and the new version of the code both work with the database during a deploy.
- Deployment freezes for the moments when you really don’t want anything to change.
- Error tracking, for example Sentry, so you see a bug from production before your users report it.
And one hint to finish: don’t lock deployment to CI only. Keep a way to deploy without it, or one day you’ll be standing outside the car with the keys inside.
There is no recording of this talk.
