Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] "staging" grimoire instead of devel for development spells as opposed to WIP spells?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] "staging" grimoire instead of devel for development spells as opposed to WIP spells?
  • Date: Fri, 25 Feb 2005 18:12:59 -0600

On Feb 25, Andrew [afrayedknot AT thefrayedknot.armory.com] wrote:
> On Fri, Feb 25, 2005 at 02:47:22PM -0800, Eric Sandall wrote:
> > We could have a machine (or better yet a cluster of machines) who's
> > sole job is to do the following:
> > 1) Update test and stable Perforce repositories on the machine
> > 2) Pull in changes from test to stable that have been in test for at
> > least two weeks
> > 3) Resolve the differences (probably `p4 resolve -at`)
> > 4) Run Prometheus[0] on what's in the not-yet-submitted stable
> > 5) Once Prometheus is done, revert any spells that failed and then
> > submit the rest
> > 6) Rinse and repeat every week/two weeks/month/whatever interval we can
> > get
> > Prometheus to finish the stable grimoire in. ;)
> >
> > Would this be feasible or even wanted?
>
> I think its feasable and was one of the ideas I had in mind as well.
>
> If we took test moved it to a staging area, had a bunch of machines crank
> on it for a while, then have a task force to fix problems that show up,
> verify them with prometheus, then back port to devel/test.

From a code promotion perspective you usually don't want to be making
changes in the staging area and then backporting them, you want to be
making changes in the dev area (even if it doesn't look broken there) and
then promoting them in the staging area to confirm they're fixed. If you
backport you *will* miss pieces and just have to go through more iterations
to get it all to build, or worse yet will promote something as working when
it isn't going to work in a clean environment.

> Then repeat until all the problems are either minor or solved, then
> release that as a our stable grimoire. Do this over a one or two month
> cycle or something. Then while the next stable is being worked on some
> other fixes will show up that might be needed/wanted such as security
> fixes, at that point have a subset of machines/people test it, once they
> mark it off have a new minor stable release. Basically we'll have a 4th
> branch thats tagged off of test once a release cycle.

The phrase "release cycle" makes me nervous. ;-) I think a lot of people
come
to source mage to get out of the release cycle treadmill (yes, even a rapid
one like the one discussed here).

It seems to me the way sandalle described it is simpler and pretty much how
this problem is normally solved in software development. You basically
have 4 environments:

1) Devel, anything goes.
2) Test, developers promote things here to see if they work and just try
stuff out.
3) Staging, developers promote things here when they believe they work and
are ready for stable. This environment looks 100% like production does,
except for the changes being staged. NO CHANGES HAPPEN HERE. If
anything fails it is reverted and has to be fixed in devel/test, then
try again (think atomic commits).
4) Stable, things are promoted to here once they pass staging, usually
automatically. If staging is done correctly, there are never any
surprises when things get to stable.

I think this is what sandalle described, with the staging environment tests
and pushes to production automated and everything still getting promoted
per spell after 2 weeks in test (if they work). It's also similar to what
swoolley described, except he was reversing the use of the terms staging
and test and wasn't formalizing it as much.

Attachment: pgpdiKsVAKkmm.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page