This is a good presentation of a good git branching strategy in general:
http://nvie.com/posts/a-successful-git-branching-model/
Since github does not manage permissions per branch you really do need
additional repositories - or at least one if you are willing to accept
that developers can screw up for each other.
Regard
- henrik
On 9/14/11 2:43 AM, Matt Wise wrote:
I'm looking for a bit of best-practices here. Our puppet environment
up-until-today has been owned and operated by IT Operations only. We've
had a single 'production' environment and our code has been managed in a
local GitHub::FI install. We have ~14,000 lines of code in our PP files.
We're trying to make two changes to our environment... that may need to
be done in the same way, or different ways. I'm looking for
recommendations on how you might handle this given a few constraints.
Constraint #1: We must continue to use GitHub as our source code repo
Constraint #2: Our developers will not run their own Puppet servers. We
want to use a few (2 ... max 3) 'Environments' in Puppet to handle
whether our systems are getting the Production release, or the Testing
release of code.
Ok... here's the two issues we need to solve:
#1: Our main Puppet Repo contains all of our base classes, site.pp,
extlookup tables, etc. This repo also contains our /private/ code ...
private keys, operations-owned bits of data that shouldn't be exposed to
the rest of our engineers. We want to break this into a Production and
a Testing environment on our Puppet servers themselves. I'd like these
two environments to both pull-changes every 5 minutes from Git, and have
an easy but clean method of merging changes from the Testing environment
into the Production environment. This can all be private ... meaning
that the same access rules apply to both environments, we just have
different process around them.
#2: Our User Area for Puppet modules is a much more open, free-form
place for our engineers to build their own puppet classes for their own
machine types. We'd like to do the same thing as above ... where our
engineers can update a Testing environment very easily. The difference
here is that we want our IT Ops staff to be the ones who pull changes
from Testing into Production for this repository, on some regular
interval. Access to these repos is different. IT Ops staff will need
read/write to both ... while the engineering teams will only be given
read/write to the Testing environment.
I'm really not super familiar with Git branching vs forking vs other
things... I'm looking for suggestions on how to handle this. I was
thinking that #1 could be handled with branches, and #2 could be handled
with forking and push/pull requests... but that seemed ugly to me to do
it differently on the two.
—Matt
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups Puppet
Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
