Should we promote source code or built binaries?

One of the interesting tensions we see is in how various teams promote approved or tested changes towards production and release. In an ideal world, our developers would work on various bug fixes and new features and as we neared release, a release manager would select the features she wanted and the bug fixes that were tested, create a build based on that source code baseline and release it. Many source control vendors (especially those with more expensive products) push this approach. 

Unfortunately, the changes made for one item on the list can impact other change items in unpredictable ways. A common alternative is to have everyone work on a shared branch. Indeed this is a standard CI practice. When a build is completed, the produced artifacts are tested in various environments, gain various approvals and some builds are eventually released out into production.

This build promotion model is great, in that it gives us the more realistic tests and addresses the problem of unanticipated impact seen in the source code promotion model.  However, we've lost the ability to pick and choose exactly what changes we want to include in our release after the work has been done - we can only make that decision before the work for a release is done.

The trend seems to be towards the build promotion model, and that's one that fits quite neatly in AnthillPro's model. The most common other approach that we are seeing is a two stream model. The first stream takes all developer changes and does CI builds against those. These builds off the development stream tend to only be sent to early testing environments. The second stream, receives changes promoted by a release manager from the first. These promotions kick off another build that goes through all the testing environments - retesting the changes to make sure they still work when assembled in this combination.

This tension between being able to pick and choose features and fixes and actually testing all the changes working together is an interesting one. Neither the classic, "Promote this source change to Production state" approach pushed by many SCM vendors nor "do everything in one stream" approach present in classic CI provides us the control, flexibility and testing that are needed in some environments. Given the choice, I'd lean towards doing everything in a single branch or stream, but I think the hybrid approaches are gaining some traction.