hello, 'lo, > I did read the reductive labs documentation (which is unclear as > usual), and the devco site before posting here, and again after > someone referenced it. I understand the concept of multiple > environments quite well, and that's not the issue. The issue is how I > integrate this functionality back into subversion such that I don't > have to be constantly copying files between development and > production. > > The devco site does NOT show you how you can branch. It says you can > do it, and that's about it. It does not address for example the issue > of when making a branch, and checking the branch out to work on it, > you suddenly have no puppet environment to work in. How do you test? >
Based on the devco site. All your modules would live generally one directory, /etc/puppet/manifests/common/modules the modules there would apply to all your environments. Now you decide to work on your apache module in test. svn copy common/modules/apache development/modules/apache < edit files in development etc > svn ci development/modules/apache -m 'start dev on apache' At this point, and if your puppetmaster has an up to date svn checkout, machines in the 'development' environment will get your development version of the apache module you still need machines to test with, they still need to talk to a puppetmaster but this helps you isolate versions of code. Since development also still point at common should your apache module rely on your php module then it would just grab it from common (unless you also branched that). Now you're done testing, you're happy it works and you want to make your apache module the same as devel one everywhere, just merge the changes into common and 'svn delete development/modules/apache' when done. Now all machines have the new module and you've been able to test it in isolation on your dev machines. This is a very simple approach it, maybe you have releases every tuesday, or maybe you have multiple environments between dev and production, you can adapt this approach to those no doubt I just kept it simple to get the concept across. For example many places have an environment per developer so they can just have their own test boxes (maybe VMs on their desktops). -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
