CI/CD: Defining the Software Delivery Pipeline
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
Many organizations have trouble deploying code easily after every build, resulting in extensive manual intervention. And if environments aren’t always available, lead time is increased through the deployment pipeline.
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:
- 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.
- 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).
- 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.
- Consider 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.
- Define a Lean Deployment Reference Architecture. Use the considerations above to help define the right reference architecture for deployment and release management.
- 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.
- Finalize Tools and Technologies. Select the specific tools and technologies needed to implement CI/CD (which will vary depending on the enterprise and environment).
- 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.
- 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.