development/staging/production

In an off-list message on another topic, Harlan came out
with this Rather Good Stuff; I am taking the liberty of
replying publicly.  [Some reformatting...]

> I'm also wondering if there is a general need for separate
> areas for development, testing, and production "roll out".

*YES*.  This kind of thing has to be possible.  But it
mustn't be mandatory -- ARK is also aimed at the 4-8
hosts on your home network...

> For example, the sidai team is a production team.

Whoa!  There's nothing to stop you using teams that way, but
I wouldn't.  Sidai is a "policy" team -- it advocates
certain ways of doing things, e.g. "build packages from
source", do the "install/deploy/reveal" gig, use Amanda,
... :-)

> At some point, people will want to do development on that
> team (on some number of potentially different items), and
> each developer will probably want a sandboxed "roll out"
> area.
> 
> Once a development milestone has been reached, I can see
> that the changes should be integrated into a testing area,
> which would need to be tested/reviewed by other folks.
> 
> Once this revision of the team has been "accepted", it
> would be put into production and rolled out everywhere.
> 
> There are a number of ways to do this:
> 
>     sidai	   The production team
>     sidai-test   The staging area for the next production release
>     sidai-will-23  a development team for, say, Will's #23 TODO item
> 
> Part of me thinks that bitkeeper repositories
> <http://www.bitkeeper.com> may be an easier way to handle
> this rather than using different team names.

Ah, yes, *exactly* (though I certainly wouldn't mandate
BitKeeper; incidentally, my hot tip is
Subversion... http://subversion.tigris.org/).

In CVS terms, I would have a workspace (cvs checkout...) for
production, another for staging, and one each (at least) for
each developer.

Each host would be tied to a workspace.  Each developer
would be given one or more machines to mangle -- they would
be "tied" to the developer's workspace.  ("Tying" requires
nothing more than setenv'ing ARK_PROFILE to point to a
particular file.)  Developers presumably work against the
HEAD branch (cvs'ly speaking).

Then you'd have a small group of machines -- one of each
type, probably -- tied (perhaps temporarily?) to the
"staging" workspace.  This workspace would be 'cvs update'd
against a not-yet-in-production branch.

All the other machines would be tied to the production
workspace.  This workspace would be 'cvs update'd against a
(stable) release branch.

> Regardless, I don't know what else might have to be
> addressed "inside" the team spec to identify this.  I do
> know I HATE having to change things in multiple places
> when going from development->test->production, so I'd
> prefer to have an XML gizmo (attribute/entity) that
> specifies the "state" of the team and have the filename
> generation take this value into account.

As I suggest, solving the problem w/ your CM system rather
than your team stuff, avoids this (real) problem.

There is a currently-empty web page about "sysadmin
configuration management"; source is sidai/webpages/scm.txt.
I would like to write it as a response to the (imaginary)
scenario of four sysadmins trying to manage a 400-host site.
(Actually, I think there's a proper paper to be done on this
stuff...)

Back to teams: I can imagine a 'sidai-plus' team which says,
"Yes, we agree with how Sidai does the low-level stuff; but
we need a strict development/test/staging/production
approach on top of that".  The prototyping machinery will
let you set this up quite easily: where `glasli1' has...

   <prototype team="sidai" name="GNU" />

... you would have ...

   <prototype team="sidai-plus" name="GNU" />

... or perhaps ...

   <prototype team="sidai-plus" name="ALL" />
   <prototype team="sidai"      name="GNU" />

(The latter would work if 'sidai-plus' didn't introduce much
new <code>; instead, it just <param>'d existing sidai code
to make it do the right thing.)

Somebody please yell if I'm talking b******s.

Will