continuous deployment 9 CI/CD best practices for DevOps teams

The pros and cons of CI/CD pipelines

Many enterprises begin their DevOps journey with a continuous development and delivery pipeline. Before you get started, understand some fundamental CI/CD pros and cons.

Continuous integration and continuous delivery are central to DevOps-driven organizations. CI means teams frequently update and reintroduce code, while CD applies further tests to ensure it is ready to be checked in for deployment. Combined as a CI/CD feedback loop, they enable continuous upgrades to the DevOps environment and faster response to the organization's and users' needs, compared with a Waterfall approach, which involves large changes at potentially extended intervals.

At a high level, CI/CD makes perfect sense: Developers prioritize organizational demands as discrete changes and quickly move them to the operations environment, with sufficient checks and balances in place to ensure a smooth transition. However, there are several areas an organization must consider before it buys into a CI/CD approach.

What are the benefits of a CI/CD environment?

Let's look at the main benefits to a CI/CD process.

  • More responsive development. Many organizations that strive to deliver and operate at real-time speed are often hampered by slower traditional app development. With CI/CD, developers can rapidly prioritize and address each organizational need. This also requires a close relationship with the business side to prioritize areas with the biggest potential business impact, rather than what developers may view with higher technical preference.
  • Better code quality. Smaller changes involve less code, and code quality can be checked to a greater degree before it reaches a full testing environment. Developers can more easily identify and solve problems earlier in the DevOps process. Code quality is still important, however -- CI/CD does not mean you can cut corners in the interests of speed.
  • Shorter testing cycles. Less complex and smaller volumes of code to check means there's less need to repeatedly test functionality throughout the CI/CD process. New functionality created by the development community gets out into the operational environment far faster than with full retro-testing of mass changes. Again, this does not mean you should take any testing shortcuts -- only that a well-run CI/CD approach involves fewer interactions between what is changed and what remains the same.
  • Easier monitoring of change in the operational environment. If something goes wrong during a rollout, it is usually far easier to identify the root cause when it involves only one or two changes. However, the right tools must be in place to ensure that monitoring is sufficient and effective.
  • 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. Again, ensure the right tools are in place, especially an effective orchestration tool.
The continuous development and continuous delivery pipeline.
The process of continuous integration and continuous delivery, from code commits and builds, through various stages of tests, to automated delivery and deployment.

What are the disadvantages of a CI/CD environment?

There are several challenges with a CI/CD approach that you must address.

  • Not everyone appreciates continuous change. Many changes that occur in CI/CD, such as ones to back-end databases or business processes, are invisible to the user. Other changes impact the UX, such as renamed functions, moved menu-bar items and changes to established steps -- and users won't appreciate them. Any UX changes must be well communicated as soon as possible to the users, and where possible provide in-line, on-screen guidance. With cascade development, an organization can train the help desk (as well as users) about all the upcoming changes. With CI/CD, the help desk is sometimes barely notified of changes about to occur, and may struggle to deal with questions (or complaints) from the user base. 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 with a microservices environment. With CI/CD in a microservices environment, one small change can impact multiple different interactions. A change may work well for the intended microservices process, but it could cause problems within other service chains. Configuration management tracks 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 their nature impact 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 misbehaves, you 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 any resource and performance hits 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 that define how to push workloads out to the organization's platforms. Again, orchestration tools can help continuously monitor what is happening across IT platforms and automatically take corrective actions -- assign more resources such as compute or memory, throttle activity, reallocate or spin up or shut down an instance of the microservice/app, or raise a flag for manual intervention.

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 ascertain:

  • Is the change requested technically feasible? Is it cost effective at the development stage?
  • Will the change require more hardware investment to provide sufficient resources?
  • Are the users happy with the result of the changes, or are there simple adjustments that will improve the new functionality's effectiveness or acceptance?
  • 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; it must be added and operated with care, or else it will introduce a new layer of chaos.

Dig Deeper on Software development lifecycle

Cloud Computing
App Architecture