The document outlines a virtual workshop on Continuous Delivery for Puppet Enterprise held on April 30, 2020. It details the setup and integration of CD4PE, covering installation, user account creation, and the configuration of pipelines and job hardware, while emphasizing the importance of automation in managing code changes across teams. The workshop also discusses best practices for using service accounts, integrating with GitLab for source control, and managing deployment policies for effective code delivery.

1. Continuous Delivery
for Puppet Enterprise
Virtual Workshop
30 APRIL 2020

2. CD4PE WORKSHOP2
Continuous Delivery
for Puppet Enterprise

3. Code -any code- is best managed with CI/CD
CD4PE WORKSHOP3

4. Challenges of not having an automated workflow
CD4PE WORKSHOP4

5. CD4PE: the most powerful add-on to Puppet Enterprise
Everything you need when using Puppet at scale or across teams
• Automates the validation & testing of Puppet code changes
• For both control repos and modules
• Manages & streamlines version control (git) workflows for you
• Integrates natively with on-prem & cloud versions of Github, Gitlab, Bitbucket, Azure DevOps
• Integrates with Puppet Enterprise for controlled deployments & approvals
• Allows you to write custom deployments for bring-your-own-workflow
• Enables multi-tenancy within or across Puppet Enterprise installations
• Workspaces, protected environments requiring approval, fine-grained RBAC on modules
• Delivery vehicle for future additional plugins
CD4PE WORKSHOP5

6. Workshop setup
CD4PE WORKSHOP6
<workshopID>-gitlab
● 1 Control Repo per student
● 1 Module Repo per student
<workshopID>master0
<workshopID>cd4pe0
Teacher (me)
<workshopID>master1
<workshopID>cd4pe1
Student 1
<workshopID>master2
<workshopID>cd4pe2
Student 2
<workshopID>master3
<workshopID>cd4pe3
Student 3

7. CD4PE WORKSHOP7
Lab 1:
Installing CD4PE

8. Lab 1 - Logging in to Puppet Enterprise
• Student machine pairs
Puppet Enterprise: https://<workshopID>master<#>.classroom.puppet.com
CD4PE host: http://<workshopID>cd4pe<#>.classroom.puppet.com:8080
(CD4PE is not yet installed!)
• Example for workshop “wshop5” and student 3
Puppet Enterprise: https://wshop5master3.classroom.puppet.com
CD4PE host: http://wshop5cd4pe3.classroom.puppet.com:8080
• Credentials
Puppet Enterprise: admin / puppetlabs
• Assign yourself a student nr via the Google Sheet that the instructor has shared
CD4PE WORKSHOP8

9. Lab 1 - Installing CD4PE
1. Log in to your Enterprise Console (user: admin, password: puppetlabs)
2. Go to Classification, click Add Group… and create a PE Continuous Delivery group
3. Open the group and below Certname, select your
<workshopID>cd4pe<#>.classroom.puppet.com node and click Pin node
4. Navigate to the Configuration tab and add the cd4pe class.
5. Below the added class click Parameter name, select cd4pe_version, change the value
from “latest” to “3.x” and click Add parameter
6. On the bottom right, click Commit 2 changes and then run Puppet on the node by
going to the Matching nodes tab, clicking the cd4pe node, then clicking the Run
puppet… link at the top of the page and finally clicking the blue Run button.
CD4PE WORKSHOP9

10. CD4PE WORKSHOP10
Discussion Q’s
Why use a puppet module
instead of the simple Bolt task?
How can I upgrade to a newer
minor version of CD4PE later?

11. CD4PE WORKSHOP11
Lab 2:
CD4PE Setup Basics

12. Lab 2 - About setting up CD4PE
Once the docker container is running, it's time to set up your CD4PE instance. Most of the
configuration is done in CD4PE's graphical interface. The puppetlabs/cd4pe module has
already setup the core software components and their connections for you:
● Docker Community Edition
● PE PostgreSQL (same as the database edition used by PE itself)
● CD4PE container image, with a docker volume (cd4pe-object-store)
the rest of the configuration is up to you and done in the GUI.
First we're going to configure the root account, which is responsible for overall
management of the CD4PE instance. We will set up most of the basic settings here.
Then we're going to create a user account, and a corresponding workspace.
CD4PE WORKSHOP12

13. Lab 2 - Set up CD4PE root account
1. Browse to http://<workshopID>cd4pe<#>.classroom.puppet.com:8080
2. Click the friendly button to Get Started
3. You'll be asked to supply an email address and password for the root account
4. There is no email validation, so let’s all use root@classroom.puppet.com
5. Supply a password and write it down so you don’t lose it
6. Click to Create Root User
CD4PE WORKSHOP13

14. Lab 2 - Set up CD4PE basic endpoints & storage
1. Now you'll be asked to configure endpoints, which are all on your CD4PE host
with the default ports. Fill these in and save the settings:
● WebUI: http://<workshopID>cd4pe<#>.classroom.puppet.com:8080/
● Backend Service: http://<workshopID>cd4pe<#>.classroom.puppet.com:8000/
● Agent Service: dump://<workshopID>cd4pe<#>.classroom.puppet.com:7000/
2. Next is configuring storage, used for things like the content of jobs. We'll use the
default Disk option, which uses the docker volume, mapped to /disk in the container.
Click Save Storage Settings.
3. You'll be asked for a license. Tell it to run in Trial Mode.
4. Scroll down the license agreement and click Accept without consulting an attorney.
CD4PE WORKSHOP14

15. Lab 2 - Set up CD4PE user & workspace
Okay, we're almost there. We can now create a normal user account and a workspace. A
workspace is the area where a team integrates its own version control system, PE, control
repository, and modules. This way several teams can share a CD4PE infrastructure, but
only interact with their own resources.
1. Click to Create your user account
2. Fill in name, email, username, and password. As before, there is no email validation
so it's safe to set it to something fun like kermit@classroom.puppet.com
3. Click the button, to Sign Up
4. Since this is a new install, you'll need to click to + Add New Workspace
5. Give it any name you like, for instance muppet-show and click Create workspace
CD4PE WORKSHOP15

16. CD4PE WORKSHOP16
Discussion Q’s
Why is there a separate root
user and individual users?
Why might I want to use
multiple workspaces?

17. CD4PE WORKSHOP17
Lab 3:
Integrate with PE

18. Lab 3 - About integrating with Puppet Enterprise
CD4PE should use a service account when connecting to Puppet Enterprise. The account
needs to be able to deploy code, make node groups, assign nodes to them, run tasks for
jobs and run Puppet when a direct deployment policy is involved.
In the interest of time, we've setup a cd4pe user with password puppetlabs in PE. This
account already has all the necessary permissions. When you’re doing lab testing, you
could also use the default admin account for a quick setup. In a real environment, you
should use a restricted user account like we are doing in this workshop, with the minimal
permissions as documented here.
In this lab we will integrate CD4PE with Puppet Enterprise. We’ll also go back to the PE
console, to make another change needed to enable full Impact Analysis.
CD4PE WORKSHOP18

19. Lab 3 - Integrate with Puppet Enterprise
1. In your workspace, click the big Integrate Puppet Enterprise button up top
2. Click to Add Credentials, and name the instance puppet-enterprise
3. For the console address, simply supply puppet.classroom.puppet.com
4. Leave the radio box set to Basic Authorization
5. Supply the credentials for the admin account: cd4pe / puppetlabs
6. A token lifetime of 6 months is fine for the workshop, though you may prefer
significantly longer in a real production environment
7. Click Save Changes
8. CD4PE will now link with Puppet Enterprise
CD4PE WORKSHOP19

20. Lab 3 - Enabling full Impact Analysis (1/2)
In order for CD4PE Impact Analysis to fully function, we need to make a small change to
PE itself. Without this change, the impact of Hiera changes won’t be correctly detected.
1. Switch back to your Enterprise Console (user: admin, password: puppetlabs)
2. Go to Classification, click Add Group… and create a PE Impact Analysis group
3. Open the group and below Certname, select your puppet.classroom.puppet.com
node and click Pin node
4. Navigate to the Configuration tab and add the cd4pe::impact_analysis class.
5. On the bottom right, click Commit 2 changes and then run Puppet on
puppet.classroom.puppet.com (click the Matching nodes tab, click on the node
called puppet.classroom.puppet.com, then click the Run puppet… link at the top of the
page and finally click the blue Run button).
CD4PE WORKSHOP20

21. Lab 3 - Enabling full Impact Analysis (2/2)
7. The run should take a minute. It will make 4 changes, you can optionally check the run
report to verify.
After this change, we need all the nodes to run Puppet at least once, so that the system
can build a picture of all the Hiera data that each node uses. To do this:
8. Navigate to Puppet in the Run section of the left navigation bar.
9. In the Run Puppet screen, under Inventory, click Select a target type and choose
Node group. Click on the Enter a node group box, and select All Nodes (production),
then click Select.
10. Both our nodes should now show up. Click Run job on the bottom right hand side and
wait for the run to complete. No changes should be reported.
CD4PE WORKSHOP21

22. CD4PE WORKSHOP22
Discussion Q’s
Why bother with a cd4pe
service account in PE, instead
of just using the admin
account?
Why is Hiera change analysis
important?

23. CD4PE WORKSHOP23
Lab 4:
Integrate with Gitlab

24. Lab 4 - About integrating with Gitlab
CD4PE should use a service account when integrating with your source control server.
In the interest of time, we've pre-created student accounts in the GitLab instance, that
have access to all participants' repositories.
So please make sure you pick your own control & module repositories!
CD4PE WORKSHOP24

25. Lab 4 - Generate a Gitlab access token
1. Log in to https://<workshopID>-gitlab.classroom.puppet.com using the credentials
student<#> (substitute <#> with your own number), and the password puppetlabs
2. Click the user icon ( ) in the upper-right corner to expose the drop-down menu,
and click Settings
3. In the left-hand navigation, click Access Tokens
4. In the Name box, type something descriptive, like your name
5. In the Expires at box, set the expiration to anything beyond this week
6. Click the checkmarks for both api and read_user
7. Click the Create personal access token button
8. Copy the contents in the Your New Personal Access Token box at the top
CD4PE WORKSHOP25

26. Lab 4 - Integrate with Gitlab
1. In CD4PE, click the Integrate source control button at the top of the screen
2. Click GitLab
3. Set the Host to https://<workshopID>gitlab0.classroom.puppet.com (NO dash!)
4. Paste the access token that you just generated from GitLab
5. Click Add Credentials
6. CD4PE will validate that the credentials work, generate an SSH keypair for itself and
attach it to that user. You can check the SSH Keys section in Gitlab to verify.
7. After validation, you can click Done to dismiss the dialog.
CD4PE WORKSHOP26

27. CD4PE WORKSHOP27
Discussion Q’s
Why does CD4PE create an
SSH key for itself in GitLab, if
Code Manager is doing the
deploys to Puppet Enterprise?

28. CD4PE WORKSHOP28
Lab 5:
Adding Job Hardware

29. Lab 5 - About adding Job Hardware
In order to run tests, CD4PE needs to have a pool of "job hardware" with the capabilities
to run your tests. The built-in tests all run in Docker containers. You can make jobs that run
in Docker, on Linux, on Windows, or even on MacOS, but all the built-ins are Docker.
Since the CD4PE host already has docker on it -- running the CD4PE container -- it's
simplest to re-use that hardware as job hardware.
In production, use dedicated hosts as job hardware. A puppet profile can be used to make
sure any pre-required software (like Docker) is installed on those hosts.
CD4PE WORKSHOP29

30. Lab 5 - Add Job Hardware
1. In CD4PE, click the Set up job hardware button at the top of the screen
2. There is already 1 built-in capability: Docker. All we need to do is add a host to it.
3. Click the + Edit button to modify the hosts for the Docker capability
4. In the 2. Add hardware with this capability section, select the PE integration you
added earlier in Lab 3
5. Click the checkbox next to your CD4PE server (<workshopID>cd4pe<#>)
6. Click the Save button, then click Done
CD4PE WORKSHOP30

31. CD4PE WORKSHOP31
Discussion Q’s
Why might you need Job
hardware with a Windows
capability?
What risks might be associated
with re-using the CD4PE host
as job hardware?

32. CD4PE WORKSHOP32
Lab 6:
Adding a Control Repo

33. Lab 6 - About adding a Control Repo
Now that you've got all of your services integrated, it's time to aim CD4PE at your personal
control repository. CD4PE is helpful enough to query GitLab using the service account we
provided, and list all the repositories your account has access to. It's going to be a long
list, so make sure you pick the one that's named with your participant number.
Unlike with Code Manager, you don't have to add a webhook manually. CD4PE is going to
do it for you when it adds the control repository in the GUI.
CD4PE WORKSHOP33

34. Lab 6 - Add your Control Repo
1. Click the Add control repository button at the top of the screen
2. Click the Add Control Repo button and select GitLab in the list
3. Choose the puppet organization
4. Scroll to your control repo, named control-repo-<#> (again <#> is your own number)
(Note: select the control repo, NOT the module repo)
5. Leave Branch set to master
6. Change the name of the control repo to: control-repo
7. Click Add
CD4PE WORKSHOP34

35. CD4PE WORKSHOP35
Discussion Q’s
Why might you want to
integrate with more than one
control repository?

36. CD4PE WORKSHOP36
Lab 7:
Adding a default pipeline

37. Lab 7 - About adding a default pipeline
Once you have a control repository configured for your workspace, you can add pipelines
to automatically validate and deploy code in response to events in your VCS. (A webhook
was automatically added for you, when you integrated the control repository into your
workspace.)
You will (over the course of several labs) add 2 pipelines to your control repository:
1. A master pipeline, which is triggered when either there is a push to the master
branch, a pull request into your master branch, or a pull request is merged.
2. A regex pipeline, which is triggered when a certain branch name is created/updated.
CD4PE manipulates branches that correspond to environments, much like you are used to
doing already. Before it can manipulate them, they need to exist. We've already created
these branches (development & production) for you, in the control & module repos.
CD4PE WORKSHOP37

38. Lab 7 - Add a default pipeline for the master branch (1/2)
1. Click the + Add default pipeline button on the right hand side
2. On the bottom of the pipeline, click + Add a deployment
3. Under Select a node group, click Development environment
4. Under Select a deployment policy, click Direct deployment policy
5. Leave the defaults unchanged and click Add Deployment to Stage
6. Click + Add another stage after Deployment stage
CD4PE WORKSHOP38

39. Lab 7 - Add a default pipeline for the master branch (2/2)
7. Under Stage name, enter Deploy to Production
8. We want to add a Deployment, which is the default item to add, so leave that as-is
9. Under Select a node group, click Production environment
10. Under Select a deployment policy, click Eventual consistency policy
11. Leave the defaults unchanged and click Add Stage, then click Done
12. Click the checkbox next to Auto promote between the Impact Analysis stage and the
Deployment stage, so that this stage will automatically run after Impact Analysis.
CD4PE WORKSHOP39

40. Lab 7 - Results
Your pipeline should now look like the image on the right.
Let’s also have a look at what the deployment policies do...
CD4PE WORKSHOP40
Direct deployment &
Eventual consistency:
Temporary branch:

41. CD4PE WORKSHOP41
Discussion Q’s
Why is it more likely to use
Eventual Consistency deploys
to production?
Why would you typically not
auto-promote to production?

42. CD4PE WORKSHOP42
Lab 8:
Running the pipeline

43. Lab 8 - About running the pipeline
We now have a basic pipeline ready to go, let’s make a simple change in our control repo
and see what happens in CD4PE when the change is committed.
What we expect to happen:
1. All code in the control repo is validated to ensure there are no syntax errors
2. An Impact Analysis is performed of both the Development and Production
environments (we can change this to just one environment for increased speed)
3. The change is deployed to the Development environment
4. Nothing happens yet in production, but we can manually promote the change to the
Production environment.
Note: we set the PE Master in the production environment, CD4PE is in development.
CD4PE WORKSHOP43

44. Lab 8 - Commit a change to your Control Repo
1. Navigate to https://<workshopID>-gitlab.classroom.puppet.com
2. Find and click on your own Control Repo in the list (puppet/control-repo-<#>)
3. Navigate to /site-modules/profile/manifests and review the contents of common.pp
4. Navigate to /data, click on common.yaml, then click the Edit button on the right
5. For the nano package on line 4, change:
ensure: absent → ensure: present
6. Optional: change the Commit message to something witty but informative
7. Click Commit changes
8. Switch back to CD4PE and notice a New Events message appearing
CD4PE WORKSHOP44

45. Lab 8 - Reviewing the pipeline run (1/2)
1. Back in CD4PE, click the New Events notification icon. If you don’t see this icon, that’s
possible due to AWS load balancer timeouts. In that case, simply refresh the page.
2. The first stage that runs is the Code Validation stage. This contains 4 built-in jobs that
check code, hiera, puppetfile and template syntax for everything in your control repo.
3. Click on their job numbers (#1, #2, etc.) to view their output
4. The second stage is the Impact Analysis stage. This stage determines what will
happen when our updated code is deployed to the development and production
environments. Click it’s number (#1) to view the information.
5. Click on View changes next to the development environment results to see the impact
of our code change.
CD4PE WORKSHOP45

46. Lab 8 - Reviewing the pipeline run (2/2)
6. Notice that for the production environment there was no impact? Take a look at
/data/nodes/puppet.classroom.puppet.com.yaml in Gitlab to see why…
7. The third stage of the pipeline is the deployment to the Development environment. Click
on it’s number (#2) to see the details.
8. The deployment actually is a Bolt Plan under the hood. The output we’re seeing are
Bolt Tasks that are performed by the Plan. You can even write custom deployment
policies to create your own deployment strategy!
9. Because we used a Direct deployment policy here, the change has been immediately
enforced. Open the details of this deployment and click View jobs on the Orchestration
task to see the results. Then check in PE, on the Jobs page, that Puppet has indeed ran
on the CD4PE host to install the nano package.
CD4PE WORKSHOP46

47. CD4PE WORKSHOP47
Discussion Q’s
What would be the use case for
a custom deployment policy?

48. CD4PE WORKSHOP48
Lab 9:
Promoting to production

49. Lab 9 - Commit another change to your Control Repo
1. Navigate to https://<workshopID>-gitlab.classroom.puppet.com
2. Find and click on your own Control Repo in the list (puppet/control-repo-<#>)
3. Navigate to /data/nodes, click on puppet.classroom.puppet.com.yaml, then click the
Edit button on the right
4. For the nano package on line 4, change:
ensure: absent → ensure: present
5. Optional: change the Commit message to something witty but informative
6. Click Commit changes
7. Switch back to CD4PE and notice a New Events message appearing
CD4PE WORKSHOP49

50. Lab 9 - Review the pipeline and promote to production
1. Back in CD4PE, click the New Events notification button. If you don’t see it, that’s
possible due to AWS load balancer timeouts. In that case, simply refresh the page.
2. Open the details for the Impact Analysis stage and wait for it to run. Once complete,
notice the impact for both environments:
○ the development environment will show no changes this time (no impact)
○ the production environment now also shows changes, due to our latest file change
3. Once the pipeline has completed, click the button between the Deployment
stage and the Deploy to Production stage, and click Promote, then Done.
4. Click the New Events button and view the details of the deployment. Notice this
deployment is only updating the code in PE, and is not immediately running Puppet.
5. Optional: run Puppet on the PE Master and verify it makes the change.
CD4PE WORKSHOP50

51. CD4PE WORKSHOP51
Discussion Q’s
Why does CD4PE only show
the last commit in the code
promotion screen?

52. CD4PE WORKSHOP52
Lab 10:
Adding a regex pipeline

53. Lab 10 - About regex pipelines
CD4PE prescribes a feature-branch development style. On the surface -- and it's okay to
stop at the surface if you need -- it's a lot like the git flow we've all been doing forever.
Branch off master into a feature branch to try out something. Merge into master, then
development, then production. Repeat.
A regex pipeline automates the part of the flow where you create a feature branch and
push it up to try things. Just like in the git-flow-with-code-manager style, you push a
feature branch and it creates an environment named the same. But with the addition of
pipelines, you can now do things like have all feature branch pushes automatically run
code validation before deploying to the feature-branch environment on the master.
CD4PE WORKSHOP53

54. Lab 10 - Create a regex pipeline
1. In CD4PE, go back to your control repo pipeline
2. Over on the right is a drop down box that says master -- click the to the right of it
3. Click the radio button to switch to Branch regex
4. Leave the default regex as feature_.* and click Add Pipeline, then Done
5. For your new pipeline, click + Add default pipeline
6. Find the Pull Request Gate, and click X to delete it (no PR’s used in a feature branch)
7. Click Add a deployment and select the Feature branch policy
8. Accept the defaults and click Add Deployment to Stage, then Done
CD4PE WORKSHOP54

55. Lab 10 - Create a feature branch and run the pipeline (1/3)
1. Switch over to your control repo in Gitlab
2. On the left hand navigation bar, go to Branches (in the Repository section)
3. Click the green New Branch button on the top right
4. Type in feature_emacs for the Branch name, and leave Create from to master
5. Notice that in CD4PE, a feature branch pipeline has kicked off.
6. Once the pipeline finishes, switch over to Puppet Enterprise and update the classes
(Classification → All Environments → Configuration tab → Refresh link on the right)
7. On the right, click Edit node group metadata. Notice the feature_emacs environment
now shows in the Environment dropdown box. Click Discard metadata changes.
CD4PE WORKSHOP55

56. Lab 10 - Create a feature branch and run the pipeline (2/3)
We now have our shiny new branch in Puppet, but it doesn’t have any changes yet….
8. Switch back to Gitlab, and while in the feature_emacs branch, navigate to /data,
click on common.yaml, then click the Edit button on the right
9. After line 6, add 2 new lines for a emacs package (use the same indentation!):
emacs:
ensure: present
10. Optional: change the Commit message to something witty but informative
11. Click Commit changes
12. Switch back to CD4PE, and see the pipeline trigger again
CD4PE WORKSHOP56

57. Lab 10 - Create a feature branch and run the pipeline (3/3)
13. Once the pipeline finishes, switch over to Puppet Enterprise
14. Our changed code is now available in the feature_emacs environment, but no nodes
are classified to that particular environment. However, rather changing the classification
permanently, we can also run Puppet once with an environment override. Navigate to
Puppet in the Run section of the left navigation bar.
15. In the Run Puppet screen, under Environment, set the radio button to Select an
environment for nodes to run in and select the feature_emacs environment.
16. Click Select a target type below Inventory and choose Node list. Type cd4pe and click
Search. Select your CD4PE node and click Run job on the bottom right hand side.
17. Notice there is 1 intentional change. Check the report to verify emacs was installed
CD4PE WORKSHOP57

58. CD4PE WORKSHOP58
Discussion Q’s
Why require that feature
branches have names
matching a regular expression?

59. CD4PE WORKSHOP59
Lab 11:
Using Pull Requests

60. Lab 11 - About pull requests
Finally, we're getting ready to complete the development cycle by creating a pull request
to propose our feature branch changes into the master branch. Once validated in the
CD4PE pipeline, and the Impact Analysis review, we can decide to approve it and merge
the changes.
First we need to enable our CD4PE to trigger on Pull Requests, after that we can create
the PR and go through the workflow.
CD4PE WORKSHOP60

61. Lab 11 - Enable Pull Request triggers on the pipeline
1. Switch back to CD4PE and go back to your control repo pipeline
2. Over on the right, below Pipelines, click the dropdown box (it probably still says regex)
and change it back to master. Then click Manage pipelines on the top right.
3. In the Triggers section, put a checkbox next to PullRequest
4. Click Save Settings, then Done
5. Notice that below the pipeline dropdown box that says master, the Pipeline trigger
status now says Commit, Pull request.
CD4PE WORKSHOP61

62. Lab 11 - Create a Pull Request that triggers the pipeline (1/2)
1. Switch to Gitlab and click Merge Requests on the left hand navigation bar.
2. Click the green New merge request button
3. Click the Select source branch dropdown box and select feature_emacs
4. Ensure the target branch is set to master (it’s the default) and click Compare branches
and continue.
5. Notice Gitlab tries to automatically name your PR for you, based on the commits made.
Put a checkbox next to Remove source branch when merge request is accepted, so we
don’t have to cleanup manually afterwards.
6. Click the green Submit merge request button near the bottom. Leave this page as-is.
CD4PE WORKSHOP62

63. Lab 11 - Create a Pull Request that triggers the pipeline (2/2)
7. Switch to CD4PE and click the New Events notification to see the new pipeline. Notice
that this time, the pipeline only runs until the Impact Analysis. The Pull Request Gate
after Impact Analysis has prevented the pipeline from running further for pending PR’s.
8. View the details of the Impact Analysis. Verify there is no impact as our CD4PE node
has already been updated in the previous lab, and the change doesn’t affect the PE
master as it has its own Hiera data that overrules the default from common.yaml.
9. Switch back to Gitlab, where we can see the pipeline status has synced back to the
PR. Now that we’re happy with the expected impact, click the Merge button to approve
the Pull Request.
10. Switch back to CD4PE and monitor the pipeline as it re-runs the pipeline, now all the
way to deploying the changes to the development environment.
CD4PE WORKSHOP63

64. CD4PE WORKSHOP64
Discussion Q’s
Why did the pipeline stop after
Impact Analysis for the Pull
Request, but not the merge?

65. CD4PE WORKSHOP65
Lab 12:
Adding a module

66. Lab 12 - About adding modules
If you keep your modules in their own individual repositories, you can have CD4PE
manage their deployment. Just like the control repository, they will have pipelines to
validate code, run Impact Analysis, and deploy to environments. Pushing a feature branch
even causes CD4PE to make a corresponding branch in the control repository and deploy
it, saving you a few manual steps.
In this lab, the module we’re adding contains a new task that has only been saved in the
master branch; it hasn’t been promoted to other environments yet. We will use CD4PE to
manually trigger a workflow on this commit and see the task appear in CD4PE.
CD4PE WORKSHOP66

67. Lab 12 - Add your module
1. In CD4PE, in the left-hand navigation, select Modules
2. Over on the right, click Add Module
3. Choose GitLab as the source
4. Choose the puppet organization
5. Select your numbered puppet-mymodule-<#> repository
6. Click Add
7. It should detect a .cd4pe.yaml file in this repo. Click Yes, manage as code
8. Click Done to dismiss the dialog.
CD4PE WORKSHOP67

68. Lab 12 - Trigger the module pipeline
1. In CD4PE, on the right-hand top, click Manual actions → Trigger Pipeline
2. Select the master pipeline
3. Select the commit named add task mymodule::puppetdb_query
4. Click Trigger Pipeline, then Done
5. Click the New Events notification to view the pipeline. Wait until it completes.
6. Switch back to Puppet Enterprise and navigate to Run → Task
7. Under Code environment, select development and then search for the
mymodule::puppetdb_query task in the Task box
8. Set the factname parameter to ipaddress and then run the task on the PE Master
CD4PE WORKSHOP68

69. CD4PE WORKSHOP69
Discussion Q’s
Suppose several teams have to
cooperate on a single "profile",
but they have to promote their
changes at different velocities.
How might breaking out
profiles into team-specific
modules make this
manageable?

70. CD4PE WORKSHOP70
Lab 13:
Protecting an
environment group

71. Lab 13 - About protected environment groups
You can mark environments as protected in CD4PE, and specify groups of users who are
allowed to approve deployments to those environments. This is similar to how you used to
protect branches in your VCS, in order to keep them from being inappropriately deployed.
But with CD4PE, you let it do the protection.
You can even use the combination of both protected environment groups in CD4PE, and
protected branches in your VCS, for ultimate security of your code changes.
CD4PE WORKSHOP71

72. Lab 13 - Create an approval group
First, you need to make a group of approvers, and add yourself to it.
1. In CD4PE, in the left-hand navigation, select Settings → Groups → Create new group
2. Enter Approvers as the group name and click Save
3. Under Control Repos, click the checkbox next to the List option.
4. Under Modules, click the checkbox next to the List option.
5. Click Save and add users, and tick the box next to your username
6. Click Add users to group, then Done
CD4PE WORKSHOP72

73. Lab 13 - Protect a PE environment group
1. In CD4PE, in the left-hand navigation, select Settings → Puppet Enterprise
2. In the column for Protected Environments click on the number 0, then click Add
3. Select the production environment
4. To enable the Approvers group, click on its slider
5. Click Add, then Done
6. Click Done to dismiss the dialog.
CD4PE WORKSHOP73

74. Lab 13 - Trigger a deployment to production
1. In CD4PE, navigate back to your control repo pipeline
2. Click the button between the Deployment stage and the Deploy to Production
stage, and click Promote, then Done.
3. Click the New Events button and view the details of the deployment.
4. Notice the deployment to production is now in a Pending Approval state.
5. Since you are an Approver, go ahead and open the details of the deployment and
Approve the deployment.
6. A few seconds after approving, the rest of the deployment policy will kick in.
CD4PE WORKSHOP74

75. CD4PE WORKSHOP75
Discussion Q’s
What if some malicious person
just pushes code to the
production branch,
"bypassing" CD4PE's
approval?

76. CD4PE WORKSHOP76
You made it!
Well done!

77. Thank you.