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.
