First of all, if your sysadmins aren't advocates of version control (even more so than your developers), fire them now, Now, NOW. Or at least hire a competent senior sysadmin to train them properly.
Back to the topic at hand. We have only two environment (production and development). Since the puppet.conf file is itself managed by puppet, adding "environment = <%= environment %>" to the [puppetd] stanza means that switching a system between production and development is as simple as "puppetd --test --environment development". That change is "sticky", in that it won't revert without explicitly doing "puppetd --test --environment production". We keep our manifests in Bazaar. When we've got a successfully tested/reviewed set of changes in development, we do a "bzr commit" on the development side, and then a "bzr merge bzr://bzr/puppet/puppet-dev;bzr commit" on the production side. The only real down side is that moving code to production means that either *everything* in development is now ready for production, or that you can isolate the interesting changes for the commit/merge. Since there's really only one of us working on manifests at the moment, it's not a big deal. For future needs, we've got a 2nd puppetmaster set up identically that we can use if we're afraid the changes might crash the production puppetmaster. On Mon, Jul 5, 2010 at 9:40 AM, Dan Carley <dan.car...@gmail.com> wrote: > On 5 July 2010 11:01, Jean-Baptiste Barth <jeanbaptiste.ba...@gmail.com>wrote: > >> For the moment we only have 1 puppetmaster here. I noticed that if I have >> a syntax error in one of my included .pp, then puppet runs fail on all nodes >> (even if they do not use this recipe), which is not acceptable. More >> generally, working directly on production recipes seems too riskee, since >> people who will manage those recipes are not devs but sysadmins, which means >> poor development skills (and no versionning for the moment). >> >> I found the documentation about puppet "environments" ( >> http://docs.puppetlabs.com/guides/environment.html ) : does anybody use >> it here ? I also read some of you have 2 puppetmasters running on different >> ports, for test and prod : how do you do that (init scripts available >> somewhere? different conf/manifests directories? sync between test and >> prod?). Do you have a pool of client machines dedicated to your tests ? Do >> you handle this kind of problems directly with your version control system >> (post hooks?), or maybe at an other level in your external node provider ? >> > > Mostly echoing Daniel Pittman's comments.. > > - We use environments a lot. The default production environment is for, > well, production. All other environments are for development use. Each has > their own SVN branch and Puppet `manifest`/`modulepath`/extlookup > directives. > > - In addition to custom types, providers and facts, flapping back and > forth between environments. It's also not possible to have separate > fileservers for additional paths between environments. But it's probably not > something that will affect you at this stage. > > - We have virtualised dev/staging machines which reflect the roles of our > production machines, only on a slightly smaller scale. Any changes get > pushed here and monitored first. We also have some shell scripts which are a > shorthand for `--test --noop` to quickly review what is going to happen for > a given machine. When we're happy with the results then the changes get > merged to production. > > - Syntax errors are caught by a pre-commit hook. It won't guard against > stupid yet syntactically correct code. But it does vastly reduce the time > spent dealing with simple humanoid typos. > > - Be sure to version control your manifests from day one. Without doing > so, you'll have no way of knowing who changed what and when. Nor the ability > to roll back to a point in history. It will also provide you with an easy > mechanism to peer review any code that you're not confident with, as Daniel > notes. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@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-us...@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.
