On Jun 24, 4:02 pm, Eric Sorenson <[email protected]> wrote:
> - Describe your environment (general application, number of clients, number 
> of puppetmasters)
Internet facing private SaaS application (at my former employer),
about 150 nodes, one puppetmaster for production, one for testing
running on a different port.

> - Describe revision control setup
Commits are pushed to a "central" git repository into topic branches.
This is distinctly different than subversion, which doesn't handle
branches like Git does.  On each of the two puppet master servers,
environments are setup for individual people to work without affecting
other people.  Environments hack at the modulepath, so this
effectively tells the puppet master where to look for the local git
clone.  During testing, the environment in question is checked out to
the branch in question and the nodes are tested using puppetd --test --
environment=jmccune

To promote from development to testing, commits are cherry-picked or
full on merged into another branch named environment/testing, which is
shared and a sort of "staging area"

To promote from testing to production, the testing branch where topic
branches are merged and staged, we would simply merge the environment/
testing branch into the environment/production branch, then pull down
the branch from the "central" git repository onto the puppet master.

> - What do you like about it?
I love that Git allows you to switch branches quickly and easily
without the filesystem path changing.  This allows for a relatively
static --modulepath configuration setting.  I love that Git
facilitates each topic branch being tied to a specific Sales Force
case number (any ticketing system would work just as well).  I love
the clear and easy promotion from development to testing to
production.  Git is fast.  Very fast.  I like being able to hack on
puppet code on an airplane without network access.  I like being able
to rebase a topic branch and consolidate a number of small commits
into a single patch, then apply it to another branch.

> - What do you NOT like about it?
Git is difficult.  It took me some time to wrap my brain around it,
but once I did everything is great.  Git is difficult for junior level
people to approach as well.  The "central" git repository used a
shared "git" unix account with SSH authorized_keys containing a public
key for each person with commit access.  I was surprised to find many
of my colleagues had difficulty even setting up SSH keys for this
purpose.

> - What are you doing to improve/change the setup?
Pre-commit hook to check syntax before accepting a commit to the
environment/production branch.
Post-commit hook to trigger a git pull on the puppet masters after a
commit to the environment/production branch.
Integration with Salesforce case numbers (Ticketing system).

I also wrote a custom report processor for the puppet master to append
the Git commit ID to every log message generated.  This allowed me to
identify the state of the environment/production repository that
caused a resource to change or whatever log message coming from the
client.  My presentation on this is available at:
http://puppetcamp.org/europe-2010-ghent/schedule-and-speakers/
Slides: http://bit.ly/puppetsplunkslides
Video of the talk: http://blip.tv/file/3759813/
Custom Report Processor: 
http://github.com/jeffmccune/puppet-demotools/blob/master/lib/puppet/reports/logversion.rb
Finally, the config_version command line option to actually get the
Git SHA.  This could easily use Subversion as well:
http://github.com/jeffmccune/puppet-demotools/blob/master/bin/get-config-version


Let me know if you have any questions about this setup, I'm happy to
help.

Cheers,
--
Jeff McCune

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to