How CI/CD Pipelines Enforce Good DevOps Release Management

So far, you’ve learned that CI/CD is a key aspect of DevOps. Reusable, purpose-built CI/CD platforms maximize the value of each developer’s time. CI/CD improves an organization’s productivity by increasing efficiency and streamlining workflows by becoming a confluence of automation, testing, and collaboration. Additional DevOps enhancements, such as shifting left and creating tighter feedback loops, help enterprises dissolve silos, scale efficiently, and realize business value quicker than other release management methods.

Today’s release managers must be fluent in CI/CD procedures, DevOps, and automated deployment technologies. They need to be able to recognize problems at an early stage and have an understanding of how the CI/CD pipeline operates, which is essential to DevOps release management. In this chapter, we’ll discuss how CI/CD pipelines enforce good DevOps release management...

Understanding CI/CD governance

Implementing governance in DevOps release management requires establishing an assortment of procedures aimed at creating oversight mechanisms within CI/CD infrastructure. This paradigm frequently incorporates a blend of access control management, compliance policies, automated testing, and manual review checkpoints. The principal focus of DevOps governance necessitates advancing the objectives of operational security and establishing a comprehensive framework for monitoring, approving, and documenting all modifications to ensure traceability.

To be comfortable with CI/CD governance, you must have a comprehensive understanding of how CI/CD pipelines function. As you learned in the previous chapter, CI/CD pipelines encompass a sequence of automated workflows, systems, and methods that are specifically devised to facilitate the swift and dependable delivery of new code, starting from a developer’s workstation to the production environment. This...

Understanding branching strategies

The majority of contemporary version control systems offer support for branches, which are autonomous streams of work that originate from a core code base. The nomenclature for the primary branch in a version control system may vary, with possible designations including master, mainline, default, and trunk, depending on the specific system in use. Developers can generate branches derived from the source, therefore enabling them to function autonomously in conjunction with it.

The practice of branching facilitates seamless collaboration across teams of developers within a unified code repository. When a software developer starts creating a branch inside a version control system, a duplicate of the code base is generated, capturing the state of the code at that specific moment in time. Modifications made to the branch do not have an impact on the other developers within the team, but this pattern is undoubtedly advantageous. However, it is not strictly...

Exploring release pipelines

A release pipeline is a workflow or a collection of steps that are undertaken to guarantee the swift implementation of recently delivered code. Fundamentally, a well-built release pipeline makes delivery to production quick, easy, and reliable.

The exact stages of a release pipeline are different for each organization and product, but they often follow one another linearly. Notably, a more complex pipeline design may include steps that can be executed in parallel. This trend has become more popular in recent years due to the strategic advantages that parallel processing provides, but also because contemporary tooling has advanced well enough to make this functionality easier to implement without extensive scripting.

Typically, releases are triggered by an event, such as a code commit, although there are instances where the release might be explicitly initiated or scheduled in advance. You may also wish to automate the execution of your pipeline until...

Understanding change management

Digital services follow a life cycle that must be managed, and most organizations accomplish this through a set of dedicated change management processes. These actions commonly serve as the first line of defense toward mitigating the potential negative effects a change might have on operations and security.

To facilitate the implementation of changes throughout the system, change management methods typically involve obtaining clearance from external reviewers or change control boards (CCBs). To validate compliance requirements, compliance managers and security managers rely heavily on change management processes to certify an entity’s compliance. This is why you must maintain an aggregate log of all changes based on detailed records to unambiguously certify your build and release process, along with any other compliance requirements. Most notably, many industry regulatory requirements often demand evidence that any modifications made are duly...

Summary

This marks the conclusion of Chapter 8. After reading and comprehending the contents of this chapter, you should now have a reliable blueprint in your mind to draw from as you begin conducting your initiatives regarding the development and implementation of governance, a branching strategy, release pipelines, and change management.

As you’ve seen, by architecting your CI/CD infrastructure to automatically enforce these tenets, you minimize the risk of human error and burnout. The implications for this should not be taken lightly as we are not replacing or watering down governance, branching strategies, release pipelines, and change management in our organizations. Rather, we are baking them into the cake. This means that these duties must still be thoroughly implemented and enforced as before, but through the various oversight mechanisms that can be implemented in the configurations of your CI/CD pipelines.

In the next chapter, we’ll discuss effective strategies...

Questions

Answer the following questions to test your knowledge of this chapter:

1. What are each of the OWASP Top 10 CI/CD Security Risks?
2. What are the three common paths to CI/CD governance?
3. What is the significance of mapping CI/CD systems and processes? What term described this process?
4. What are the four most common branching strategies used by development teams today?
5. What is the difference between trunk-based development and scaled trunk development?
6. Which of the four branching strategies described in this chapter promote feature-driven development?
7. What is the difference between a release pipeline and a deployment pipeline?
8. What is the difference between an artifact store and a configuration store?
9. Why are external CCBs and CABs frequently cited as an anti-pattern in the context of DevOps release management?
10. Why is it considered good practice to implement methods that move validation steps into the development platform?