The 3 R’s in Continuous Delivery

By | 2014-07-14T11:28:07+00:00 July 14th, 2014|Practices, Release Management|0 Comments

We have all seen the latest buzzwords of Continuous Delivery over the last few years. The name “Continuous Delivery” gives a general idea of the practice: continuously deploying an application or code into a system.  The word “continuous” does not provide the detail of what we are trying to achieve in the Continuous Delivery practices.  This is where the 3R’s of Continuous Delivery come in: Reliable, Repeatable and Reusable.

Before we get into the 3R’s, let me first set the stage on common problems that arise.

Continuous Delivery (CD) addresses the team’s constraints in deploying software to an environment. What I have experienced over the last decade is that companies, teams and individuals spend a large amount of wasted time on simple and error prone tasks. This creates reduction in flow and value.

Take copy and paste for an example. That small website deployment of copying files from a package location to a website might seem a basic and insignificant task. However, if you start doing the math on how much that action costs, it quickly becomes an expensive and risky effort.

The math: A person takes 1 minute to copy files from one location to another.  A person performs that action 5 times a day.  Not bad – only 5 min out of day.   Now let us multiply that 5 minutes by 5 days:  25 minutes. Multiply those 25 minutes across your team, say 10 members: 4 hours.  Even a simple copy paste deployment can cost half of a day for even a modest 5 test deployments per developer per day!

Other examples of hidden cost and impacts to the team are:

  • Task Switching is what I like to call “Death by a thousand cuts.”  These small micro interruptions costs us to lose valuable time throughout the day.  That 1 minute interruption can cost 15 min for our minds to re-engage to the task that we have been focusing on.
  • Manual processes or what I like to call the “Silent Killers.” These small manual processes are like cholesterol (artery-clogging fat) within our software development workflow.

Now that we know what problems we are addressing, let’s get into the 3R’s (Reliable, Repeatable and Reusable) and how they link to a solutions.

Reliable. Every system needs to be reliable, especially a deployment system. I have seen over the years a number of systems, approaches and models.  The one that I have seen development teams do most is create their own deployment system.  This might be done out of ignorance of the tools that are available or because “We did this at my last job!”  While I appreciate some of these systems, it breaks the 3R’s rules.  Why, you might ask?   The system can only be Reliable if it gets the attention and effort that it needs to support internal and new industry changes.  If your company builds CD and deployment systems, then it is within the core business and it would get the attention and effort. If not, then it is most likely a sub-project that does not get updated or even worse, only one person knows how it works.

The question you should ask is this: Do you want our development team to spend time on building, supporting and updating the deployment of your core business software?

Repeatable. This is at the heart of the deployment system. Being able to repeat the process in a known and consistent manner solves a number of problems due to manual processes and general human error.  The Quality Assurance (QA) and Operation (Ops) teams rely on a repeatable known process to reduce risk and unknowns. Being able to remove the deployment process out of the equation when testing or troubleshooting a bug reduces the time spent on these tasks.  In addition, it is nice to have a reliable and repeatable system to reduce the non-productive time previously used for explaining and proving the bug or issues is not in the build and deployment process.

Reusable. A system needs to be reusable and flexible to accommodate more than just one project. It’s better to think globally across the company’s enterprise than to have a delivery system that only works for your team.  The number of incompatible systems that does the same type of work increases the costs in the obvious areas, but the additional hidden costs of lose data and transparency are not full captured.  Not mention the support and application knowledge each tool needs to have.

There is no “one size fits all” deployment tool or practice.  Deployment tools like Microsoft Release Management and Octopus Deploy are two deployment tools that fit within the 3R’s. The ROI tool of a 3R’s deployment system is fast. By cutting the common waste within you software delivery pipeline, our customers report that their teams improved the overall performance by 10-30% in the first 3 months of implantation. The cost of not doing the 3 R’s cannot be completely captured. There are too many variables and other factors that adds to the cost that are not always in obvious.

And that brings us to the most important reason to automate: freeing humans from repetitive, boring tasks.  We can all do the math, debate the numbers, and discuss the pros and costs of automating a deployment pipeline, but we shouldn’t forget the often unmeasured cost to the team due to frustration, boredom, and apathy.  Managers hire people to think. Automation frees them to do so.

About the Author:

Leave A Comment