Pro Puppet (21 page)

Now that the operator has his or her own branch, we’re ready to make a change. We’re going to add two lines using two commits to illustrate the history tracking features of a version control system.

First, add the groups who should have access to the machine. To start, only the
wheel
group should be allowed to log in, so add the following lines to the
sshd_config
template:

As you can see, we’ve added a single line to the file
~/modules/ssh/files/sshd_config
in the personal clone of the repository in the operator’s home directory. We must commit and push this change into the central repository, but we haven’t tested it yet so we should be careful and not merge the branch we’re working on,
operator/ssh
, into the
master
branch yet.

The
git push
command the operator used creates a new branch in the central repository with the same name as the topic branch the operator is working on in his or her home directory. This is important to prevent untested changes from making their way into the master branch. Once we’ve pushed the new branch to the central repository, we should test the new branch in the development environment.

Now that we’ve switched to our new topic branch in the development environment, we’re able to test the Puppet agent against the development environment.

puppet:~ $  puppet agent --test --environment development --noop
info: Caching catalog for scd.puppetlabs.vm
info: Applying configuration version '1289751259'
--- /etc/ssh/sshd_config        2010-11-14 08:16:45.000000000 -0800
+++ /tmp/puppet-file.13997.0    2010-11-14 08:16:57.000000000 -0800
@@ -3,4 +3,5 @@
 SyslogFacility AUTHPRIV
 PermitRootLogin no
 PasswordAuthentication yes
+AllowGroups wheel adm
 UsePAM yes
notice: /Stage[main]/Ssh::Config/File[/etc/ssh/sshd_config]/content: is
 {md5}9d4c3fba3434a46528b41a49b70b60e4, should be {md5}da54f2cdc309faf6d813a080783a31f6 (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
notice: Finished catalog run in 0.39 seconds


Notice that this Puppet agent run is running in
noop
mode, and that the agent tells us it would have changed
/etc/ssh/sshd_config
by inserting the line we just committed to the branch
operator/ssh
and checked out in the development environment’s repository on the Puppet master.

You’re able to verify that the production environment remains unchanged, just like we did in the “Making Changes to the Development Environment” section when we updated the Postfix configuration file. Simply remove the environment command line option to cause the agent to execute in the default production environment again:

While the system operator is working on the change to the
sshd_config
file, the developer in our hypothetical company is working on a change to the Postfix configuration file. Just like the operator, he’ll need a personal copy of the central repository we set up at
[email protected]:git/modules.git
in his home directory.

Once the developer has cloned his personal copy of the central repository, he’s able to make his change to the Postfix configuration file. He’ll also use a branch to track his changes and make it easy to merge into the testing branch for use in the testing environment. Finally, after testing, he’ll use the tag feature of the version control system to cut a new release of the configuration used in production, then check out this tag in the repository used by the production Puppet environment.

To start, the developer creates his topic branch from the development branch named
master
. Note that the changes his teammate, the operator, has made have not yet been merged into the master branch, so the developer does not have them. We cover the process of merging multiple changes together when we merge both of these changes into the testing branch in the next section.

Now that the developer has his own topic branch, he’s free to change the code without impacting the work of anyone else on the team. His changes can be discarded or merged at a later point in time. Let’s look at his changes to the Postfix configuration file and how he committed them into the version control system:

Using the
git log
command, you’re able to see the developer has made two commits since he created his topic from the main master development branch. This specific command displays the series of commits from the master development branch to the tip of the current topic branch. You’re able to
use the
git log
command again to see exactly what the developer changed in these two commits, as shown in
Listing 3-3
.

Reviewing his changes, the developer notices he made a typographical mistake in the postfix configuration file and decides to fix this problem. In the second section of the diff output in the Postfix configuration file, the line containing
template("${module_name/main.cf.erb")
is missing a closing curly brace around the variable
module_name
. He decides to fix this and make a third commit to his topic branch. The output of
git log
now shows:

The developer is satisfied with his changes to Postfix, and he would like to try them out in the development environment in a similar way the operator tested out her changes. The overall workflow the developer follows is to push their topic branch to the central repository, fetch the changes in the development environment’s repository, check out the topic branch, then run the Puppet agent against the development environment.

Before publishing his topic branch to a different repository, he decides to clean up his commit history to remove the entire commit that he created simply to fix a single character mistake he introduced. The
git rebase
command allows him to quickly and easily modify his topic branch to clean up this mistake.