I'm in an extremely large and structured environment....
(yea, corporate life!)
And I wrote a post that almost exactly matched Scott's. So I erased it and wrote this instead:
A couple of (other) thoughts:
The ultimate goal of the process of Build/Release/Promote is Repeatability.
If special steps are required to get a release into QA, they should be documented and followed each time a release goes into QA. Anything that is one-time-only should be viewed with suspicion.
Source Code control (RCS, CVS, PVCS, Clearcase) - absolutely required, in my opinion.
Our code is too large to have everyone compile it. (It would take too much space and time). In these cases, we've modularized our code out and created stubbed out services for others code that we call (but which we won't build and aren't responsible for.)
Testing should be built for every single module. I wish we ran our unit level tests as part of the build process. :-( We do have unit level test automated and we run them every single single time they're a change.
I'm currently working on similar testing scripts for the higher levels of testing. (Perl is wonderful.)
I strongly recommend that users get to see test results as early on in the testing cycle as possible. (We unoffically get them involved at our level 2 testing when process calls for them to be involved in level 5 testing.) (Speaking as a person who's misinterrepted user requirements far too often.)
