How It's Made: A Continuous Delivery Pipeline

Software delivery was once specific to the IT industry. Now, Continuous Delivery pipelines are used around the world, from e-commerce to airline software.

Building a software delivery pipeline once involved hours of scripting and manual steps — a process that’s painful, if not impossible, to scale. However Continuous Delivery with application release automation tools offers a scripting-free, automated experience. Continuous Delivery pipelines are immensely powerful for the modern enterprise, boosting production and even customer satisfaction.

Getting Started: Measure the Existing Process

To get started building a Continuous Delivery pipeline, the IT Manager measures key metrics from the existing software release pipeline. The most important metrics to look at are:

• Time to deployment.
• Deployment frequency.
• Change volume.
• Success rate.
• Mean time to recovery.

After taking initial measurements, the IT Manager begins to identify existing bottlenecks by looking at three areas of interest: requirements management, testing, and delivery mechanics.

Requirements Management

Continuous Delivery pipelines are all about adding customer value quickly. In this instance, quicker often means smaller. Start by breaking down your deliverables into smaller stories that can by-pass the work-in-progress stage so every task is being worked on actively. Short cycle times is the goal here, even when you need a full set of stories to create the deliverable.

Testing

Start by shifting your focus from GUI testing to unit and integration testing. This is also the right time to start thinking about an automatable testing process. Before automation can happen, the existing process needs to be structured, organized and repeatable.

Delivery Mechanics

The concentration of delivery mechanics is to take a deeper look at the automation of the delivery process. The best place to start is with versioning controls. Once automated rollbacks are set up, the IT Manager can begin looking at the automation of Continuous Integration.

Continuous Integration

Once the IT Manager has taken measurements of the existing process, automation of the build processes can begin. To do this, the IT Manager uses a build automation server to trigger a sequence of steps and tests, including SCM code fetch, build, package, and unit-test. Once the code has made it through the Continuous Integration process, it’s time to start provisioning environments for acceptance, performance, and security tests, and ultimately the production environment using the same process that was used to provision the production-like environment during the automated build process.

Continuous Delivery

Now that the code is in the release stage, let’s look at how the IT Manager releases the code into production. Deploying code into production was once a manual step, but nowadays, it is much easier with the use of Deployment Automation and Release Orchestration Tools like XL Deploy and XL Release. With these tools, deployment plans are automatically created for specific versions of your application and for your target environments. The deployment plans can take code from development to production automatically, ensuring a fast and repeatable process for your applications.

To recap, building a Continuous Delivery pipeline begins with the IT Manager measuring the existing release pipeline, then automating the build process and adopting tooling that creates deployment plans for easy dev to prod code releases. All that’s left after that is implementing this automated, organized process into the daily workings of the enterprise to deliver a scalable Continuous Delivery Pipeline.