Three Pillars of Continuous Delivery
Three Pillars of Continuous Delivery
For me, you cannot start doing any good Continuous Delivery without thinking about these three elements. They make other ingredients of Continuous Delivery easier to add.
Join the DZone community and get the full member experience.Join For Free
Some time ago, I was invited to take part in an online panel about Continuous Delivery. Continuous Discussions is a series of one-hour long panel discussions between people from different backgrounds about various aspects of Continuous Delivery. The topic of my panel was Deployment Automation 2.0 and we spoke about patterns in the automation of deployments and possible future changes in this area.
At the beginning, we were asked to define must-haves of any deployment automation. When I was looking for these must-haves, I tried to identify the elements which were most important for me during the introduction of Continuous Delivery. What struck me the most was taking many things required by this process for granted. Tools or the readiness of an organisation for automation were not always in my mind when I started to automate "things" in different projects. This preparation gave me the possibility to identify my three pillars of good Continuous Delivery.
1. Automation, Automation, Automation
Automate the Right Thing
It sounds very easy, but when I look now at some of my past decisions, I was not always automating the right part of my process. If you do your manual steps frequently, use a lot of time doing your manual tasks takes a lot of time or your process is repeatable and complex, you have a good candidate for automation. Any automation without good context might lead to improvement of unnecessary parts of your software delivery.
Use the Right Tools
Identify the tools that can help you. In the modern world of software development, we have plenty of options. Tools like Jenkins, Bamboo, Travis, Ansible, and Docker can help you in the automation, but without a good justification of usage they can be just fancy tools. Your automation should evolve together with your needs and problems which are introduced by these problems. Proofs of concept will allow you to understand if a specific tool is adding any value in the context of automation.
2. Rapid Response
Give Answers Now
Continuous Deployment should help you discover problems before they occur in the production environment. If your deployment process takes days, weeks, or even hours in some cases, you can miss the opportunity to find out if your software is valid and ready to use. The time between the discovery and the fix of an issue can be minimized by the rapid response from your Continuous Deployment process.
Make It Faster
Many different things can make your process slower. One such problem is how your processes are organized. In many cases, in my previous projects, the original version of the process required the individual involvement of many people in the organization. Sometimes, you don't have the right access rights to your infrastructure and deployments are impossible. Try to improve or change these elements in your organisation. The automation of your process should not only include the solutions for technical problems, but it should also improve non-technical aspects of the process.
3. Team Effort
Do It Together
In my opinion, the responsibility for Continuous Delivery should be shared by the team. By the team, I mean all people involved in the project — not only software developers, not only system administrators, all business stakeholders. The understanding of Continuous Deployment by all members of the team strengthens knowledge about the software and improves cooperation. Our software is no longer just lines of code, it is also the place where this software lives.
No Silo Culture
Every technical person in the team should be able to start, improve, and fix the Continuous Delivery process. I understand that this can be a challenge and the team may face many failures, but by being inclusive, you can make your Continuous Delivery a beneficial process. Without the engagement of your whole team, you create an invisible wall between the software development and its deployment. This can ruin all efforts of introducing automation because your process will not be aligned with changes taking place in the code.
You may ask why just three. For me, you cannot start doing any good Continuous Delivery without thinking about these three elements. These are the parts which I would like to have during when I start introducing any automation in my projects. They make all other ingredients of Continuous Delivery easier to add.
This article was first published on the Codurance blog.
Published at DZone with permission of Robert Firek , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.