Continuous integration and continuous delivery are central to DevOps-driven organizations.
CI means teams frequently update and introduce code changes, while CD applies further tests to ensure it can be deployed successfully. Combined as a CI/CD feedback loop, they enable continuous upgrades to the production environment and faster responses to the organization's needs through smoother software delivery compared with a Waterfall approach, which involves larger changes at greater intervals.
Smoother software delivery is just one benefit of a CI/CD approach. Organizations that choose to implement CI/CD can also benefit from improved change management, shorter testing cycles and enhanced feedback loops. However, CI/CD also comes with its share of challenges, requiring significant investment in people, processes and technology. Weigh these benefits and challenges to determine if CI/CD is an appropriate fit.
What is a CI/CD pipeline?
A CI/CD pipeline is a set of tools and processes that automate the continuous integration and delivery of software. It works well within an Agile approach to software development and can be contrasted against the more static Waterfall approach. In Waterfall, rollbacks can be time-consuming and messy because the process requires reworking earlier stages when issues are discovered late in development.
With a CI/CD development process, teams prioritize proposed changes as they come in, working on areas that have the biggest benefit to the organization. Each area is, by definition, a smaller component compared to a Waterfall version change. Teams can plug the code changes into the existing code and then perform more specific functionality and integration tests, ensuring that the new code does not have any unwanted downstream impacts.
Teams can then release the new code component into the operational environment in a manner known as continuous deployment. If things do not work as expected, rollback is simply a case of reverting the component to its earlier version.
As the systems administrator identifies required bug fixes or as business users make feature requests, they are added to the CI/CD pipeline and then prioritized within the development workflow as necessary. In this way, CI/CD ensures that the system is always responding to the organization's and end-users' needs -- and at a faster rate than a Waterfall approach.
What are the benefits of a CI/CD pipeline?
CI/CD pipelines offer many significant benefits to organizations, rooted in a flexible, iterative approach to development. Let's look at the main benefits of a CI/CD process:
- More responsive development. With CI/CD, developers can rapidly prioritize and address each organizational need. As feedback comes in, teams can efficiently adapt to changing requirements and deploy updates thorough the pipeline.
- Closer working relationship with the organization. CI/CD is driven by the organization's needs, rather than what developers may view to be more technically interesting. This limits the scope of work to what's most beneficial to the organization and keeps developers from wasting time on low-value updates and fixes.
- Better teamwork. With a Waterfall approach, everything is highly controlled, and things can go wrong across a large team. With CI/CD, smaller teams can work on specific items without as much worry about what other parts of the overall team are doing.
- Better code quality. Smaller changes involve less code, limiting the scope of testing for each incremental change. Teams can check code quality more thoroughly before it reaches a full testing environment.
- Earlier error fixing. Developers can more easily identify and solve problems earlier in the DevOps process. This approach ensures reliable software releases, helps developers fix bugs before they reach the entire user base and reduces the amount of application downtime.
- Shorter testing cycles. Less complex and smaller volumes of code to check mean there's less need to repeatedly test functionality throughout the CI/CD process. Teams need not waste time testing the same functionality repeatedly.
- Easier change monitoring in the operational environment. If something goes wrong during a rollout, root cause analysis is more focused when it involves only one or two changes. More focused change management and root cause analysis minimize the process's effect on the overall system.
- Easier rollback if required. If a problem occurs that requires the platform to return to a previous known position, smaller changes mean less effort to carry out the rollback.
- Enhanced feedback loops. Small changes are easier for users and the help desk to deal with. When it comes to errors users pick up once the change has gone live, both the help desk and the development team should have less information to sift through to find the root cause.
What are the challenges of a CI/CD environment?
There are several challenges with a CI/CD approach that teams must address:
- Not everyone appreciates continuous change. Many changes that occur in CI/CD, such as changes to back-end databases or business processes, are invisible to the user. Other changes affect UX, such as renamed functions, moved menu-bar items and changes to established steps -- and users don't appreciate them. Any UX changes must be well communicated as soon as possible to the users. Where possible, provide in-line, on-screen guidance. With CI/CD, the help desk is sometimes barely notified of changes about to occur and may struggle to deal with user questions or complaints. Involve the help desk with the overall CI/CD process, and let staff see and comment on changes before they go live.
- Changes create a domino effect within a microservices environment. In a microservices environment, one small change can impact multiple different interactions. Configuration management tools can track all dependencies between different microservices, and orchestration can then help to ensure that any change does not impact other streams and that development teams can roll back changes if necessary.
- Continuous change requires continuous monitoring and reporting. CI/CD changes, by nature, affect the platform to which they are rolled out. Real-time monitoring and reporting are necessary to understand and quickly address any problems. If a change causes problems, teams need to know immediately -- before problems cascade across other services and user complaints swamp the help desk.
- Resource management must be responsive. Without deep testing beforehand, developers and testers may not anticipate the resource and performance effects of a CI/CD change until it is rolled out. To avoid unforeseen resource issues, apply as much automation as possible to prepare and provision workloads agnostically, using recipes and manifests, along with orchestration tools that define how to push workloads out to the organization's platforms.
Is CI/CD a good fit for your business?
CI/CD, as with DevOps as a whole, cannot be seen as a simple one-way process from the business through development to operations. At each stage, feedback loops must be in place to determine the following:
- Is the change requested technically feasible?
- Is it cost-effective at the development stage?
- Are there simple adjustments that address the issue without the need for a change to UX?
- Does the change require more hardware investment to provide sufficient resources?
- Are the users happy with the result of the changes?
- Can the help desk provide effective feedback to developers -- and to the business -- about how effective the change has been?
CI/CD can alter how IT supports the business by providing much faster and more effective changes to an environment. However, it is no silver bullet. Teams must add it and operate it with care, or else it introduces a new layer of chaos.
CI/CD best practices
If CI/CD is a good fit, it is important to ensure that it is supported by a suitable set of policies and procedures. These should include the following:
- Continuous feedback. The core premise of CI/CD is that it is responsive to the business's needs. As such, ensuring that the help desk and the greater line-of-business community is tightly integrated into issue reporting and functionality improvement requests is a necessity.
- Automated testing. Improvements in tools mean that testing should require minimal manual interventions. Teams can use scripts repeatedly to check that changes have not affected other functionality in the overall platform. Even with brand-new functionality, teams can also use AI to create automated test scripts.
- Version management. Just because teams move away from a Waterfall approach to CI/CD does not mean that they should do away with version control. Indeed, each change requires its own component versioning. This is so that teams can manage rollback of any component efficiently and maintain documentation.
- Documentation. With a Waterfall approach, teams generally maintain documentation on a version/subversion level. With CI/CD, this is not a good way to approach the issue. Instead, each component must be documented as to what it does, which other components it affects at a functional level, and what approaches teams have taken to fix issues.
Clive Longbottom is an independent commentator on the impact of technology on organizations. He was a co-founder and service director at Quocirca, as well as an ITC industry analyst for more than 20 years. Trained as a chemical engineer, he worked on anti-cancer drugs, car catalysts and fuel cells before moving to IT.