Working with Git branches in Continuous Delivery for PE
Continuous Delivery for PE is designed to watch for Puppet code changes you make in Git and help you deploy those changes to your environment node groups. You and Continuous Delivery for PE work together, so it's important to understand what to do in Git, and what Git work Continuous Delivery for PE handles for you.
Continuous Delivery for PE automates management of Git branches for Puppet environments, letting you focus on Git workflows for developing and deploying changes to your code.
You and your team own the main branch in Git, as well as any other development-focused branches you create, such as feature, hotfix, or release branches. In simple Git workflows, the main branch is designated as the branch to file pull requests against, tag releases off of, and treat as the leading edge of new development.
It is also your responsibility to create new environment branches when you first set up environment node groups. Environment branches are long-lived Git branches used to control which version of code is made available in corresponding Puppet environments. Continuous Delivery for PE owns environment branches after they're created, deploying changes to them and keeping them up to date. You and your team won't make changes to these branches directly, because manual changes to environment branches get overwritten whenever an automated deployment occurs.
While you focus on making commits to the main branch and getting pull requests merged, Continuous Delivery for PE works in your environment branches on your behalf, making sure your commits or changes are tested, deployed, and promoted to your environment node groups in accordance with the control repo pipelines you create and your manual deployment directives.
Continuous Delivery for PE also uses a small set of Git branches for bookkeeping, which are not part of the standard Git process. These branches are visible to users, but should be protected so that users cannot modify them. Continuous Delivery for PE manages these bookkeeping branches automatically.
Organizing Puppet content in your source control repository
Most of the Puppet content that developers interact with is infrastructure-as-code, which is versioned and committed to a Git source-control repository.
- A main branch that tracks the latest developing code
- Tags to identify meaningful code versions
- Short-lived "feature" branches that are created and deleted as part of the code development lifecycle
A control repo is a hub for Puppet configuration content. In its purest form, that's all it is. More typically, however, the control repo serves as a hub for modularized content, and also contains some directly embedded content. Typically, the embedded content includes the "role" module, the "profile" module, and Hiera data. (In a pure control repo, this content is modularized rather than embedded.)
The control repo contains a Puppetfile. The Puppetfile is the switchboard or ledger that makes the control repo a hub. It is a file that enumerates all of the modular content Puppet will incorporate and make available. Reading the Puppetfile should convey a good sense of all the Puppet content being used at a given site or Puppet implementation.
Depending on how much content has been embedded in the control repo, it might also contain a small handful of Puppet configuration files, and possibly some directories for the embedded content.
Puppet module repos
A Puppet module is a collection of content laid out in a particular way. A module can contain desired state code, Bolt tasks or plans, Puppet extensions, or a variety of other things. The module is the standard content container for everything Puppet.
Puppet knows how to consume modules automatically,
provided they are placed somewhere in its
Other "non-module" repos
It's sometimes useful to partition off certain types of Puppet for development purposes, even if the content is not technically a Puppet module. The prime example of this is Hiera data. Hiera data can be kept in a dedicated Git repository and evoked by the control repo using the Puppetfile, just like any standard Puppet content.
Other use cases for carving off non-module Git repositories exist, but they are rare. The commonality is that all such content will be committed to a Git repository and be referenced in the control repo's Puppetfile.
Puppet typically doesn't consume non-module content automatically, and correct consumption of this content requires some kind of configuration in one of the control repo's configuration files.