Understanding the Continuous Delivery for PE workflow

Continuous Delivery for Puppet Enterprise (PE) helps you to deliver changes to your organization's infrastructure-as-code. Use this workflow to develop and deploy changes with Continuous Delivery for PE.

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

Workflow phase 1: Developing changes

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

This is the general change development process:
  1. Using Git, create a feature branch from the main branch. This feature branch is where you'll develop your change.
  2. Work on your change. Edit files, run tests, and do anything else necessary to actualize, in code, the change you want to make. Which files you edit and how you test your change locally depends on the kind of content you're working on.
  3. Using Git, commit all the files you've changed to your feature branch. You may commit frequently as you iterate, or you may not commit until you're fully satisfied with your work. It's up to you how much you involve Git in your process up to this point.
  4. Submit a pull/merge request to merge your feature branch into the main branch. This may trigger a Continuous Delivery for Puppet Enterprise (PE) pipeline run (see Note on continuous integration, below).
  5. After following your organization's CI or review process, you or someone else merges your feature branch into the main branch. Once the merge is complete, your change is ready to be put on the path to production, and you can safely delete your feature branch.
Important: Once merged into the main branch, your change is finished. However, a finished change is not the same as a deployed change. Finished changes are ready to be tested and deployed using the deployment process described in Workflow phase 2: Deploying changes.

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 Puppet Enterprise (PE) for that content repo runs and reports any success or 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 continuous pipeline. However, generally, everything in a Continuous Delivery for PE pipeline that occurs before 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 is merged into the main branch of a Puppet content repo, it is time to deploy the new content version (containing your change) from the main branch.

Generically, deploying a change involves selecting a version of content, selecting a target environment, and applying the selected change to the selected environment. To do this in Continuous Delivery for Puppet Enterprise (PE), you:
  1. Pick a version.
  2. Pick a target environment.
  3. Optionally, set some deployment parameters.
  4. Click Deploy.

A version is any commit in the history of the main branch. There are no chronological requirements for picking a version to deploy. Deploying a version does not change the contents of the main branch or affect it in any way.

Environments

An environment is a set of nodes to which a content version can be deployed. You configure environments by creating environment node groups in the PE console. You must configure environment node groups prior to deploying any content versions. At minimum, the environment you want to target must be defined as an environment node group.

When defining environment node groups:
  • Each node can only belong to a single environment node group.
  • You can name the environment node groups anything that makes sense to your organization.
  • Each environment node group must be assigned a unique Puppet environment value. Functionally, this relates to how Continuous Delivery for PE performs bookkeeping of the environment's content in Git (using the bookkeeping branches mentioned in Working with Git branches in Continuous Delivery for PE). Unique values ensure simple bookkeeping and that deployments do not affect nodes they are not supposed to.

Deploying changes from control repos

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

Modularized content can be attached to a Puppetfile in two ways:
  • Statically: Modularized content cannot be independently deployed or updated.
  • Dynamically: Modularized content can be deployed independent of the control repo using a different Continuous Delivery for PE pipeline or deployment action.

Static content can only be updated by developing a change directly in the control repo (as opposed to a module repo), which modifies the Puppetfile to update the static module and deploy the change to the control repo.

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

Deploying changes from module repos

To be able to deploy module changes from module repos, the control repo version deployed to the target environment must have a Puppetfile that defines 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 is deployed, terminating at the highest-value target environment. This final target is frequently called production.

Continuous Delivery for PE pipelines use automation to reflect this deployment sequence. Pipelines are a progression of deployments and other actions that, when triggered, run in the defined manner configured by the pipeline creator, including pauses, termination, or continuation after each step.

Pipelines can contain actions other than deployments. As mentioned in Note on continuous integration, the first part of a Continuous Delivery for PE pipeline up to the pull request gate is typically CI validation and testing actions, rather than deployment actions. Deployment actions are usually not be placed in the pipeline until after the pull request gate.

Pipelines are considered continuous because of when they run or how they are triggered. Usually, pipelines automatically start when new changes are merged to the main branch of a content repository (or when a pull request is submitted to the main branch).

It is common for deployment pipelines to automatically deploy validated changes to some pre-production environments, and then pause or wait for human approval before continuing to deploy to more sensitive, higher-tiered environments.