What is a continuous delivery process map?

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

Basically, you vacuum-seal meat – the most popular being steak – and then put the bag inside of a container with water. The water is heated 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. You just pull it out of the bag and cut it up.

Continuous delivery does something very similar. The next section explains how!

From there,  we’ll go even further and discuss the process of continuous delivery, its benefits, and even its differences from other methods like continuous deployment.

Let’s get started.

What is Continuous Delivery?

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

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 maintains that temperature until you’re ready to eat. Continuous delivery creates software that’s ready to be released to production at any time.

This means the software is written, tested, and pushed into production-like environments to ensure it performs correctly in a real production environment. And it sits in a waiting area until you’re ready to finally deploy it, kind of similar to sous-vide.

The Process of Continuous Delivery (AKA the Continuous Delivery Pipeline)

The continuous delivery pipeline can be broken down into:

• Building
• Committing
• Testing
• Staging

Building is straightforward. The developer writes the code for the software and commits it 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. This will ensure that the customer will be able to achieve their goals when they use the software.

After testing, 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 can understand the benefits of continuous delivery, we need to understand software development before continuous delivery existed.

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 they get worse.

Also, rather than take a developer’s word for it, you can release the software into a pre-production environment and see for yourself 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.

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 in every environment.
• Fix problems in the code when they’re found.
• Scrap a build and start over if it has too many problems and your developers deem it unworthy.

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.

This 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 take the application to 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. It indicates that you’re depending on these people to manually fix something instead of automating it.

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

To recap, continuous delivery is an outgrowth of continuous integration which grew out of the ever-changing DevOps culture. 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.

Contact us today to discover strategies to make DevOps work for your business.