On Thu, Oct 1, 2009 at 10:56 AM, Calimero <calimero...@evolutive.org> wrote: > > On 30 sep, 17:20, Kenneth Holter <kenneho....@gmail.com> wrote: >> Hello all. >> >> We're running Puppet to manage our linux-servers, but as of now we don't >> really have a good setup for dealing with different environments >> (production, qass, and so forth). The puppet manifests have been added to >> Subversion. > > We also have our puppet conf versioned by SVN. And, well, ... we still > don't have a proper system for various stages. > > I thought of creating multiple branches in SVN (each branch being > configured as a puppet environment) and then, when changes seem OK, > merge (svn merge) them from the dev branch to the testing branch and > so forth. > > But this of course requires some change in SVN usage: commit only > things that belong together (so that you can 'svn merge -c N ...') > instead of committing any changes that are dangling in your working > copy. > > Anyway, I would also like to hear how people do this in their setups. >
We make use of a combination of SVN tags as well as environments. We configure puppet with the following environments: development, staging (a.k.a. QA), production, prod-clone, branch1 and branch2 The first 3 should be self-explanatory. Prod-clone is for emergency fixes outside of our normal update schedule where we can point a production machine to a branch with the prod puppet code + a fix. Branch1 and Branch2 are similar to development for major refactoring. We also have to deal with production control issues, so we created a schedule for each environment - Development, Branch1 and Branch2 we are free to update at any time, so systems in those environments are generally new builds or test/dev systems. QA we update in our Tuesday evening change window and Production and Prod-clone are updated in our Thursday evening change window. Prod-clone, by its nature, can get updated anytime after that, but only in an emergency situation to fix a problem. Development is our puppet SVN trunk. Branch1 and Branch2 *can* be SVN branches, but aren't always. More often than not they're trunk plus some local changes that once we vet are merged back into trunk. At some point before Tuesday, we copy trunk to a tag that becomes the next QA->Production configuration. We tried doing things the Right Way(TM) with SVN and having branches, merging fixes from trunk to the branches, cutting tags from the branches, etc. but it was just too much overhead for what we were doing. We have found if we keep the release tags fairly frequent (every week or two), it's fairly easy to stay on top of things and not break anything. We also comment our check-ins in a specific format so we know what host(s) the change(s) affect and what the change is. We use this to generate a summary page that is presented at our weekly rollout meetings so that the other groups (DBAs, App Developers, etc.) can see what changes are scheduled for the next change. This lets us remain agile enough to respond to things, but also gives some oversight to the process so we don't go breaking anything in production because we fat-fingered an SVN update or something similar. 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 -~----------~----~----~----~------~----~------~--~---
