Author : Mayowa Tundonu
Releasing a version of a piece software to production can be described as a bittersweet experience for many developers. The sweet experience comes from a feeling of accomplishment of a certain set of goals — new features or bug fixes, or anything else. The bitter experience can, however, be summarized in a very popular expression amongst developers; “Don’t deploy on Friday afternoons”. Many developers take this advice in order to ensure that they do not spend their entire weekend debugging various issues that may occur when the software is eventually deployed to production on Friday. So, often times, deployment occurs on other days of the week, except, of course, Fridays.
“If you know the enemy and know yourself you need not fear the results of a hundred battles.” — Sun Tzu
The goal of every Software Professional is to deliver high-quality software in short cycle times, while also enjoying every process that leads to the delivery of this software. However, there are certain practices that make the process of releasing software a bit of pain. These practices can also be referred to as Software Release Anti patterns. Let’s have a look at some of them.
- Deploying software manually: Deploying software manually means that the process of deploying an application is separate — done in a different environment that is only known to certain members of a team and atomic — each process is performed by an independent team or individual. This anti pattern is very prone to human error because the ordering and timing of the steps required to deploy an application often lead to different outcomes. The image below provides a perspective on how manual software deployment can lead to a serious delay in project delivery
Manual software deployment. Credit: Bitbucket
- Deploying to a production-like environment only after development is complete. When this eventually happens, it leads to inconsistency in the behavior of the software because the software is now in an environment with a different set of configurations than the development environment. This is where the tweaking begins for the operations team to ensure that the behavior of the application is the production-like environment is consistent with the development environment. As the application grows with new features being added, new configurations, etc., the inconsistencies also increase; it probably never ends.
Deploying to a production-like environment after development is done
- Manual configuration management of the software environments — development, staging, production. The image below makes this anti pattern very obvious. The development, staging, and production environments all have different configurations. This is likely because the environments are handled by different teams, at different times. It goes without saying that these configuration discrepancies will lead to problems.
Different configuration for different environments
Strive for continuous improvement, instead of perfection. — Kim Collins
To achieve our goals as Software Professionals, we can improve our software release process by adopting the Continuous Delivery approach.
Continuous delivery is a software release practice where teams release high-quality software products frequently and predictably from source code repository to production in an automated fashion.
Automated Continuous Delivery Pipeline.
Before we highlight some of the benefits of Continuous Delivery, it might be worthwhile to talk about what Continuous Delivery is not. These are some general misconceptions about Continuous Delivery that may hinder its adoption or proper application amongst teams or even as a solo developer. Here are some of them.
Continuous Delivery is not a destination
Continuous Delivery is neither a checklist nor a destination, it is a journey. It is at the heart of continuously improving the process of delivering high-quality software products to users in short cycle times.
Continuous Delivery is not a buzzword
Continuous Delivery is not another buzzword. It is taken from the first principle of the Agile Manifesto which states that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. It is an approach that is meant to improve both software release processes and experience as well as improve the experience of our customers.
Continuous Delivery is not exhaustible
As a process-driven practice, Continuous Delivery has so many components, each with varying degree of ease in applicability and complexity. Therefore, the aim should not be to apply all the components in your release process, as this might defeat the goal of Continuous Delivery, rather, the aim should be to extract the components that fit our software release process and apply it to improve our software release process.
Having highlighted and corrected some of the misconceptions about Continuous Delivery, we can go ahead and talk about how Continuous Delivery can help us achieve our goals as software professionals.
Build applications faster with components
As stated earlier, our goal as software professionals is to deliver high-quality software in an efficient, fast and reliable manner. This can be summarized into a two-point agenda as
- High-quality Software.
- Short Cycle Time.
Cycle time is the total time spent from when a feature to be added to a piece of software was decided till when the feature is released to the user.
Continuous Delivery can help us achieve this goal through automated and frequent releases. How’s that? To answer this question, let’s try to understand what automated and frequent software release means in the context of Continuous Delivery.
- Automated Release: The manual process of releasing software to production is very error-prone, hard to review, and difficult to control or rollback. This ultimately defeats the first point of our two-point agenda — High-quality software. Despite the difficulties with the manual software release, many software products deployed using this process are still working well with so many users even after so many years. So, it is not all completely bad, but it can be better. What is noticeable is that during manual software release, the same set of processes are repeated over time by humans. Continuous Delivery abstracts these repetitive processes into a pattern and then automates the pattern using a set of tools and presents a better software release framework called a Deployment Pipeline Pattern. The Deployment Pipeline pattern makes the computer perform the boring repetitive tasks during software releases without sacrificing quality and allows humans to do what they do best. A deployment pipeline is an automated implementation of an application’s build, deploy, test and release process. The manual processes that Continuous Delivery automates are the build, deploy, test and release processes.
- Frequent Release: Short Cycle Time can only be achieved when releases are frequent. Frequent release is important because it increases the rate at which we get feedback from our users. Furthermore, it also increases the quality of feedback from the users which enables the delivery team to act faster and deliver quality releases. Frequent release is heavily dependent on automation. The more reliable a deployment pipeline is, the higher the frequency of release.
Automated and Frequent release provide feedback. This feedback can be acted on very quickly and the result of this is high-quality software and short cycle time. Automated release tracks changes in the software and its environment and reports the effect of those changes to the teams. Frequent release tracks feedback from users and a process can be created to collate these feedback and report to the team.
What are the benefits of adopting Continuous Delivery?
Continuous Delivery comes with some very cool benefits that encourage its adoption. Here are some of them.
- Continuous Delivery empowers teams to be more productive by reducing dependency amongst team members, increasing work flexibility and collaboration. For example, the operations team can create the application environment and check it to version control. Testers and developers can set up their environments for the application using the application environment from version control. The testers test each feature as the development teams release them while the development team works on other features. Bugs can be reported using bug tracking tools and tickets can be created for those bugs which can be reviewed later by the development team.
- Continuous Delivery reduces errors through the deployment pipelines. Any changes made to the code base, code configuration, or code environment is detected and tested in the pipeline. A report is generated which contains the effects of the changes that have been made. If any error occurred during the changes, the reports will tell. Nothing goes unnoticed.
- Continuous Delivery reduces the stress level of the team. I think every Engineer knows what stress feels like. haha.
- Continuous Delivery increases deployment flexibility. Using the right tools to track software releases, when a bad release occurs, the production-like environment can be rolled back to the previous stable release and the bad release can be investigated for bugs.
Continuous Improvement is the goal of Engineering. Adopting practices and techniques that will improve how we build software applications is very necessary. Continuous Delivery is one of the practices that can help us build better. The main focus of Continuous Delivery is to help Software Engineers achieve their goals through automated and frequent releases. Automated releases can be achieved by implementing a deployment pipeline, while frequent releases can be used as a feedback channel from our users. As I mentioned earlier, Continuous Delivery is not a magic wand, it will not solve all the software release problems in the world. But it gets Software Engineers and teams closer to achieving their goals.