On Fri, Jul 17, 2009 at 1:06 PM, Teyo Tyree<t...@reductivelabs.com> wrote: > In the course of training and consulting with Puppet, the question of change > management best practices has come up over and over again. On the edges, we > have small teams that can get away with simply version controlling their > code using an SCM as an incremental backups while rolling out change in a > fairly adhoc fashion and larger teams that need branches, QA, and DEV > environments, and perhaps even separate repositories for each module. There > is also the issues of roll back and testing. We are curious how the > community approaches these problems in hopes of developing some best > practices. So what do you guys/gals do?
We use environments extensively. We store all our configurations in VCS. All edits are done to a "common" branch. Teams responsible for specific platforms (say "mac") perform a VCS integrate from the common branch to a mac_unstable branch. The team members tend to live on their own unstable branch, and regularly bug fix in common and repeat the integrates to "mac_unstable". Once that has settled, a VCS integrate is performed from "mac_unstable" to "mac_testing". A larger group of pilot users not in the immediate team group live on this branch/environment. Once that has settled, a VCS integrate is performed from "mac_testing" to "mac_stable". This allows all the teams to follow their own release cycles, yet all still share a common code base. We have an extensive series of presubmit hooks that do things like run puppet --parseonly --detailed-exitcodes on each .pp file, that validate that file source urls like puppet:///module/file actually point to a real file, style guide enforcement like trailing commas, whitespace, tabs, etc etc. We also have test servers where we can do things like redirect all environments to refer to the "common" development environment for ease of testing fixes without going through the whole release process. We sit down every so often and look back at the developed code base to see where we can combine solutions from different groups and share as much configuration as possible. It's actually a bit more complicated than this because our environments are more fine-grained than just "mac_unstable" so we can target different OS versions differently and different hardware types (workstation, laptop) differently, but the same principles all hold. Oh, and we also have matching apt repositories for the unstable/testing/stable environment suffixes, and perform simultaneous releases/promotions in apt and puppet. > -- > Teyo Tyree :: www.reductivelabs.com > > > > -- Nigel Kersten nig...@google.com System Administrator Google, Inc. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
