Hi, > 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?
Here we don't (yet) have different code bases for production and development, but are considering it. Instead, we each have a clone of the manifests in our home-dirs and test new stuff by running: puppetd -t --environment <username> on relevant dev machines, then push/pull the changes into the central repository on the puppetmaster once everything seems ok. As we have different puppetmaster servers (more or less one for each customer), we try to share the most we can by putting almost everything in modules, stored in seperate repositories on github. Then using git-submodule (currently testing git-subtree [1] as a replacement) to glue them all together in one big repository on each puppetmaster. This forces us to write cross-platform manifests, in a "one application = one module" fashion. Marc [1] http://github.com/apenwarr/git-subtree/tree/master --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
