Built-in deployment policies
Deployment policies are prescriptive workflows for Puppet code deployment that are built into Continuous Delivery for Puppet Enterprise (PE). You select the best deployment policy for your situation, and Continuous Delivery for PE does all the Git heavy lifting for you, deploying your code to the right nodes.
Which deployment policy should I use?
Continuous Delivery for PE includes built-in deployment policies, each with a different branching workflow. Use the table below to select the best deployment policy for your circumstances.
Deployment policy | Best for... |
---|---|
Direct deployment policy |
|
Temporary branch policy |
|
Eventual consistency policy |
|
Feature branch policy |
|
Direct deployment policy
The direct deployment policy is the most basic of the four deployment policies offered in Continuous Delivery for PE. This policy is best to use if you wish to deploy a certain commit to a specified environment, then run Puppet on that environment (and only that environment) to deploy your changes.

When you kick off a deployment using the direct deployment policy, Continuous Delivery for PE performs the following steps.
Step 1: puppet-code deploy
Using Code Manager, Continuous Delivery for PE
synchronizes the selected code change with your PE
instance by running puppet-code deploy
on Puppet Server.
Step 2: Temporary environment group
Continuous Delivery for PE creates a new environment group that's a child of the node group you selected when setting up your deployment. The child node group inherits all the rules, configuration settings, and variables of its parent node group. A Puppet Query Language query pins all the nodes associated with the parent node group to the child node group.
This environment node group is temporary; when the deployment is complete, it is automatically deleted. It's likely that you won't ever need to interact directly with this environment group.
Step 3: Running Puppet
Continuous Delivery for PE uses the orchestrator to kick off a Puppet run on the nodes in the child node group. The orchestrated Puppet run updates nodes as quickly as the concurrency limits of Puppet Server allow. You can monitor the progress of this process on the deployment details page in the Continuous Delivery for PE web UI.
Step 4: Clean-up
When the Puppet run is complete, Continuous Delivery for PE deletes the child environment group and moves the HEAD of your target branch in your source control repository to the commit you chose to deploy.
Direct deployment policy parameters
.cd4pe.yaml
file as part of a deployment
step type declaration. Parameter | Description | Required? | Default value | Value type |
---|---|---|---|---|
max_node_failure |
The maximum number of nodes that can fail before the deployment is stopped and reported as a failure. | no | - | integer |
noop |
Whether to perform the Puppet runs in no-op mode. | no | false | Boolean |
fail_if_no_nodes |
Whether to stop the deployment and report a failure if the selected node group does not contain any nodes. | no | false | Boolean |
Temporary branch policy
During a deployment using the temporary branch policy, Continuous Delivery for PE creates a temporary Git branch containing the code you wish to deploy, and a temporary environment group containing the nodes you're deploying code to. Your new code is then mapped to the temporary environment group in batches, allowing you to be certain that your new Puppet code works with each node before the changes are deployed to the full environment.

When you kick off a deployment using the temporary branch policy, Continuous Delivery for PE performs the following steps.
Step 1: New branch
Continuous Delivery for PE creates a new branch in your source control repository with the commit you've selected at its tip. This branch is temporary; when the deployment is complete, it will be automatically deleted. It's likely that you won't ever need to interact directly with this temporary branch.
Step 2: puppet-code deploy
Using Code Manager, Continuous Delivery for PE
synchronizes the code changes with your PE instance by running puppet-code deploy
on Puppet Server.
Step 3: Temporary environment group
Continuous Delivery for PE creates a new environment group that's a child of the node group you selected when setting up your deployment. The child node group inherits all the rules, configuration settings, and variables of its parent node group. A Puppet Query Language query pins all the nodes associated with the parent node group to the child node group.
This environment node group is temporary; when the deployment is complete, it is automatically deleted. It's likely that you won't ever need to interact directly with this environment group.
Step 4: Running Puppet
Continuous Delivery for PE uses the orchestrator to kick off a Puppet run on the nodes in the child node group. Puppet runs on a few nodes at a time, based on the stagger settings you specified when setting up the deployment. You can monitor the progress of this process on the deployment details page in the Continuous Delivery for PE web UI.
Step 5: Clean-up
When all the Puppet runs have completed successfully (or in the event that the termination conditions you specified are met), Continuous Delivery for PE deletes the child environment group, moves the HEAD of the target branch in your source control repository to point to your chosen commit, and deletes the temporary Git branch created at the beginning of this process.
Temporary branch deployment policy parameters
.cd4pe.yaml
file as part of a deployment
step type declaration. Parameter | Description | Required? | Default value | Value type |
---|---|---|---|---|
batch_delay |
How many seconds to wait between each deployment batch. | no | 60 | integer |
batch_size |
How many nodes to include in a deployment batch. | no | 10 | integer |
max_node_failure |
The maximum number of nodes that can fail before the deployment is stopped and reported as a failure. | no | - | integer |
noop |
Whether to perform the Puppet runs in no-op mode. | no | false | Boolean |
fail_if_no_nodes |
Whether the deployment should fail if there are no nodes in the target node group or environment. | no | true | Boolean |
Eventual consistency policy
The eventual consistency policy is designed for situations in which you wish to deploy new Puppet code, but prefer to wait for nodes to check in on their regular schedule to pick up the changes, rather than kicking off a dedicated Puppet run with the orchestrator. By using this policy, impacted nodes all eventually reach consistency with the new code.
When you kick off a deployment using the eventual consistency policy, Continuous Delivery for PE performs the following steps:
Step 1:
puppet-code deploy
Using Code Manager, Continuous Delivery for PE synchronizes the selected code change with your PE instance by running puppet-code deploy
on Puppet Server.
Step 2: Code changes are implemented during the next round of scheduled Puppet runs
The new code is delivered to the impacted nodes the next time they check in according to their established schedule.
Eventual consistency deployment policy parameters
The eventual consistency deployment policy does not have any optional or required policy parameters.
Feature branch deployment policy
The feature branch deployment policy is used only in regex branch pipelines. Code changes you've made in a feature branch are deployed to a Puppet environment with the same name as the feature branch.
When you kick off a deployment to a regex branch pipeline using the feature branch deployment policy, Continuous Delivery for PE performs the following steps:
Step 1:
puppet-code deploy
Using Code Manager, Continuous Delivery for PE deploys the commit in the pipeline to a Puppet environment with the same name as the branch that triggered the pipeline. If an environment with this name doesn't already exist, Continuous Delivery for PE creates it during the deployment.
Feature branch deployment policy parameters
The feature branch deployment policy does not have any optional or required policy parameters.