teams for development/staging/production (take 2)

In a previous message, I kinda dissed Harlan for thinking
about ARK *teams* as a configuration-management tool; here's
a snippet of what he said:

> 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

A variant of this crossed mah wee brain, which showed that
Harlan was Onto Something.  File this message under "weird
things you could do with ARK"...

Imagine having two teams, 'devel'(opment) and
'prod'(uction).  'devel' would assemble things to be
deployed on production machines; however, it *wouldn't even
have* methods for deploying and revealing!  In fact, its
'install' method might simply produce RPMs (or equiv) of the
bits to be deployed/revealed.  (Hi, Paul :-)

Meanwhile, 'prod' *wouldn't even have* methods for
compiling/checking/installing!  It wouldn't know how to do
anything but accept the RPMs from 'devel' and splat them
around in a productionly manner.

By doing it with teams in this way, you set up an 'air gap'
between development and production which cannot be crossed
by mistake.

(Harlan, keep those ideas coming...)

Will