I'd like to throw out my own question about version control. I've finally finished my initial policy files for our pilot deploy (for the most part; need to update comments). There are four files that we currently maintain/edit: promises.cf, dg.config.cf, dg.library.cf, and dg.bundles.cf. The rest of the files in our masterfiles directory are untouched from the Cfengine defaults. (We may split dg.bundles.cf into one file per...policy setting(?)...but that's a separate issue.)
I plan on importing our policy files into Subversion next week. Would it make sense to import the entire masterfiles directory or just the files we modify? Thanks, Justin From: help-cfengine-boun...@cfengine.org [mailto:help-cfengine-boun...@cfengine.org] On Behalf Of Jessica Greer Sent: Thursday, March 04, 2010 4:52 PM To: help-cfengine@cfengine.org Subject: Re: Version control best practices? Thanks to everyone for the responses - that's helpful. Tim, I especially like your idea of mailing out diffs, so everyone stays in the loop, and teammates don't have to alert each other by hand. What are your sandboxes like? Do your non-prod branches just contain promises that pertain to testing hosts, or test versions of services? How do you handle "promoting" a promise/bundle from a test environment to production? What's most intuitive to me is one single repository, letting Cfengine classes handle test and prod environments within the same file: files: class1_prod:: "do_something_safe"; class1_test:: "do_something_gutsy"; The obvious downside to me is that this doesn't protect against human error during the testing process - production promises could be accidentally altered when you've got your hands in a file that drives both environments. But there's where revision control bails you out, right - rolling b...er, forward to a known good state? Am I missing any other advantages to breaking environments out by branch? -Jess On Thu, Mar 4, 2010 at 12:01 PM, Tim Cutts <t...@sanger.ac.uk> wrote: On 4 Mar 2010, at 4:45 pm, Jessica Greer wrote: > Anyone want to share advice on using SCM/revision control software to manage > Cfengine configuration? > > I've recently joined a group where several people will be editing inputs and > masterfiles, and it'll be important to have a clear picture of what changes > have been made and by whom. > > Yale is using Bazaar for several other projects, so if anyone has feedback > on Cfe+bzr, I'd be especially interested. We use CVS (just because the momentum of moving to anything else has been to great - if I were starting again, I'd use something else; git, subversion, bzr, it doesn't really matter which). We add hooks to the CVS repository so that when anyone commits something to the CVS server, a diff of the policy change is emailed to relevant parties automatically. And of course, because the commit happens in a sandbox, it hasn't gone live yet, so there's an opportunity for objections before a CVS update is run on the policy host. You could do similar things with any of the other version control systems. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- ------------------------- Jessica Greer Unix Infrastructure and Virtualization Information Technology Services | Yale University (203)436-5205 | jessica.gr...@yale.edu This electronic communication and any attachments may contain confidential and proprietary information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee responsible for delivering this communication to the intended recipient, or if you have received this communication in error, please do not print, copy, retransmit, disseminate or otherwise use the information. Please indicate to the sender that you have received this communication in error, and delete the copy you received. DigitalGlobe reserves the right to monitor any electronic communication sent or received by its employees, agents or representatives.
_______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
