Having CI/CD pipelines doesn’t mean that continuous delivery is a business need or a good idea. I wrote about this a couple of years ago when I asked, “Is Continuous Delivery Right for Your Business?”

I know this is a debated topic. Yes, you can use feature flags or branching strategies to enable very frequent releases with controls that block new code from impacting customers. Yes, smaller releases are generally lower risk than larger ones. And yes, given two extremes, customers and end-users generally prefer more frequent releases and not waiting eons for improvements and bug fixes.

Bare with me and let’s leave the debate aside.

This post is not about how often and frequent you deploy but about the disciplines tied to responsible deployments.

Deployment is Greater than a Code Push

CI/CD addresses the integration, deployment, and hopefully, the continuous testing that Dev, Ops, and QA teams automate. It removes the very long, error-prone checklists Dev teams used to write (sometimes more/better than others) and that Ops teams once executed manually (sometimes flawlessly, but painful when steps were missed). In addition, over the last decade, many more development and testing teams developed automated testing and integrated continuous testing into the CI/CD pipelines.

All good, important stuff!

But not sufficient for pushing the green button to deploy! Agile planning releases must do a lot more than pushing features and code out. Here are five pre-deployment things to do before hitting the green button:

1. Evaluate risk and develop a remediation strategy – Happy paths are great, but having risks outlined and a remediation plan to go with it is prudent planning
2. Finalize ready-for-release testing and documentation – Not all testing can easily be automated. UAT? All aspects of security testing? And what documentation is needed before the release is truly done?
3. Develop your communications – This is often a product owner’s responsibility. Still, communicating release versions, features released, defects addressed to customers, end-users, and stakeholders should be part of the deployment plan.
4. Monitor and report on business and technical impact – A release doesn’t end when the code is deployed, and it’s important to capture customer feedback and usage data. Define who is capturing what data and when they are reporting the learnings and insights before hitting the green button.
5. Assess new technical debt – All releases introduce some form of technical debt. Capture this detail in the backlog before making the release. If a release introduces significant debt, then maybe it’s not ready to go to production.