views:

181

answers:

2

Given a pretty basic source tree structure like the following:

trunk ------- 
   QA  |--------
     Stage |-------
        Prod  |------

And an environment which mirrors that (Dev, QA, Staging and Production servers) - how do you all manage automated or manual code promotion? Do you use a CI server to build and promote at all stages? CI at Dev to build the binaries which are used throughout? Some other hybrid?

I've been kicking around a couple of thoughts. The first being that each promotion would do a get latest, build, and then push the output of the build to the correct server. The second being that at some point - QA or Staging - the binaries that were promoted would be the exact same ones copied to the other stages. The third is keeping a secondary source tree for deployed binaries which would automatically move in lockstep with the code promotion. Any other thoughts or ideas?

+3  A: 

You want absolutely no possibility of the production code not being identical to the one QA tested, so you should use binaries.

You should also tag the sources used to create each build, so if needed you can reproduce the build in a dev environment. At least if you make a mistake at this point, the consequences won't be as drastic.

Mark Ransom
Completely agree, pushing anything other than the tested binaries to production is a mistake.
HowardSP
+1  A: 

We make use of CI at the dev stage, and use daily builds that are promoted. These daily builds, if successful, are tagged in SVN so that we don't need to keep a seperate copy of the binaries. Any third party libraries referenced are also included so that a tag is an exact source copy of what is compiled.

Darksider