In my last post, I advised that having CI/CD automation is very important to drive frequent and reliable releases, however, it is not a sufficient process or steps to establish responsible releases. When you’re making a production release of an application or service, it requires communication, additional testing, documentation, and other steps that go beyond the scope of what continuous integration and deployment automate.

My next three posts, including this one, will home in on improving deployment frequencies. This one will cover several business and technical prerequisites. The next post will cover seven required DevOps practices before increasing deployment frequencies, and the final one will provide guidelines on how frequently you should really deploy code.

Prerequisites before improving deployment frequencies

Let’s first make sure we agree on some prerequisites before considering whether improving the frequency of deployment is needed or a good idea. Here are seven considerations that you should evaluate:

1. Business stakeholders actually want you to improve release frequency. Perhaps they don’t! Maybe a release every two months is good enough and improving this DevOps KPI is not a high priority. Maybe there are other more critical agile or DevOps practices areas to focus on?
2. A modular architecture in place with only a few, manageable, and testable dependencies between systems. If this is not the case, you should be looking to address technical debt in your architecture before hitting the gas pedal.
3. A firm understanding of the risks is in place. CI/CD is just one DevOps best practice! And most importantly, CI/CD represents the happy path for when everything works right! Have development and operations teams discussed and engineered a process that defines a “successful release” versus one that requires rollback?
4. There’s confidence in the testing strategy, coverage, and automation. This needs repeating because having automated deployments with CI/CD but without continuous testing is not sufficient if your goal is to improve the frequency of deployments.
5. Mature agile management and DevOps tools are in place. Trying to go faster when tools are not in place or are in the early stage of maturity is a recipe for driving without control. Tools for agile tracking development, version control, CI/CD, IaC, and incident management all need to be instituted with reasonable maturity and integration.
6. There’s active collaboration between business, development, and operational teams regardless of the organizational model in place. Most importantly, you have a defined process for who does what when something goes wrong, and there isn’t a culture of blame when there are failures.
7. A defined deployment communication protocol is in place. If you’re going to deploy frequently, you must inform customers, stakeholders, and end-users on what’s going out when and have a defined process to capture feedback or problem escalations.

Use this as a checklist. My next post will go deeper into the DevOps technical practices that are foundational to improve deployment frequency.