Stages in continuous delivery pipeline

Agile without automation

Back in 2014 when the turbo charged engines of F1 cars were slightly tweaked, it left the fans utterly disappointed. There was a general perception that the engines were less on power and performance. But it turned out, the cars were as powerful as they were earlier, and the races were equally exciting.

Now let's suppose these power machines are made to race on tracks filled with mud and slush! Who is to be blamed at the end of an obviously lackluster performance? The engine of the car?

In just the same manner, certain software development teams end up blaming the Agile model after a few months of adopting Agile practices. Claims of burnouts, less predictability, scope creep among other accusations are leveled against the Agile methodology. While this is definitely not fair, the teams do have a point. The Agile way of working can be demanding for teams, especially for the ones who are just creeping out of a comfortable and familiar waterfall model. Without an automation ecosystem in place, it becomes even more taxing and soon you have team members complaining.

"Simply put, things always had to be in a production-ready state: if you wrote it, you darn well had to be there to get it running!" - Mike Miller

Automating Continuous Delivery

Agile without automation, is hard to consume. Hence, teams can start by first automating phases of the Build-Test Management-Deploy cycle, also called the Continuous Delivery (CD) process. This is because agile emphasizes on delivering high quality software frequently and this cannot be achieved by the traditional approach where teams push code into the testing environment, run manual tests, and deploy code manually. Though most enterprises have realized the importance of setting up an automated CD pipeline, only few have tasted success. This is primarily due to the plethora of technologies, tools, and the sheer size of most enterprises. This exercise of setting up the pipeline can be challenging, but at the same time rewarding. In addition to substantially shortening the demand to deploy cycle time, an automated CD pipeline brings in improved product quality, reduced risk, and better governance among other benefits. Let's look at the various activities involved in setting up a CD pipeline.

Setting up the CD Pipeline

While there is no definite Continuous Delivery pipeline structure, it usually encompasses the following stages:

1. Ideate and Plan:

   While this may not technically be part of the CD pipeline, we have consciously included this stage to stress the importance of Agile planning and make sure there is sufficient alignment between the Product Owners and developers. Typically, developers are often clueless about the business importance of a feature or the larger picture, and they end up working in a feature factory. Check out our article, 'Ditch the Feature Factory' to find out more about feature factory.

2. Commit and Build:

   When developers make changes to an application, they commit their code to a shared repository which will then integrate their piece of code with the trunk (central code repository). The changes are then compiled and packaged into a build after it is unit tested. The packaged builds are then stored in an artifact repository. A Continuous Integration (CI) product can orchestrate this repeatable process and provide a consolidated dashboard view. A CI server also checks code for test coverage and reports coming from popular code coverage tools like Emma would be much more effective!

3. Automated Environment Provisioning:

   Most teams face a significant roadblock when it comes to the testing stage. Staging environments are either shared by multiple teams or are very tough to get. What if these environments can be provisioned on the fly and destroyed after the testing activities are completed? That's exactly what configuration management tools like Docker, Puppet, and Chef automate. A word of caution (if its production environment), start off by automating infrastructure in small pockets with proper security protocols and backup servers in place.

4. Deploy:

   Deployment of the package into the staging environment can be automated by either using existing deployment scripts (if any) or leverage plugins provided by Release Automation tools.

5. Automated Testing:

   Ideally functional automation scripts need to be fired after the build is deployed in a testing environment. This can be orchestrated by a Continuous Delivery product. In fact, CD tools can orchestrate all these stages, resulting in better governance and increased visibility. This would also spare teams from toggling between multiple automation tools for reports and dashboards.

All these stages might look daunting at the onset, but it comes with a bouquet of benefits as explained earlier in the article. After all, we wouldn't want to see a fancy sports car stuck in a mud road, particularly if it is our own car!

Get in touch for futher quries