Principles and practices of Continuous Delivery

Every developer has experienced, at least once in his or her life, that feeling of tension on the Delivery Day. Being aware of the pitfalls of software development, developers are afraid of emerging defects, inconsistencies, and malfunctions while using it.

Are we really confident that this is the way? Can we overcome the fear of deployment by turning every day in a D-day? Yes, we can! How? Through the practice of Continuous Delivery.

Continuous Delivery is an ongoing DevOps practice based on the automation of the entire pipeline. 

Are you a release candidate?

Unlike traditional processes where product development is separated from the functional activities for the software release, the Continuous Delivery approach proposes always ready software to release.

How?

You could do it through the continuous integration of each development, which is released in a staging environment – akin to the production staging. The software that reaches this stage has already passed the build and test phases, and as a matter of fact, it is ready to be released.

Every change that is introduced into the system following this practice is, therefore, a release candidate, deliverable in production as a new version of the software.

This process can be taken to its extreme, automating this last step and automatically put into production without a manual approval: this practice is called Continuous Deployment.

Differences among various deployment models

Starting from the concept of the release candidate, it is possible to identify six essential principles to guarantee an effective and continuous release process:

• Automating as much as possible: it is the prerequisite for a reliable, repeatable, and simple deployment pipeline.
• Keeping everything in version control: each changeset must be referenced with a version number and it must always be possible to identify the build of the number applications is released – at a given time in each environment – and from which version it comes.
• Building on quality: integration, testing, and release must be anticipated as much as possible to immediately identify software defects and being able to intervene to correct them. In this way, you can get to the Build Quality In.
• “Finished” means “released”: a feature achieves its purpose only when it is used by its users; in a CD process only what has already been released is considered finished.
• Everyone is responsible: it is essential to make people of the team co-responsible and encourage collaboration to obtain rapid and reliable releases. The success of a project is always a team success.
• Continuous improvement: the release process must be continuously and incrementally improved, exactly as for an application.

An applicable process even for small business

The CD approach is famous for being used by big corporations in the digital world such as Google, Yahoo, Amazon, and Facebook – just to name a few. But its functionality is not tied to company size: it is a set of principles that can be effectively applied to any company size.

Our experience

We introduced the concept of Continuous Delivery because we needed to reconcile product release with developments, updates and customers’ applications maintenance, and a need for product reconciliation – each of them has its own timing and needs.

Three years ago, one of our teams decided to introduce some principles of the Continuous Delivery approach into the release process and transformed them into practice. These principles have become development milestones for Mia-Platform.

Let’s have a look:

• Planned Goals: create a team board to keep under control the established release objectives for each work cycle, with a defined timetable (typically weekly), following Agile methodologies.
• Automatic deployment pipeline: the developed and versioned code activates the build’ automatic pipeline, unit tests, and acceptance tests. The release in a staging environment is enabled by the Product Owner, inside the team, who verifies the environment’s acceptance requirements. During each sprint, the set features go into production through an automatic deployment, operated manually during the predetermined release windows.

The team pipeline takes the code from checkout to the staging environment (NB: for this team, the red line indicates a manually activated step).

• Release windows: depending on the application domain and users’ traffic analysis, it is possible to identify the most suitable time windows for releases, according to needs. As a matter of fact, depending on the customer, it is not always possible to release any software at any time. In these time windows, therefore, there must also be time for any rollbacks and the re-deployment of the previous version.
• Small batches: the complexity of the merge exponentially increases as the amount of code released grows. So, splitting the job into individual features and proceeding through incremental development cycles decrease the chance of release failing. Furthermore, a possible roll-back would not invalidate all the work done.
• Rigorous versioning: when the releases in all environments are frequent, it is essential to always know what has been released in each environment; for this reason, each application and service display their own version number. In this way, teams can increase the number of their releases and critical failures are almost non-existent because the changes that break the system are automatically blocked before they arrive in production.

Conclusion

The principles of Continuous Delivery, applied to the development context of each team, allow us to face and overcome the fear of release, making the software evolve more quickly, easily, and reliably.

In our experience, a good delivery process must be automatic, can be activated by any team member, the same for all environments and must include separate build and deploy moments. Furthermore, it must follow a rigorous versioning system and continuously guarantee the software rollback.

This article comes from a talk by Riccardo Porrini and Tommaso Ballardini and it was published in its original version on Mokabyte released in May 2019.

{{cta(’86d6e5f7-efb2-4d58-a49e-299dd87ae947′,’justifycenter’)}}