Reviewing the code before including it in any of our production branches is a good practice due to the great advantages it provides. It helps to detect problems in the code as early as possible. Some things that are out of the test's scope as code readability or variable naming can be detected by other members of the team.
When there's a team of people who work collaboratively on Puppet, it is quite important to have good communication among its members and a common vision on how the code is organized, where logic and data are placed and what are the principles behind some design decisions.
Many mistakes while working on Puppet are due to incomplete knowledge of the area of effect of code changes, and this is due, most of the time, to bad communication.
For this reason, any tool that can boost communication, peer review, and discussion about code can definitively help in having a saner development environment.
When we work with Git, the natural companion to manage peer review and workflow authorization schemes is Gerrit, a web interface made by Google for the development of Android, that integrates perfectly with Git and allows commenting on any commit, allows you to vote for them, and has users that may authorize their acceptance.
Different user roles with different permission schemes and authorization workflows can be defined. Once new repositories are added, they can be cloned via Git:
git clone ssh://[email protected]:29418/puppet-modules
When we work on repositories managed under Gerrit, we have to configure our Git to push to the special for ref, instead of the default heads. This is the key step that allows us to push our commits to a special intermediary place where they can be accepted or rejected:
git config remote.origin.push refs/heads/*:refs/for/*
We also need a precommit hook that automatically places a (required) Change-ID in our commits:
gitdir=$(git rev-parse --git-dir) ; scp -p -P 29418 [email protected]:hooks/commit-msg ${gitdir}/hooks/
Once we have made our setup, we can normally work on our local repo with Git, and when we push our changes they are submitted to Gerrit, to the special refs/for for code peer review. When a commit is accepted, Gerrit moves it to refs/heads from where it can be pulled and distributed.
Gerrit can be introduced at any time in our workflow to manage the acceptance of commits in a centrally managed way and, besides the client's configurations, we have seen it doesn't require further changes in our architecture.
Note
A great tutorial on Gerrit can be seen here: http://www.vogella.com/tutorials/Gerrit/article.html
There are various online services that can be used for peer review and provide an alternative to an on-premise solution based on Gerrit.
GitEnterprise (https://gitent-scm.com) offers a Gerrit and code repository online service.
RBCommons (https://rbcommons.com) is the SaaS version of the review board's (http://www.reviewboard.org/) open source code review software.
Repository management sites such as GitHub (https://github.com) or BitBucket (https://bitbucket.com) offer, via the web interface, an easy way to fork a repository, make local changes and push them back to the upstream repository with pull requests that can be discussed and approved by the upstream repository owner.