Working with Git branches in Continuous Delivery for PE
Continuous Delivery for Puppet Enterprise (PE) watches for Puppet code changes you make in Git and helps you deploy those changes to your environment node groups. You and Continuous Delivery for PE work together, so it's important to understand what you need 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 create pull requests against, tag releases off of, and treat as
the leading edge of new development.
You must create new environment branches when you first set up environment node groups. Environment branches are long-lived Git branches that control which code version is available in corresponding Puppet environments. Continuous Delivery for PE owns environment branches after you create them; it deploys changes to them and keeps them updated. You and your team don't change these branches directly because manual changes to environment branches are overwritten when an automated deployment occurs.
While you focus on committing to the
and merging pull requests, Continuous Delivery for PE works in your
environment branches on your behalf. It makes sure your commits or changes
are tested, deployed, and promoted to your environment node groups in
accordance with your control repo pipelines and your manual deployment
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, and must 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 Puppet content that developers interact with is infrastructure-as-code, which is versioned and committed to a Git source-control repository.
- A main branch tracking the latest developing code.
- Tags to identify meaningful code versions.
- Short-lived feature branches created and deleted during the code development lifecycle.
Required repository permissions vary by source control provider, and these are configured when you Integrate with source control.
In its purest form, a control repo is a hub for Puppet
configuration content. Usually, however, the control repo serves as a hub for
modularized content and contains some directly embedded content. Typically, 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, which is the switchboard or ledger that makes the control repo a hub. The Puppetfile is a file that enumerates all of the modular content Puppet incorporates and makes available. Reading the Puppetfile can convey a good sense of all the Puppet content being used at a given site or Puppet implementation.
Depending on how much content is embedded in the control repo, the control repo might also contain some Puppet configuration files and possibly some directories for 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. Modules are 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
Sometimes it's useful to partition off certain types of Puppet content for development purposes, even if the content is not technically a Puppet module. A 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.
There are other use cases for partitioning non-module Git repositories, but they are rare. The commonality is that all such content is committed to a Git repository and referenced in the control repo's Puppetfile.