"Nobody touch production – I'm about to release!"
That phrase may be familiar to you. Deploying to production can be a risky and costly exercise that sometimes requires putting all development on hold. This causes release cycles to be slow and changes to stagnate in the development environment. It's the start of an awkward (and vicious) circle in which the more commits are made to the repository, the more risks get introduced into the next deployment to production, and the less likely your team is to make that release.
- Releases become smaller and easier to understand.
- No one is required to drop their work to make a deployment because everything is automated.
- The feedback loop with your customers is faster: new features and improvements go straight to production when they're ready.
Continuous deployment vs. continuous delivery
If you want to implement a continuous deployment pipeline, the best place to start with continuous delivery. These two practices are similar, but differ in their approaches to production deploys. In continuous delivery, every change pushed to the main repository is ready to be shipped, but the production release process still requires human approval. In continuous deployment, the release to production is done automatically for every change that passes the test suite.
Before you start shipping changes automatically to production, you'll need to have a good continuous integration (CI) culture, and it's highly recommended to start with continuous delivery first. You can read more about the two practices in the articles below:
Moving from continuous delivery to continuous deployment
Emphasize a culture of continuous integration
継続的デプロイの中核にあるのは偉大な CI 文化です。テストスイートの品質がリリースのリスクレベルを決定し、チームは開発工程においてテストの自動化を最優先に行う必要があります。これは、リリース後に発見されたリグレッションに対する追加テストに加え、すべての新規機能にテストを実装することを意味します。
Fixing a broken build for the main branch should also be first on the list. Otherwise, you'll be exposing yourself to the same risks you faced prior to adopting continuous deployment: changes are accumulated in the development environment, and developers can't be sure that their work is finished as they don't know if their changes passed the acceptance tests.
Make sure you have good test coverage (and good tests too!)
Start using test coverage tools to make sure that your application is adequately tested. A good goal is to aim for 80% coverage.
Be careful not to mistake good coverage for good testing. You could have 100% test coverage with tests that don't really challenge your codebase. Make sure to spend time during code reviews to check how tests are written and don't hesitate to point out gaps in coverage or weak tests. Your test suite acts as the gate to production – make it a strong one.
Adopt real-time monitoring
すべてのコミットを自動的に本番環境にデプロイするなら、問題が発生したときに警告を発信してくれる優れた仕組みが必要です。新しい変更がすぐに本番環境を壊さなかったとしても、それが CPU やメモリー消費を危険なレベルに引き上げる原因となる場合があります。そのため、本番環境のサーバーにリアルタイム監視機能を実装すると、指標の異常を追跡することができて便利です。
Make sure that these tests do more than just hitting a static page, waiting for a success response. It's good practice to have a test that requires that all your production services (database, micro-services, 3rd parties...) are working properly.
Get your QA team to work upstream
As every commit goes now straight to production, it means that there's no traditional buffer for your QA to review and approve new features. Instead, they should be working closely with the product manager and the development team to define the risks associated with new improvements.
This is a great opportunity for the QA team as it will result over time in better quality for the releases. With continuous deployment, your team will be naturally inclined to have good test coverage of the codebase. Failing to do so means frequent disruptions due to bugs slipping out to production where they're discovered by your users.
Drop the traditional release notes
Continuous deployment makes it hard for you to keep up with releases – and that's a good thing! Your goal should be to have daily deployments to production, even multiple deployments per day. It may be bug fixes, small improvements, new features... whatever. As soon as a developer finishes their work, that work should be running in production in a matter of minutes.
In this new world it's no longer possible to write release notes that get sent to your customers with each new version. Instead, embrace this new flow and limit your announcements to key features that matter to your customers. Bug reports and small improvement requests can simply be handled in your ticketing system – JIRA, for instance, can update all watchers of a ticket as soon as you close or update it.
A different approach for new projects: deploy to production before coding
There's something interesting that you can do if you're getting started on a brand new codebase. You can start by creating your continuous deployment pipeline before having any customers and any feature ready (not unlike test-driven development). At the beginning, you'll be shipping an empty platform. Then, as development progresses, new capabilities will start appearing automatically. You just need to keep your production environment closed until you're ready to open it up for your customers.
This approach may seem counter-intuitive at first. But it's an easy way to take the stress out of going from a manual release approval to continuously deploying to production. It's also an excellent way to make sure that you have a good test coverage and continuous integration culture at launch since they necessary conditions for continuous deployment.
It's understandably hard to take the leap and switch to continuous deployment. All of a sudden the gates are lifted, and code goes straight to the customers in a matter of minutes or hours. (Eep!) So it's important to invest in the tests and automations that give you confidence in your builds. This will be easy if your codebase is new, but it may require adopting a different strategy for a complex ledgacy codebase.
Start small and build up your continuous deployment knowledge and experience. Once you get there for one project, it will be easy to replicate your success in other parts of your organization.