Working with Git branches in Continuous Delivery

Continuous Delivery watches for Puppet code changes you make in Git and helps you deploy those changes to your environment node groups. You and Continuous Delivery work together, so it's important to understand what you need to do in Git, and what Git work Continuous Delivery handles for you.

Continuous Delivery 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 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 main branch and merging pull requests, Continuous Delivery 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 directives.

Continuous Delivery 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 manages these bookkeeping branches automatically.

GitLab users: Pull request is another term for merge request. For the sake of simplicity and consistency, the term pull request (PR) is used in the Continuous Delivery web UI and documentation.

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.

When using Continuous Delivery, every Git repository, regardless of its type or contents (control repo or module), works the same way and has the same key components:

  • 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.
There are many Git 101 tutorials online that describe how to interact with standard Git repositories of this type and explain the basic branching and merging process.

Required repository permissions vary by source control provider, and these are configured when you Integrate with source control.

Control repos

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.

Visit the PE documentation for more information about Managing environment content with a Puppetfile.

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 modulepath.

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.

Typically, Puppet doesn't consume non-module content automatically; therefore, correct consumption of this content requires some kind of configuration in one of the control repo's configuration files.