Code Management for Puppet: Understanding the connection

between Puppet and Git.

Phil Watts Principle Enterprise Director of Self Aggrandizement

Why use git?• Distributed (work offline)

• Creating branches is trivial

• Enforces Trackable Consistency

• Change History

• It’s awesome.

Integration with Puppet:

r10k and dynamic environments

web hooks are magic

Options for Repository Hosting

GitHub Stash GitHubEnterprise GitLab*

Location Public Web Self-HostedSelf-Hosted or

Virtual Appliance

Self-Hosted

Data Protection Managed Bad Export

Tool included

Very nice backup tools and Puppet

modules

Good Luck

How to RBACFork/Pull,

Organizations, Collaborators

Branch Level Permissions

Control

Fork/Pull, Organizations, Collaborators

Protected Branches

Visual Appeal OMG Octocat Looks like Jira (blegh)

So much Octocat Ugly

Cost Free/Monthly per private repo

Pay per seat (cheap)

Pay per seat (not cheap) FREE?!?!

Hooks Webhooks only (post receive)

pre commit & post receive

Web hooks Officially*

pre commit & post receive

acceptance

stable

servo

feature_branch

acquiesce

stable

feature_branch

stable

acceptance

stable

production production production production production

Sandbox Deployment Non-Prod Deployment Production Deployment

stable

control-fiefs

control-vassals

control-lords

Pull from upstream

Merge Pull Request

Pull Request

1

2 3

4

65

7

1. Developer creates and completes to their satisfaction, a "feature" branch. Then a pull request is created to merge the "feature" branch.2. Peer review results in the "feature" branch being merged up to "acquiesce".3. A commit to the "acquiesce" branch results in automated testing in the "servo" branch. If tests succeed, code is merged up to the "acceptance" branch, and a pull request is created.4. "Team Leader" review to confirm the code change, testing, and process requirements. If acceptable, the code is merged to the "stable" branch.6. The "stable" branch is submitted to required change control, and is merged into the "production" branch in accordance to production change requirements.5 & 7. The "stable" and "production" environments are cascaded downstream to serve as baselines for systems in lower environments when not actively being tested against.

feature_branch

acquiesce

servo_branch

acceptance

stable

production

CI Robot

Change Control

Team Review

** Any Other Developer **

Developer

"One Repo to rule them all, One Repo to find them,

One Repo to bring them all and in the darkness bind them" ~

1. Developers create feature branches for new code. Upon completion, a pull request is submitted to the "acquiesce" branch.

2. Any approved developer other than the submitter can review and approve the pull request to "acquiesce". **Low Scrutiny || Code Sanity Check**

3. A webhook or watch based automated action will trigger when a merge is detected against the "acquiesce" branch. This will create a "servo_" branch to perform automated tests.

4. Upon the successful passing state of all required automated tests, the "servo_" branch will be merged into the acceptance branch by the CI tool. At this time, the CI tool, or a web hook action can create a pull request from "acceptance" to "stable".

5. Evaluation of pull requests to stable evaluated for releasable state. ** High Scrutiny Review || Could be Team Lead / Team Review **

How do I pick a review structure?

• Pick your favorite dysfunctional government structure:

Autocracy Democracy

Plutocracy

Logocracy

Kakistocracy

github.com/marsupermammal @pwattstbd

pwatts217@gmail.com http://www.slideshare.net/PhilipWatts1/codemgmt-48871071

Chose your own adventure!

Comics Code Samples

Git Hooks

Pre-commit:

Good Bad

Validate Code before it leaves your local git

No way to force compliance with

their use

Prevents all your syntax fail commits from entering the

history

Lots of duplication of code, as every repo requires its own config per

developer

Enforces syntax checking, style,

and other unit test like functions

Pulling code from others can break

your commit hooks, if you’re the only one

using them.

Low Cost, High Rewards

When cleaning up your own git repos,

local hooks are easy to forget about, and hilarity can ensue.

Pre-receive:

Good Bad

Can be enforced for all committers without setup per

developer.

Bane of your existence when trying to push

“one last change”.

Prevents everyone else’s syntax fail

commits from enterting the history.

Can be slow. As all commits trigger hooks run by the

same server.

Enforces syntax checking, style,

and other unit test like functions

Different hooks for different repo types.

Makes for more administrative

overhead (unless you automate it)

Great for workflow orchestration.

Web hooks

Good Bad

Made by Wizards. Can do anything.

Require externally

hosted service to listen/act.

Seriously, anything.

Post receive means git

changes get dangerous.

Enforce whatever you want, you’re

the boss.

Makes the bad API of other tools feel like your problem.

Great always. Made of Beer and Bonuses.

Not trivial to write in most

cases.

Glossary• Fief - Heritable property or rights granted by an overlord to a vassal who held it in fealty (or "in fee") in return for a form of

feudal allegiance and service. (Yes, it was deliberate to identify developers as the property, instead of as peasants or peons).

• Vassal - A subordinate who placed himself in service to a lord in return for the lord's protection.

• Lord - A person or deity who has authority, control, or power over others.

• Acquiesce - Reluctant agreement without protest.

• Servo - An automatic device that uses error-sensing negative feedback to correct a process. Failed tests yell at you.

• Autocracy - A system of government wherein absolute power resides with a single person. In code review, this is often viewed as a Benevolent Dictator for Life (BDFL). Obviously, this leaves you prone to a single person’s thoughts.

• Plutocracy - A system of government wherein power resides with the wealthy. In code review, decisions governed by team members based off of “organizational currency” such as tenure, political clout or membership in social cliches. This can be prone to creating an “echo chamber”.

• Democracy - A system of government wherein power resides with the populace. In code review, decisions governed by popular vote. Often very time consuming for the team, very slow, and resistant to innovation.

• Logocracy - Rule by word. In code review, decisions governed by written, often antiquated process.

• Kakistocracy - Rule by the worst. In code review, this is the result when code review is considered scut work, and is delegated to the least talented, experienced or skilled developers.

• Continuous Delivery - Moving developed code to releasable branches as quickly as possible while adhering to all desired governance.

• Continuous Integration - Moving releasable code into the primary branch frequently. This is often done through automation.

• Continuous Deployment - Pushing released code in the primary branch directly out to live servers. In Puppet, this is also known as <= 30minutes after Continuous Integration.