On 1/4/07, Stephane Bailliez <[EMAIL PROTECTED]> wrote:
Andreas Sahlbach wrote:
> We have a 4 phase staging process. In our team we are working on
> trunk. We have a nightly build that is building trunk to our
> development stage, so we can see if it basically works. If we think
> that it works, we are moving exactly this build to our integration
> stage, where we are connected to several other projects that closely
> integrate their test environment with ours.
>
> After a longer testing period, we are moving this build our QS stage.
> At this stage we should be function complete. In the QS stage we have
> a lot of tests, including stress tests and so on, which are made from
> different departments. Also functionality is tested by the customer
> and we are running here in a similiar firewall environment as in the
> productive stage.
>
> If we pass all tests, we can go live. In case of needed fixes we are
> branching the release build, put the fixes in the branch and of course
> merge them back to trunk. Hotfix releases are made from the branch of
I miss a few transitions in your process.
I don't see any mention of stable branch nor tagging, you seem to branch
the release by going backward to the revision of the nightly build that
you picked up one day (how long before ?) that happened to work.
I don't see how with constant work on trunk you can manage what really
goes inside the release and eventually cherry picking of commits.
Assuming your build is mostly fine but need 3 commits which fix critical
issues for the release and there has been 150 commits in between your
'picked nightly build' and the final QA report, how do you do it then ?
You branch the build and merge the 3 fixes ?
-- stephane
That's right, I did not mention branching, sorry. Ok, if we have
reached the QS stage, we are usually function complete. If we find a
bug in the QS release, we create a branch from the QS release build.
As I mentioned before, I am automatically recording the svn version
and url we have used for a build. So if I need to make a branch I can
easily do this with the information found in the war/ear or whatever.
We are doing fixes in the branch and create a new build with a
different patchlevel. This new build is deployed on the QS stage for
further testing.
When we reach a productive ready state, we are deploying this build to
productive and then I tag it with a release tag.
Ciao,
Andreas
--
Andreas Sahlbach
