Skip to main content

6 key practices of continuous delivery pipelining

Continuous delivery is a method that promotes the adoption of an automated deployment pipeline to quickly and reliably release software into production. Its goal is to establish an optimised end-to-end process, enhance the development to production cycles, lower the risk of release problems, and provide a quicker time to market.

In a blog I wrote a few weeks back, I listed Jez Humble's 8 Principles of Continuous Delivery (opens in new tab). In order to achieve the Holy Grail of an "automatic, quality based, repeatable, reliable, continuously improving process", and not having to feel like you are chasing a myth, we must break that process into simpler practices. Building the "pipeline" enables us to deal with the different stages of the process, one by one.

A deployment pipeline makes sure a change is processing in a controlled flow. The system is as follows: a code check-in or configuration change triggers the flow. The change is compiled, and goes through a set of tests – usually unit tests and static code analyses. A successful test triggers automatic application tests and regression tests. After successfully passing these tests, the change can be either ready for production use, or go through additional manual tests and user-acceptance tests before hitting production.

Achieving an efficient deployment pipeline is done by following these best practices:

  1. Build your binaries only once

    Compiling code should only happen once, eliminating the risk of introducing difference due to environments, third party libraries, different compilation contexts, and configuration differences.

  1. Deploy the same way to all environments

    Use the same automated release mechanism for each environment, making sure the deployment process itself is not a source of potential issues. While you deploy many times to lower environments (integration, QA, etc.) and fewer times to higher environments (pre-production and production), you can't afford failing deployment to production because of the least tested deployment process.

  1. Smoke-Test your deployments

    A non-exhaustive software test (essentially testing "everything" – services, database, messaging bus, external services, etc.) that doesn’t bother with finer details but ascertains that the most crucial functions of a program work, will give you the confidence that your application actually runs and passes basic diagnostics.

  1. Deploy into a copy of production

    Create a production-like or pre-production environment, identical to production, to validate changes before pushing them to production. This will eliminate mismatches and last minute surprises. A copy of production should be as close to production as possible with regards to infrastructure, operating system, databases, patches, network topology, firewalls, and configuration.

  1. Instant propagation

    The first stage should be triggered upon every check-in, and each stage should trigger the next one immediately upon successful completion. If you build code hourly, acceptance tests nightly, and load tests over the weekend, you will prevent the achievement of an efficient process and a reliable feedback loop.

  1. Stop the line

    When a stage in the pipeline fails, you should automatically stop the process. Fix whatever broke, and start again from scratch before doing anything else.

The pipeline process helps establish a release mechanism that will reduce development costs, minimise risk of release failures, and allow you to practice your production releases many times before actually pushing the "release to production" button.

Continuous improvement of the automated pipeline process will ensure that less and less holes remain, guaranteeing quality and making sure that you always retain visibility of your production readiness.

Making sure your database can participate in the efficient deployment pipeline is obviously critical. However, the database requires dealing with different challenges than application code. Implementing continuous delivery for the database proves to be a challenge. Click here to read about 5 major differences between application and database Continuous Delivery (opens in new tab).

About the author:

Yaniv Yehuda is the Co-Founder and CTO of DBmaestro (opens in new tab), an Enterprise Software Development Company focusing on database development and deployment technologies.