7 Continuous delivery and branching models

 

This chapter covers

  • Designing delivery pipelines to avoid pushing failures to production systems
  • Choosing a branching model for infrastructure configuration for team collaboration
  • Reviewing and managing changes to infrastructure resources within your team

In the previous chapters, you learned how to write patterns for modules and dependencies. You also applied some general practices for writing infrastructure as code and sharing modules. The patterns, practices, and workflows had a lot of steps.

Furthermore, many of the workflows require careful coordination of changes. One day, you might try to make a change only to find out that your teammate’s updates might overwrite yours! How do you make sure you manage conflicts during the development process?

One solution involves submitting change requests to a ticketing system. For example, if you want to change a server, you’d need to fill out a change request in your ticketing system. This change request then gets reviewed by your peers (usually your team) and the change advisory board (on behalf of the company).

Most companies use this process, called change management, to figure out which changes conflict. Infrastructure change management involves submitting a change request detailing rollout and rollback steps for peer reviewers’ approval.

7.1 Delivering changes to production

7.1.1 Continuous integration

7.1.2 Continuous delivery

7.1.3 Continuous deployment

7.1.4 Choosing a delivery approach

7.1.5 Modules

7.2 Branching models

7.2.1 Feature-based development

7.2.2 Trunk-based development

Summary