We use Git here and we tag branches to certain environments. We have a testing branch which everyone commits in to and what most of our testing machines are using. We then have other environments like Staging and Production that have specific tag checked out that (will eventually) align with our Developers' Continuous Integration and Agile release cycle. Our testing environment has lots of micro check- ins, commits for every little syntax error I make. To test a specific machine though, I often temporarily change the environment back to Testing to make sure nothing is broken, then switch it back to it's real environment. This is because we don't have a test machine for every single system (staff workstations, etc).
The idea we're aiming towards is that all Puppet changes up to the end of an iteration will be included in the next release. A tag is "cut" and checked out into the Staging environment. All those changes get applied and our own Developer written code is tested alongside any Puppet changes. If there are any problems we can update the tag, same as if there was a bug in our code's release candidate. Then when our code goes to production, we check out the production Puppet environment with the same tag (plus any updates). On Oct 18, 9:52 am, Andreas Paul <a.p...@enbw.com> wrote: > Hi, > > we are currently managing our puppet modules with one SVN workspace for each > admin. > The post commit hook script updates /etc/puppet/ directory and triggers the > puppet kick of the correct server. > > The problem we have with this solution is that sometimes there are many > small checkins to one change, because the admin forgot to change small > details in the config file, e.g. forgot to change the access logfile name of > the vHost, forgot a redirect, misspelling in the comments etc. > > What we end up with are many micro checkins, which can be used to tell every > small mistake the admin has done. > > What we want is a solution which lets the admin test his changes on one > server without checking these changes into the "main" SVN repository. > So that the SVN repository only contains the final releases of the changes. > > I have to say that we also manage the dev and QA servers with this > puppetmaster. Would dividing of these different stages into puppet > environments help us? > What I really want to know is, do you understand my problem and if you had > the same problem, how did you solve it? SVN branches? Multiple > puppetmasters, one to test with a dedicated test SVN repository? > > Thanks! -- 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.
