How might a product owner support a continuous delivery pipeline that fully automates deployments with no compliance steps?

What is Continuous Deployment?

Part of being agile is the ability to react quickly and efficiently, particularly when it comes to software development.

Continuous deployment and continuous delivery are two terms that are seen so often together that they may be used interchangeably and so there’s much confusion between them. They both refer to how features are released to production.

There is, however, a major difference between the two. With continuous delivery, someone will need to approve the release of the feature to production but with continuous deployment, this process happens automatically upon passing automated testing. 

Continuous deployment is basically when teams rely on a fully-automated pipeline. This practice fully eliminates any manual steps and automates the entire process. Therefore, continuous deployment ensures that code is continuously being pushed into production. 

Real-time monitoring, however, would still be needed to track and address any issues that arise during the automated tests and to ensure that the builds passed these tests. 

CI/CD and CD process

Continuous deployment is part of a continuous process. The first step starts with continuous integration when developers merge their changes into the trunk or mainline on a frequent basis. This helps teams evade what is known as ‘merge hell’, which happens when developers attempt to merge several separate branches to the shared trunk on a less regular basis. 

Then comes continuous delivery when code is deployed to a testing or production environment. Here, developers’ changes are uploaded to a repository, where they are then deployed to a production environment. With continuous delivery, you can decide to release daily, weekly or monthly but it is usually recommended to release as often as possible in small batches to be able to easily and quickly fix any issue that arises.

Continuous deployment goes one step further and combines continuous integration and continuous delivery to make software automatically available to users without any human intervention. Hence, continuous deployment requires the complete automation of all deployments and so refers to the process of automatically releasing developers’ changes from the repository to production, bypassing the need for developer approval for each release. Consequently, this process relies heavily on well-designed test automation.

All these practices come together to facilitate and accelerate releases making deployment less risky.

Benefits of Continuous Deployment

In this sense, continuous deployment accelerates releases to market and it also quickens the feedback process with both developers and customers. The work of developers goes live almost immediately after they’ve finished working on it. This way, developers can respond to such feedback in real-time and immediately respond to any bug reports or if they want to test a new idea, they can quickly deploy and validate new features.

Continuous deployment also takes away release day pressureso developers’ sole focus is on building the software, which automatically goes live in a matter of minutes.

It also heightens productivity and allows developers to respond to rapidly shifting market demands.

Continuous deployment, however, requires a high degree of monitoring and maintenance to ensure it continues to run smoothly as well as a great capacity to respond to changes quickly.

Features flags and continuous deployment

We can conclude that teams practicing continuous deployment need to be very thorough in their automated test practices as all releases are happening automatically without prior approval. Therefore, any bugs that manage to bypass these tests will make their way to your end-users.

This issue can be solved through the use of feature flags as they add a layer of safety to the continuous deployment process. A kill switch can be placed on each feature so any bugs detected don’t need to be rolled back but instead you just switch off the feature toggle. This way, the parts of the feature that are not working as they should are not exposed to your users while the rest of the changes to the feature can be released without the need for rollbacks.

Quick review

In summary:

• Continuous integration (CI):integrate changes to a shared trunk several times a day.
• Continuous delivery (CD): continuous integration then deploy all code changes to production environment; deployment is manual.
• Continuous deployment (CD): step further from continuous delivery; automated deployment to production without any need for developer approval.

CI/CD, then, can be taken to refer to the connectedness of the continuous integration and delivery processes or it can even refer to all three practices of continuous integration, continuous delivery and continuous deployment.

In the end, what’s important to remember is CI/CD, visualized as a pipeline, automates the software delivery process by building code, running tests and deploying this code to a live production environment.

Info

How might a product owner support a continuous delivery pipeline that fully automates deployments with no?

Which two aspects of the continuous delivery pipeline require the most involvement from product owners?

How do you automate a continuous delivery pipeline?

How does SAFe continuous delivery pipeline enable?