Mark,
We''re a Subversion shop (sadly), but I can tell you what we''re
doing:
We have one puppetmaster (at the moment, we haven''t hit a scaling wall
yet). That puppetmaster has environments defined; there is a
production environment for our stable, well-tested Puppet configs, a
staging environment for Puppet configs which are candidates for
production, and an environment for each of us who are developing
Puppet manifests. The production and staging environments point to a
directory containing a checkout of a Subversion tag. It has two
subdirectories: manifests/ (which really only contains site.pp at the
moment) and modules/ (which contain our modules). All of our modules
are stored in a single repository at the moment. When we release these
modules to the community, that will probably change. We have a ''Puppet
Master'' (me) who is the only one allowed to merge branches, cut tags,
and deploy to production. Development takes place on topic branches.
I personally use git-svn to interact with our repository, because I
hate Subversion with a passion. It may be an improvement over CVS, but
it is still trapped in the Dark Ages as far as I''m concerned.
While I''m developing I use virtual machines to verify that the
manifests work as expected. Once I''m satisfied with them, I cut a tag
and svn switch the staging environment to that tag. There is a second
instance of puppetd running on a representative subset of our
machines; that instance is run with --noop and is pointed at the
staging environment. The theory is that we leave the staging tag in
place for 24 hours or so, and review the logs from the second instance
to make sure things work as expected. In practice, our configs are
changing too fast at the moment, so I usually run this sample by hand
several times and look at the logs. I won''t be able to get away with
that much longer :-)
I highly recommend that each sysadmin develop on their own branch,
with a merge master to do the work of integrating. That said, I''m
almost a complete newb at collaborative development, so you probably
don''t want to listen to me.
That''s the outline of things. Feel free to ping me with more questions.
--Paul
On Thu, Sep 4, 2008 at 9:38 AM, Mark Drayton <mdrayton@gmail.com>
wrote:>
> Hi there
>
> I''ve been using Puppet to manage several classes of servers
separately
> from my coworkers while I learn the basics and try work out the best
> approach to take. We''re happy that Puppet is the way forward so
now
> it''s time to work out how several sysadmins can use version
control
> and multiple environments for development, testing and production.
>
> I''ll probably use Git for version control but I can''t
quite figure out
> the workflow of actually getting changes from sysadmins into Puppet.
> I''m planning something like a central git repository with
development,
> testing and production branches with testing and production pushed out
> to /etc/puppet/modules-{testing,production} on the live puppetmasters.
>
> How should the sysadmins use the development branch? I''m not sure
that
> we want a development environment on the live puppetmasters; pushing
> incremental dev changes out to live where they won''t be used seems
a
> waste, so pushing changes from syadmins directly into the developer
> branch seems a no-no. So perhaps I need a development puppetmaster
> which checks out the development branch (remote branch? Git''s new
to
> me) into /etc/puppet/modules-development. Admins can then tinker with
> things, committing into development and then pushing to testing.
It''d
> presumably also be easy to branch here to allow development of new
> features in parallel (though obviously only the active branch could be
> used as the catalog for the development puppetmaster, and presumably
> only one admin could be doing work there at any one time).
>
> Or.. could I just check the manifests out onto a development server
> (which could be a VM, easily re-imaged) and develop by running puppet
> from the command line? That is, avoiding the need for a development
> puppetmaster entirely? Once whatever feature being developed is done
> it could be committed to the testing branch, omitting a development
> branch entirely.
>
> Lastly, DavidS'' Common Modules wiki page [1] suggests a repo per
> module. Is this necessary when all modules are developed in house?
> What''re the advantages? His layout also seems to have changes
pushed
> between dev/testing/prod repos rather than merged between branches. A
> key requirement for us is to be able to see (i.e., log) when changes
> were integrated from one environment to another.
>
> You can probably tell that I''m stuck and possibly quite confused.
> How''re you doing this?
>
> Looking forward to your replies,
>
> Mark
>
> [1] http://reductivelabs.com/trac/puppet/wiki/CommonModules
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---