Thanks for your replies.  I agree that we'd like to use multiple branches, 
but we're running into problems doing that with our setup.  The issue here 
is that often, there isn't a way to know something isn't working until the 
changes are committed and the development puppet server has pulled them 
down, because only then can we see how the puppet client systems react.  
There are a few potential ways to go about this:

- Have a bunch of test clients (most of them would have to be VMs), two for 
each developer's workstation, and run puppet masters on each developer's 
workstation for test clients to point to.  I'm thinking there has to be an 
easier way than this.

- Have multiple development branches, each one being pulled down to the 
puppet development server in separate directories, then have those 
directories rsync'd into the main puppet tree (this avoids the problems 
that happen when you have unmanaged files in locations to which you're 
doing a git pull, which are magnified greatly when implementing multiple 
trees, as I discovered yesterday).

- A better version of the above is something like this, but it would 
require a lot of restructuring, and unfortunately we're understaffed and 
have several large projects that take priority:

http://puppetlabs.com/blog/git-workflow-and-puppet-environments/

I think option 3 is the best long-term, but I'm looking for something we 
can implement quickly until we get a bit of breathing space.  I realize the 
way we're using Git is kind of weird, so maybe I'm thinking in the wrong 
direction altogether.

-- 


Reply via email to