Continuous Delivery: Painless Births

Presenting our creations to the world can be one of our greatest fears. Posting a song, posting a photo on Instagram, putting a Website online or even publishing a Blog Post (like this one), are charged with a feeling that mixes fear and expectation simultaneously.

In the case of technology, and specifically of Software, those of us who have the privilege of working in this art experience that feeling every time that “our babies are going to go out into the world”, or in other words, when we put our Software in Production!

And you will ask: “But JJ, how to deal with this?”….. Good thing you ask! :). The DevOps philosophy has some secrets to minimize the pain of this “birth”.

Pause to understand DevOps slang

Product Release = Make the most recent version of a product public (obviously in Production).

Deployment = Install, test and configure the product in an environment, for example: Development or Pre-Production. A Deployment can even be made to Production, without making it visible to the public until the Product Release.

Examples:

“Come on, let’s do the Deployment of version 2.0.3 to Production.”
“Deployment of Release 2.0.3. was a success!” (Yes, with a little effort, those words will come out of your mouth often 🙂 )

Now that we have things clear, let’s continue:

These are some of the symptoms of a painful Product Release:

Infrequent releases
- When I mentioned “childbirth”, I was speaking figuratively! It doesn’t mean that you have to wait 9 months to have Releases
- Less than 4 Releases per year is a sin.
Manual Deployments
- Humans are not made to perform repetitive tasks. Period.
- Having a human manually copy/paste an App in Production is extremely risky, especially if it’s someone who is tired or distracted (or hungry! #trueStory).
Bugs found in Production immediately after Release.
- I can only ask: “So…what happened to the testing?”
Dev Box: the Test Environment
- You tell me that the testing was done on the Developers’ machines? Are you aware that this “environment” has the same degree of hygiene as a public toilet at a concert?
Release Friday
- “Release on Friday night …in case something goes wrong.” Do you really have so little confidence in your deployment (which should already be automated) that you give yourself 30+ hours in case “something goes wrong”.

“If something hurts, do it more often.”

When Martin Fowler says “If something hurts, do it more often” (Martin Folwer – FrequencyReducesDifficulty), he’s referring to the continuous search for the stressors that contribute to progress. Non-digital life example:

After a month of physical inactivity, returning to training in the gym will cause intense muscle pain, which will be greatly reduced by maintaining a regular training frequency .
When learning the complicated part of a song on guitar or piano, our neurons are exposed to stress that, the more times it’s repeated -in a focused way- , the easier the task will be until we master it .

Despite sounding counterproductive, these are tangible proofs of the benefits of frequently challenging our fears and discomforts. And, the more we do it, the more self-confidence we have, therefore, we go from fear to curiosity to know what else we are capable of achieving.

The Continuous Delivery mindset allows companies like Amazon to execute Releases every 11.6 seconds. Maybe you don’t need to deploy at that speed, but you definitely want to use Continuous Delivery to automate what’s causing you pain and avoid issues and overtime on release day.

Tips for Achieving Continuous Delivery

Schedule Frequent Releases

The recommended cadence of the Releases is between 2 weeks to 2 months. Coincidentally, it is recommended by Agile Methodologies – Principle #3 .
If the organization of your Development Team is based on User Stories and these do not fit in a Sprint, you have two alternatives:

Make your stories smaller. There’s always a way to reduce them.
It uses the Dark Launch technique to hide functionality that is not listed.

Automate Deployment 100%

Apps installation – especially if it’s something as simple as copy/paste files – their configuration and verification should be fully automated.
There is no single tool that covers the particular needs of each App, but there are quite a few Scripting languages that will help you customize the Deployment according to your needs. Ex: Python, PowerShell, Ruby, etc.

Run Tests before Deployment

The automated process of Deployment (CD Pipeline) is like the pizza boy . If the cooks prepare a gourmet pizza, the boy will deliver it quickly. If the cooks prepare , the boy will deliver it…quickly .
Don’t forget that a successful Continuous Delivery goes hand in hand with Continuous Testing when the tests are automated.

Use “Placeholders” in your configuration files.

Suppose you plan to deploy a Website, it will most likely contain a web.config file. Since you already follow the DevOps philosophy and communication between your Devs and Ops is fluid, you can coordinate with both teams to have “Placeholders” like the one in this example:

<connectionString Server=”{APP-SERVER}” Database=”{APP-DB}”>

Where {APP-SERVER} and {APP-DB} are the Placeholders that will be replaced with proper values for the Environments where said Website will live.

Create a Testing or Pre-Production Environment

Have at least one sanitized Testing or PreProduction environment that is a mini-version of Production.
As you already have your deployment automated and you also use Placeholders to customize settings by Environment, deploying in environments is a piece of cake.

No one is safe from starting with painful Releases, this is a kind of “Baptism of Fire”. This being the case, remember that from the moment that humans mastered fire , our evolution was upwards .

What’s your experience with Deployments and Releases? What other suggestions do you have?

Leave your comment and let more people benefit.

Keep on learning… and Delivering!