If you’ve got continuous deployment, you’ve got stable servers. You make big
changes in small increments.

Continuous deployment forces you to do many good things:

Good tests.

Repeatable build.

Well-configured identical machines.

Automated deployment.

Migrations and rollbacks

Etc.

Lots of good things. But let’s compare it with lion taming.

Originally, lions were beaten into submission, confused and kept in line with
whips. Likewise you’ll be beaten if you dare to touch the production machine
as it might break.

Now lions are understood better. Conditioning, behavior/signal mapping, reward
and trust are the methods now. We understand that deployment is hard. We have
behaviour/signal mapping with code/test/green/deploy. Etc.

Continuous deployment: everyone is responsible. Everyone deploys. You
automatically learn. Everybody uses the same environment locally for test
deployments. The same as on the server.

Testing is core. Slow tests are killing. Fast tests. And all types of tests:
unit, functional and acceptance tests. Also automatic code checkers. The light
must stay green. Quality must stay high, also test quality.

You need a repeatable build. And it should include not just code, but also
configuration and infrastructure. And… always follow the pipeline.

Even in emergencies, follow the pipeline. Peer review, tests, and then the
deployment. Don’t do manual steps.

Rollback. You must be able to switch back to the previous version.

You can take a canary approach. Canary in the coalmine. Show the new version
to a few users. “User testing” in a sense.

Rollbacks in databases; keep it backwards compatible. Never drop columns,
for instance. (After a long time, you can remove them safely, of course).

Small changes. Frequent releases mean less risk: if something breaks, you
know where to search.

Some tips:

Split your stuff in components. A component is something that has a good API
and that can be switched out for a different component. It can also be
separately deployed.

This helps with testing, too.

Rehearse releases. Get very good at them!

You need good infrastructure. You must manage it and test it good.

Keep all environments equal. Use vagrant.

Automate everything! And if it is not possible: document it. But know that
that’s something that’s not quite correct yet!