5 Structuring and sharing modules

 

This chapter covers

  • Constructing module versions and tags for infrastructure changes
  • Choosing a single repository versus multiple repositories
  • Organizing shared infrastructure modules across teams
  • Releasing infrastructure modules without affecting critical dependencies

Up to this point in the book, you’ve learned practices and patterns for writing infrastructure as code and breaking them into groups of infrastructure components. However, you can write the most optimal configurations but still have trouble maintaining and mitigating the risk of failure to your systems. The difficulties happen because your team does not standardize collaboration practices when updating infrastructure modules.

Imagine a company, Datacenter for Veggies, starts by automating its growing operations for herbs. Applications in GCP monitor and adjust for optimal herb growth. Each team uses the singleton pattern and creates a unique infrastructure configuration.

Over time, Datacenter for Veggies becomes more popular and wants to expand to all vegetables. It hires a new application development team specializing in software for growing various vegetables, from herbs to leafy greens to root vegetables. Each team creates an infrastructure configuration independent of the others.

5.1 Repository structure

5.1.1 Single repository

5.1.2 Multiple repositories

5.1.3 Choosing a repository structure

5.2 Versioning

5.3 Releasing

5.4 Sharing modules

Summary