> > > It works fairly well but not perfectly. Problems are: > > 1) It's fiddly. From my cloned repo I have to switch to my branch, > make the change, commit, push to the central repo, switch to testing, > merge with my branch and then push to the central repo to get a change > live. For most things that's fine -- I want to be sure -- but when a > developer comes along and wants a rewriterule fixed or some other > simple change or feature request that's already signed off from above > it's a bit of a task to get it live. (Perhaps we should consider > storing application configs elsewhere, in a more straightforward repo, > or building them into an RPM or something.) >
I guess the real question is which kind of changes do you have in your environment. once you identify them, you could have an action plan for each type of change.. e.g. changes that really effect system services (must be coordinated), changes which are minor and doesn't effect the application/server productivity, changes which effect only a subset of hosts etc... I ended up with having 99% of our modules tagged, and having one module which is polled from trunk/head. this allows the admins to push changes immediately if needed by inheriting the correct class in this module. the tricky part is that you must audit this changes, and over time inherit them into your stable environment. you could break this even deeper to manifests changes/ file changes (which is simply permissions in your version control - e.g. who can check in this file). > 2) Git's distributed approach is a bit confusing (read: I don't know > how to work it). Local branches tracking remote (central) branches, > pushing a local branch to a remote branch, etc, makes my brain ache a > bit. SVN's versioned-tree model might work better, especially if you > can just set tags representing testing and production and check those > tags out to the puppetmasters. However, Git's branching does make it > possible to develop several features in parallel, which a tagged > approach might not give you. Swings and roundabouts. Git has tags but > I haven't yet figured out how they work. hmm.. Learn git or move to subversion ;) > > > 3) I haven't worked out how to get the central repo to push to all the > puppetmasters. Like Paul, I don't want this to happen automatically. > What I really want is a way for admins to push their changes to > testing, have this action recorded and sent to a mailing list (with a > diff!) by running a single script on the central repo. Same for > production. Currently this happens when an admin merges changes into > his local testing/production and then pushes these branches to the > central repo, which I think might be asking for trouble. > If you have a stable pretested environment, why don't you want it to be pushed to all of your puppetmasters? do you really want to allow all of the admins full access to each puppetmaster? in my environement, each puppet masters update the "stable/testing/development/whatever" code automaticily (with cron or in the puppet run on the puppetmaster itself). in general, no one is allowed to change the tags, the worst thing that could happen is that someone checkin a broken manifest to trunk and then (if its not reject by a puppet --parseonly hook) you can fix it, but in no way it effects your running production clients. > > Sorry, this is a bit rambly -- early morning and all that. I'm on the > Puppet course next week so I'm hoping I'll learn The One True Way > then. Hmm... I can tell you that it took a loooot of time to get things running they way we need them to... most of this time was just to graspe the change managmenet processes..good luck :) Ohad > > > Cheers, > > Mark > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
