May I politely disagree ? I feel that using subversion branches for the different environments is defeating the fact that Puppet separates the environments thru the use of the environment setting.
Does that make any sense to you all ? “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) ----- Original Message ----- From: "Jason Slagle" <raist...@tacorp.net> To: puppet-users@googlegroups.com Sent: Thursday, August 16, 2012 9:28:29 AM Subject: Re: [Puppet Users] Managing puppet code Although it doesn't seem to do svn yet (You could extend it), I'm fairly certain you could accomplish this with librarian-puppet. It's on github. Your Puppetfile would be in your main repo which could have dev/stage/prod branches. Jason On 08/16/2012 07:22 AM, Benjamin Priestman wrote: > I'm piloting a puppet deployment that may grow to a fair size (~100 > nodes, at least two distinct sites, dev/stage/prod environments). I'm > struggling a bit with settling on a strategy and processes for > managing and deploying puppet code. > > As seems to be generally accepted best practice and as required by the > fact that there will be multiple teams likely to contribute modules > for their applications, I'm managing the code for each > internally-developed module in separate repositories - some SVN and > some git-based, depending on the working practices of the different > teams. I also want to make sure we have a way of pushing different > modules through the different environments at their own pace > (application a's module might be ready to move into production while > application b's module should remain in UAT). > > My issues are around how to pull all these modules together, and how > to move them through dev/stage/prod environments in sane a reasonably > simple way. There are a number whitepapers and descriptions of process > around which mainly seem to rely on having a single git repo with > different branches representing the different environments. I've got a > kind of process working which links together different internal > modules, as well as the git-hub sources of modules that have been > published to the forge, making use of azimux's externals project > (https://github.com/azimux/externals). This works quite nicely for > constructing an unstable trunk/master and could be used to push > monolithic tags through uat and prod. My current system for deploying > individual tags, though, relies on creating a library of tagged > modules and a forest of symlinks under $environment/modules. It works, > but it is so complex it confuses me, let alone anyone else. > > Using forge-style modules seems to be the way to go, but these will > need management, too. > > Does anyone have any suggestions? -- 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.
