Pro Puppet (22 page)

This command will open, in your default text editor, a list of commits to the topic branch since it diverged from the master development branch. In order to clean up the commit history, the developer replaces “pick” with “squash” in the line listing his commit to add the missing curly brace. This will effectively combine this commit with the commit above it, where the curly brace should have been present in the first place.

Once the developer makes this change, he saves the file and quits the editor.
git
rewrites history for him, giving him the option to change the commit message of the freshly cleaned commit:

The developer is now ready to publish his topic branch to the rest of his colleagues and to the puppet master system itself, in order to check out the topic branch in the
/etc/puppet/environments/development/modules
repository.

Next, he logs into the puppet master system as the user
puppet
, fetches his topic branch from the central repository, and then checks out his topic branch in the development environment. This process will switch the current development environment away from whatever branch it was previously on. This could potentially interfere with the work of the operator. If this becomes a common problem, it is possible to set up more environments to ensure each contributor has their own location to test their changes without interfering with others.

The developer’s topic branch has now been checked out in the location the Puppet master is using for the development environment.

You can run the Puppet agent against the development environment, as we have previously and as shown in
Listing 3-4
, to verify your changes.

Listing 3-4.
Testing the Puppet

agentroot:~ # puppet agent --test --noop --environment development
info: Caching catalog for scd.puppetlabs.vm
info: Applying configuration version '1289764649'
--- /etc/ssh/sshd_config        2010-11-14 12:11:28.000000000 -0800
+++ /tmp/puppet-file.25961.0    2010-11-14 12:11:40.000000000 -0800
@@ -3,5 +3,4 @@
 SyslogFacility AUTHPRIV
 PermitRootLogin no
 PasswordAuthentication yes
-AllowGroups wheel adm
 UsePAM yes
notice: /Stage[main]/Ssh::Config/File[/etc/ssh/sshd_config]/content: is {md5}da5
4f2cdc309faf6d813a080783a31f6, should be {md5}9d4c3fba3434a46528b41a49b70b60e4 (
noop)
info: /Stage[main]/Ssh::Config/File[/etc/ssh/sshd_config]: Scheduling refresh of
 Service[sshd]
notice: /Stage[main]/Ssh::Service/Service[sshd]: Would have triggered 'refresh'
from 1 events
--- /etc/postfix/master.cf      2010-11-14 11:54:37.000000000 -0800
+++ /tmp/puppet-file.22317.0    2010-11-14 11:58:15.000000000 -0800
@@ -1,3 +1,5 @@
+# This file managed by puppet.  Manual changes will be reverted.
+#
 #
 # Postfix master process configuration file.  For details on the format
 # of the file, see the master(5) manual page (command: "man 5 master").
notice: /Stage[main]/Postfix::Config/File[/etc/postfix/master.cf]/content: is
 {md5}3b4d069fa7e4eb6570743261990a0d97, should be {md5}710171facd4980c2802a354ee4cb4a4e (noop)
info: /Stage[main]/Postfix::Config/File[/etc/postfix/master.cf]: Scheduling refresh of
 Service[postfix] notice: /Stage[main]/Postfix::Service/Service[postfix]: Would have
 triggered 'refresh' from 1 events
notice: Finished catalog run in 0.61 seconds


The Puppet agent run against the development environment shows us that Puppet will update the Postfix configuration file and notify the Postfix service as a result. Notice how the changes we’ve made to this system by trying out the
operator/ssh
branch will now be reverted. This is because the developer created his branch from the
master
branch and the operator has not yet merged her
operator/ssh
branch back into master, therefore her changes are not present.

At this point, both the changes of the operator and the developer have been tried in using the development environment. It’s now time to merge both change lists into a testing branch and make them both available in the testing Puppet environment.

Unlike the development Puppet environment, where anything goes and people may perform a checkout on their branches to quickly try out their changes and topic branches, the testing environment should change less frequently. The process of merging topic branches from the master development branch into a testing branch periodically, once every two weeks for example, has worked well for many projects and companies. In this section, we work through the process of merging change lists into the testing branch with the goal of ultimately promoting the testing branch to a production release.

First, our system administrator will create a new branch, called “testing,” based on the current master branch we started with. When starting out with Puppet, this testing branch and the process of merging change lists should be set early on in order to provide a good reference point. It also provides and staging area that’s not quite as risky as the development environment, and does not require a release process like the production environment does.

The system administrator creates the new testing branch in a manner similar to how the operator and developer created their topic branches. This should be done in the personal repository the system administrator has in her home directory:

Before checking out the testing branch on the Puppet master, the system administrator decides to merge the change lists from the operator and the developer into the main development branch. This keeps the main development branch in sync with the testing branch and allows the system administrator to advance the master development branch with additional changes without affecting the testing environment, which will only be updated on the Puppet master periodically.