I try to explain how we implemented our workflow. We developed some strategies to make puppet module development easy to test and we have a way to rollout our configuration to different environments by simply taging the versions we think they are stable enough. Basically we use the power of the DVCS Git to get that done.
Development or changes of puppet manifests: If we build a new Server we can choose between two different post install scrips. The standard script simply installs puppet and register the node on the puppetmaster for one of the three environments we have (testing->integration->production) The other one installs a puppetmaster and an empty git repo with a post-receive hook. This way it can be used as a development-server. And this is how it works: - take your copy of your puppet-modules repo and commit your changes (don't push them to the real puppetmaster) - add the new development-server as a remote target to git. - push the branch to the development-server This is where the post-recieve hook kicks in. it copies the HEAD to the modules directory of the development-server (he has his own puppetmaster) and runs "puppetd --test --debug". That's it! Just make sure the development-server includes all classes you want to test. You can also do cosmetics on your commits while you fix some syntax errors or small bugs, because you never pushed your changes to a public repo. Rollout: If the new version is ready and we believe everything is right, we push our changes to the puppetmaster (if there are changes and you have to merge, go back to your development-server and check if everythis is still ok). On the puppetmaster there is another post-receive hook that copies the HEAD to the testing environment. If everything went fine, we simply tag the version with a integration-YYYYMMDDxx tag and push that tag. the post-receive hook then copies that to the integration environment... and so on.. Rollback: This comes for free, simply tag an older version with a newer tag (and restore the damn file that ensure => absent killed from the backup :-) ). We don't have that much servers in puppet at the moment ~80 and only 2 people working on the manifests so i don't know if this scales if numbers grow. Maybe someone here with experience on larger setups has some suggestions on this? would be very welcome. I hope someone understands my poor english. Andy Am Friday 17 July 2009 22:06:09 schrieb Teyo Tyree: > 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? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
