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
