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? > The policy that I set up at my previous workplace with some measure of success involved a "dev" and "release" branch. You could make as many changes as you wanted to the dev release, but when it came time to promote it, you would have to send a ticket, have someone else review/test the release, then promote it to release using a custom tool that created a pointer (using svn externals) setting it as the current release tag. This worked pretty well, but it had some deficiencies too. For example, if no one else was available to review your release, it slowed things down, and sometimes tickets got lost. And sometimes bad releases DID get out. --Russell > > -- > Teyo Tyree :: www.reductivelabs.com > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
