4. Options for Repository
Hosting
GitHub Stash
GitHub
Enterprise
GitLab*
Location Public Web Self-Hosted
Self-Hosted or
Virtual
Appliance
Self-Hosted
Data
Protection
Managed
Bad Export
Tool included
Very nice
backup tools
and Puppet
modules
Good Luck
How to RBAC
Fork/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
5. 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.
6. 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
**
7. How do I pick a review
structure?
• Pick your favorite dysfunctional government structure:
Autocracy Democracy
Plutocracy
Logocracy
Kakistocracy
10. 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.
11. 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.
