CI/CD: Defining the Software Delivery Pipeline

June 15, 2018

Together, CI and CD implement the changes necessary to make the DevOps philosophy of delivering value quickly a reality. Read our overview in The Key to Realizing Agile and DevOps is CI/CD.

The Deploy and Release Challenge

For many organizations, code deployment is painful and arduous – an intensely manual process sometimes consisting of hundreds of steps that may not be fully documented. This is complicated further by variation across environments and the difficulty in ensuring the quality of test data in lower environments. Something that should be a no-brainer becomes a nail-biter all too often.

Properly defining the delivery pipeline minimizes/removes roadblocks, allowing development to proceed unimpeded.

Defining the Software Delivery Pipeline

Defining the delivery pipeline involves putting in place systems (people, process, and technology) to develop, build, test, deploy, and validate all the way through production, safely, quickly and sustainably. Benefits include minimizing bottlenecks, rework and unnecessary manual intervention. Here are nine steps that will guide your team in defining a software delivery pipeline that enables repeatable and consistent deployment and release:

    1. Create a Charter. Clearly define the objectives, scope, and timeframe of the initiative. Be sure the sponsor and champions articulate the outcomes and establish their expectations.
      CI/CD - Example Project Charter
    2. Understand Current State of Software Delivery Process. With a charter in place, assess the current state of how software is developed and released, including:
      • How the application development organization is organized.
      • The practices the team uses.
      • How long team members wait before they can take the next step.
      • How long each step takes.
      • The quality of output from each step (in terms of completeness and accuracy).
    3. Identify Bottlenecks and Constraints. By closely examining current state, you can identify why bottlenecks are occurring. Some common contributing factors include:
      • Environment availability doesn’t meet release cadence, leading to excessive wait-times.
      • Granular batching of features into deployment packages leads to too much integration.
      • Deployments are inconsistent across environments, resulting in rework and redeployment.
      • Feedback loops are slow or missing, requiring “find and fix” late in the delivery lifecycle.
      • Performance issues found in production, not in testing phases, increasing production patches.
    4. Consider the Overall Technology Roadmap. Ensure the CI/CD solution, at a definition and architecture level, can be applied across the enterprise without conflicting with other technology systems that support key business workflows.
    5. Define a Lean Deployment Reference Architecture. Use the considerations above to help define the right reference architecture for deployment and release management.
      ci/cd reference architecture
    6. Define Should-Be State Using Relationship Diagrams. Use the current-state analysis, technology roadmap and deployment reference architecture to define the “should-be” state. Then, depict the flow, both conceptually and visually, using relationship diagrams. These diagrams help in designing pipelines where deployment into any environment results in repeatable, consistent releases.
continuous integration diagram
release management diagram
  1. Finalize Tools and Technologies. Select the specific tools and technologies needed to implement CI/CD (which will vary depending on the enterprise and environment).
    CI/CD Toolchain Example
  2. Identify a Pilot Application. An enterprise-wide implementation may be the ultimate objective, but beginning with a single key application provides several benefits:
    • The implementation process becomes iterative.
    • Teams can exercise aspects of the orchestration and release governance process.
    • Triggers and monitors can be set up and tweaked to offer the most valuable, timely feedback.
    • Collaboration channels can be built across development, QA, and operations.

    Tip: If an existing team already follows an agile methodology or is eager to implement automated testing earlier in the lifecycle, start with that application.

  3. Start Implementation. Move to implementation in iterations with specific iteration objectives. This will establish yardsticks for communication throughout the initiative—informing relevant teams what will be in place and what could be expected of them in each iteration. Where possible, each iteration should include not only technology changes but also process and people changes.

Instill an Attitude of Shared Responsibility

Planned and opportunistic communication is critical for any initiative. Communicating and sharing ideas early and often fosters a culture of learning and experimentation. And since embracing DevOps principles is as much about the right culture as it is about getting functionality to production seamlessly, instilling an attitude of shared responsibility is a critical success factor of CI/CD.


Learn how the SQA team prepares your organization for DevOps and CI/CD adoption.

Additional Articles