Re: [Infrastructures] FW: Version control checkout

[Luke A. Kanies]

On Tue, 30 Mar 2004, John Sechrest wrote:

>
> Luke,
>
>       This is an interesting path. We have been keeping
>       system configs in CVS and using cfengine to check them
>       out too. However, the system admins got a bit confused
>       about how to represent the testing tree vs the production
>       tree. So they could not roll in a test, try it and then
>       roll it into production.
>
>       How would you approach the branch for testing vs production,
>       so that you can watch the checkout happen on the testing
>       system, and then once it works all the way thru, roll it
>       into service on the production instances?

Well, first let me categorically say that I do not believe I have solved
this problem completely.  With that...

I consider this problem in two phases:  Initial deployment of a new
feature, and later deployment of changes to a feature.  And then there's
the definition of feature that gets a bit fuzzy at times; I'll cover that,
too.

The initial deployment is pretty easy.  Nearly every one of my cfengine
config files looks a bit like this:

groups:
  deploy_feature = ( host1 host2 host3 )

control:
  host1|host2::
    feature_detail = ( "this is some detail" )

  host3::
    feature_detail = ( "this is some other detail" )

  deploy_feature::
    actionsequence = ( shellcommands.featureness copy.featureness )

shellcommands:
  deploy_feature.featureness::
    "/bin/do/something"

copy:
  deploy_feature.featureness::
    ${filesource}/file dest=/path/to/file

------------

This handily covers the initial deployment.  You can use classes (or
roles, as you call them) to determine who gets the initial deployments,
and you can slowly increase the deployment rate as your confidence grows.
I've been using this method for maybe 1.5 years and have had great
success.  It is definitely my favorite stepped deployment method yet.

Things get painfully more complicated when you start talking about
upgrades in a feature.  Deploying new data is usually not that difficult
-- you test the data on your development systems, then move it to
production.  Following the above example:

groups:
  deploy_feature = ( any ) # it's now deployed everywhere; this class
    # could really just be removed now

control:
  AllowRedefinitionOf = ( feature_detail )
  feature_detail = ( "" ) # yes, you have to init cfengine vars for this
  Development::
    feature_detail = ( "${feature_detail} one two three" )

  Production::
    feature_detail = ( "${feature_detail} one two" )

....

Like I said, that's pretty straightforward.

But what about when what you're deploying is new code itself, or a new
organizational method for the code?

This is the part of the problem that I consider unsolved.  I've played
with using CVS branches, but given a typical site with 4-10 cfengine
modules, 20 or so cfengine config files, and maybe 50 different config
files, how do you do the brances?  Per file?  Per tree?  It's not
straightforward.

I basically usually test the code on a few systems manually by putting it
all in place and then running cfagent on /var/cfengine/inputs/cfagent.conf
directly so it doesn't update itself.  Once I'm satisfied that everything
works, I check it all in and hit go.  Yes, this has caused problems in the
past, but surprisingly few of them.

I definitely agree with Steve Traugott that modifying an already-deployed
script is a dangerous game, but I also think it's absolutely required for
the long-term support of a network.  I've had good luck with the above
methods, but I know that I'm going to cause some disaster one of these
times.

I'm perfectly happy with my initial deployment solution, but I would love
to hear others' ideas on how to do the later staged deployments of new
versions of code or new ways of solving the same problems.  It's a
difficult problem.

Luke

-- 
"The optimist proclaims that we live in the best of all possible worlds,
and the pessimist fears that this is true."
                -- James Branch Cabell 1879-1958