Puppet users - Sep 2011 - Quick help… GitHub & Puppet Environments...

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.