What Is Continuous Delivery? the Benefits and Best Practices

by The ATC Team | May 27, 2019

If You are asking yourself “ What is Continuous Delivery ?” then you’re in the right place.

There’s a cooking method that’s super popular right now called sous-vide (pronounced “sue-veed”).

Have you heard of it? It’s pretty cool (and yes, it relates to continuous delivery).

Basically, you vacuum-seal meat — the most popular being steak — and then put the bag inside of a container with water.

The sous-vide contraption heats the water to a specific temperature, which heats the steak to the exact same temperature.

The best part?

The meat stays at that temperature for as long as it sits in the water.

Meaning you can perfectly cook a medium-rare steak to 135 degrees and keep it perfectly cooked for hours, even a whole day if you wanted.

So when you’re ready to eat the steak, you just pull it out of the bag and cut it up.

What does this have to do with continuous delivery?

It’s essentially the same process. And we’ll prove it in the next section.

But we’ll go even further and show you the process of continuous delivery, it’s benefits, and even it’s differences to other methods like continuous deployment.

Let’s get cooking.

What is Continuous Delivery?

In our previous post about continuous integration (CI), we provided a definition of it from Aaron Cois.

He said CI is a technique designed to continually merge “source code updates from all developers on a team into a shared mainline. This continual merging prevents a developer’s local copy of a software project from drifting too far afield as new code is added by others, avoiding catastrophic merge conflicts.”

Continuous delivery is the next phase of this process.

Which brings us back to sous-vide.

Sous-vide cooks meat to a specific temperature and keeps it there until you’re ready to eat.

Continuous delivery creates software that’s ready to be released to production at any time.

Meaning, software is written, tested, and pushed into production-like environments to ensure it will perform correctly when in a real production environment. And it sits in a waiting area until you’re ready to finally deploy it.

Just like a juicy steak sitting in a bag at the right temperature waiting to be eaten.

What is the Process of Continuous Delivery (AKA the Continuous Delivery Pipeline)?

The continuous delivery pipeline is pretty straightforward once everything is automated.

The continuous delivery pipeline, as it’s commonly known, can be broken down into these basic parts:

• Building
• Committing
• Testing
• Staging

The building part of this process is straightforward: the developer writes the code for the software.

After that, they commit the software to the source repository.

Then the software undergoes different types of software testing using a variety of automated testing tools.

These may include:

• Unit testing to analyze a single component or individual module.
• System testing to determine if the final software product works in relation to the computer system it’s a part of. This includes white box and black box testing.
• Acceptance testing or user acceptance testing (UAT) to test the total functionality and usability of the software.
• Smoke testing to identify any “showstoppers” hidden in the code.
• End-to-end testing to test each element of the software from beginning to end to ensure continuity and flow for the end-user, simulating real-world use so you know the customer will be able to achieve their goals when they use the software.
• And many more.

Once this is complete, the software is put into a pre-production staging environment that mirrors the actual production environment, allowing for more advanced testing, such as:

• Graphical user interface (GUI) testing to evaluate the GUI based on your clients’ requirements and/or customer feedback to make sure that customers understand the UI and how to interact with it and use it.
• Integration testing to determine if all the units of the software operate in harmony with one another.
• Compatibility testing to see how your software will function in a variety of different environments.
• And so on.

And that’s where it stays until it’s ready to be deployed to production.

You’ll know you’re practicing continuous delivery when:

• Software is deployable throughout its lifecycle.
• Your team puts emphasis on deployable software over new features for the software.
• Any developer can receive automated feedback on deployability of the software any time another developer makes a change.
• You can, at any time, deploy the current version of the software to any environment, including production.

What are the Benefits of Continuous Delivery?

Before we describe the benefits of continuous delivery, we need to understand software development before continuous delivery came along.

You see, continuous delivery grew out of agile principles and values, which were developed as a response to the old-school method of software development: Waterfall.

In our post about the agile methodology, we gave a brief overview of the waterfall method:

“The waterfall methodology was long and tedious. It all started with heavy documentation upfront, gathering together all the requirements for the software and everything the business wanted to be included in the final product. These were long documents that detailed everything from functional specs to user interface designs.”

Too many manual processes.

Too many delays.

Too many errors.

But the Agile-inspired method of continuous delivery allows you to “fail fast” and, as a result, succeed more, and more quickly. By consistently deploying software into the main source repository and testing it relentlessly, errors are easily identified and fixed before growing into a much bigger problem.

Also, you don’t have to rely on a developer’s word that software is “done.” When you release it into a pre-production environment and test it there, the results will tell you if it’s done or not. Continuous delivery creates believable and reliable progress.

Plus, developers are more productive when they can follow a repeatable process using automated software to streamline their workflow.

What’s the Difference Between Continuous Delivery vs Continuous Deployment?

Some people confuse continuous delivery with continuous deployment, but there is a clear distinction:

Continuous delivery gets software into a state where it can be deployed into production at any time.

Continuous deployment means you take that software and actually deploy it into production automatically, sometimes several times a day.

Continuous deployment is impossible without continuous delivery.

One other key difference is that some teams practicing continuous delivery will manually approve software before deploying it to production.

Whereas, teams practicing continuous deployment will automatically push software into the production environment without manual approval.

What are Some Continuous Delivery Best Practices?

If you want to implement continuous delivery in your organization, the following best practices can help guide you.

Always Be Ready to Deploy

Rule #1 of any continuous delivery team is that software is “done” when it is in some kind of staging environment, has been thoroughly tested, and can be deployed to production at any time.

This means DevOps teams should:

• Establish the automated tests they plan on running.
• Use the same build of the application throughout the development and testing pipeline so you don’t have to build application binaries at every environment.
• Fix problems in the code when they’re found.
• And if a build has too many problems and your developers deem it unworthy, scrap it and start over.

Practice Continuous Integration

As we noted earlier, continuous delivery grows out of continuous integration. So if you want to practice continuous delivery, you have to start with continuous integration.

Which means you should follow the 10 principles of continuous integration:

1. Maintain a Single Source Repository
2. Automate the Build
3. Make Your Build Self-Testing
4. Everyone Commits To the Mainline Every Day
5. Every Commit Should Build the Mainline on an Integration Machine
6. Fix Broken Builds Immediately
7. Keep the Build Fast
8. Test in a Clone of the Production Environment
9. Make it Easy for Anyone to Get the Latest Executable
10. Everyone can see what’s happening

And finally, use continuous delivery to add the final step of staging the application in a deployment-ready environment.

Create Stops Between Development and Production

We talked about this best practice a bit when we discussed the continuous delivery pipeline.

You know you need to test your software before releasing it into production, so that constitutes at least one stop.

But you also want to make sure you put your application into an environment that mimics the actual production environment. The reason is to completely validate that the release is production ready, that all the scripts perform correctly, and it’s virtually error-free.

Deploy Software the Same Way in Every Environment

You don’t want to deploy software differently in different environments. Instead, you want to deploy an application into each environment the same way you would once you deploy it into production.

That means you should use the same automated release mechanisms for each environment. This helps troubleshoot the deployment process — resulting in fewer issues.

Don’t Use Quick Fixes; Fail and Restart Instead

One of the best qualities of a continuous delivery pipeline is that you can feel comfortable starting from the beginning if you have to.

You don’t have to add one manual little fix here and another there, compounding temporary fixes to errors that may grow into major issues.

You can go back to the beginning of the build and fix it and then run it through your automated pipeline again seamlessly.

Automate as Much as Possible

The more you automate, the less time you waste and the fewer manual errors you commit.

If you notice that your pipeline only works when certain people are involved, this may mean that your automated systems aren’t optimized and you’re depending on these individuals to manually fix something that should be done automatically.

Make sure that your end-to-end process is completely automated by identifying any areas where you’re performing manual work and figure out a way to automate it.

Use Version Control for Everything

Using a version control system like GitHub or Azure DevOps Server for every single script, database change, or configuration file.

It’s also recommended to store binaries in a package repository like JFrog’s Artifactory or Octopus.

Next Steps on the Path to Continuous Delivery

As we’ve made abundantly clear in this post, continuous delivery is an outgrowth of continuous integration which grew out of the ever-changing DevOps culture.

You see, DevOps brings together all the teams who would eventually interact with a new software project and allows them to collaborate simultaneously, give and receive feedback, and speed up the development and deployment cycle.

Unfortunately for the uninitiated, DevOps can seem too frustrating and complicated to implement for many organizations, leading them to settle for their current processes instead of trying something new.

That’s where we come in.

ATC specializes in DevOps consulting. We can help you:

• Audit your current processes, identify inefficiencies, align your team around a common end-state vision, and create an actionable plan for implementing DevOps and continuous delivery.
• Assist you in setting up your “continuous delivery pipeline” and applying DevOps’ end to end process automation while improving security, compliance, and productivity.
• Achieve full DevOps integration in your organization and handle release management, continuous deployment, and new server setup while reducing the costs of ongoing management.

This article was originally published on TEAM ATC