That's been my feeling as well. I want to make sure that the same code goes through each environment. While performing the same merge on different branches should give that result, it's still performing two different actions which - especially with svn in the mix - may give different results. We use dev, systest, uat and prod environments. I'm think I'm heading towards using CI-style checkouts of the main branch of code for systest, with a user-modifiable modules directory in the module path for dev, in addition. Both would exist only on our internal systems. Puppet-library looks like it would be good for this but extending it to use SVN will have to wait for another day. To make it onto UAT, modules need to be packaged up forge-style. A local repo of these packages would get synced between puppetmasters in different environments. I'm hoping I can work past the current crop of bugs and install locally packaged modules with the puppet module tool. I'd install to different module directories for UAT and Prod. This still leaves me with no entirely accurate record of what's on prod at any given time, but the dev trunk will be close enough to rebuild from in the case of total meltdown.
On Thursday, 16 August 2012 15:46:07 UTC+1, Ygor wrote: > 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) > > ------------------------------ > *From: *"Jason Slagle" <rais...@tacorp.net <javascript:>> > *To: *puppet...@googlegroups.com <javascript:> > *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 view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/f7Jbot7Tei0J. 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.
