Understanding the Continuous Delivery for PE workflow

Continuous Delivery for Puppet Enterprise (PE) enables you to deliver change to your organization's infrastructure-as-code. Use the workflow outlined here to develop and deploy changes with Continuous Delivery for Puppet Enterprise (PE).

Tip: Before you begin, review Working with Git branches in Continuous Delivery for PE.

Workflow phase 1: Developing changes

The high-level process for developing a change is always the same regardless of whether the content is in the control repo, a module repo, or a non-module repo. The change development process is driven through Git.

Here's the high-level process for developing a change:

Using Git, create a feature branch from the master branch. This feature branch is where you'll develop your change.
Work on your change. Edit files, run tests, and do anything else necessary in order to realize, in code, the change you want to make. The details of what files you edit and how you test your change locally will vary depending on which kind of content you're working on.
Using Git, commit all the files you've changed to your feature branch. You may be committing frequently as you iterate, or you may not commit until you're fully satisfied with your work. How much you like to involve (or not involve) Git in your process up to this point is totally up to you.
Submit a pull/merge request to have your feature branch merged into master.
Assuming whatever CI or process requirements your organization uses are satisfied, you or someone else merges your feature branch into master. Once the merge is complete, your change is now available and ready to be put on the path to production, and you can safely delete your feature branch.

At this point your change is finished, as it has been merged into the master branch. Note that a finished change is not the same as a deployed change; a finished change is a change ready to be tested and deployed using the deployment process described below.

A note on continuous integration

When you submit a pull/merge request against a Puppet content repo (a control repo, a module repo, or a non-module repo), the continuous integration (CI) pipeline configured in Continuous Delivery for PE for that content repo runs and reports back success/failure results in your pull/merge request.

Pipelines in Continuous Delivery for PE are not cleanly separated into CI and CD. Instead, you see a single contiguous pipeline. However, it is a fair approximation to say that everything in a Continuous Delivery for PE pipeline that occurs before a special marker called the Pull Request Gate is the CI portion of the pipeline, and is (usually) focused on validating that proposed changes pass requisite acceptance tests or governance requirements.

The CI portion of a Continuous Delivery for PE pipeline therefore aids the development workflow.

Workflow phase 2: Deploying changes

Once a proposed change has been merged into the master branch of a Puppet content repo, the new content version (in the master branch) containing the change needs to be deployed.

In broad terms, to deploy a change means to select a version of content, select a target environment, and cause the selected change to take effect in the selected environment.

In Continuous Delivery for PE, this process looks like:

Pick a version.
Pick a target environment.
Optionally, set some deployment parameters.
Click "Deploy."

A version is any commit in the history of the master branch. There are no chronological requirements for picking a version to deploy. Deploying a version will neither change the contents of the master branch nor affect it in any way.

Environments

An environment is a target set of nodes to which content versions can be deployed. Environments are configured using Environment Node Groups in the PE console.

Note: See Create environment node groups for more information.

Per the definition of deploying above, environment node groups need to be configured as a prerequisite to deploying any content versions. At a minimum, the environment you want to target must be defined as an environment node group.

Some basic characteristics of defining environment node groups:

Each node can only belong to a single environment node group.
The environment node group can be named anything that makes sense to your organization.
The environment node group must be assigned a "Puppet environment."
- The functional importance of a "Puppet environment" relates to how Continuous Delivery for PE performs bookkeeping of the environment's content in Git (using the bookkeeping branches mentioned earlier).
- Each environment node group should be assigned a unique "Puppet environment" value. This ensures simple bookkeeping and that change deployments do not affect nodes they are not supposed to.

Deploying changes from control repos

The basic process:

Pick a version.
Pick a target environment.
Optionally, set some deployment parameters.
Click "Deploy."

Because a control repo contains a Puppetfile, which is the switchboard or ledger to which all modularized content is attached, how that modularized content is deployed in a target environment depends on the Puppetfile deployed to that environment.

Modularized content can be attached to a Puppetfile statically, such that the modularized content cannot be independently deployed or updated, or the content can be attached dynamically, so that the modularized content can be deployed independent of the control repo using a different Continuous Delivery for PE pipeline or deployment action.

If modularized content is defined statically in the Puppetfile, the only way to update it is to develop a change to the control repo itself, which modifies the Puppetfile to update the static module, and then deploy that change to the control repo.

Deploying changes from module repos

The basic process:

Pick a version.
Pick a target environment.
Optionally, set some deployment parameters.
Click "Deploy."

The inverse of the note about control repos above is that to be able to deploy module changes this way, the control repo version deployed to the target environment must have a Puppetfile that attaches this modularized content dynamically. If the target environment does not have such a Puppetfile, it is not possible to independently deploy the module changes.

Pipelines, or the path to production

Many organizations have a semi-linear sequence of target environments to which a change will be deployed—a sequence which terminates at the highest-value target environment. This final target is frequently called "production."

A pipeline in Continuous Delivery for PE is automation reflecting this sequence of deployments. It is a progression of deployments (and other actions) which, when triggered, will run in a defined manner, pausing, terminating, or continuing after each step as configured to by the pipeline creator.

The pipeline can contain many kinds of actions besides deployments. As mentioned in the "note on continuous integration" section above, the first part of a Continuous Delivery for PE pipeline up until the special Pull Request Gate step is typically CI validation and testing actions, rather than deployment actions. Deployment actions will usually not be placed in the pipeline until after this step.

The continuous element of a pipeline is in reference to what triggers it, or when it is run. Pipelines typically start automatically as soon as a new change has been merged to the master branch of a content repository.

Deployment pipelines typically deploy validated changes automatically up to some level lower than "production," but pause or wait for human approval before continuing to run and deploy to more sensitive, higher-tiered environments.