Act Like This is the Release

I think the single most important part of Release Engineering (RE) is the principle of "act like this is for the release." There may be times that this is too extreme, but I think that keeping this as a guiding principle will do more good than harm.

For instance, instead of having one process for developers to build during development and another one for release, try to use the same one. That way, when it comes time to release, the path is well worn and more easily reproducible if necessary.

That's hopefully a pretty obvious thing to do, but it isn't always obvious for developers. How many times have you heard "well, it builds for me, it must be your build scripts!" :-) The more closely integrated RE and development are, the better the chances of having a smooth and easily reproducible release.

IMHO, RE should pervade every aspect of development (to the level appropriate) and be involved from start to finish. Now that I think of it, this is akin to "test early and test often"; having QA activities/mindset pervade every aspect of development.

As to where the boundaries are between development, SCM, RE, I think that depends on the organization. However, when possible, I think it works best to have somebody with a big-picture view of all activities to be responsible for SCM/RE and for that to be their first priority. It seems to me that when this is given to somebody in development who does not have the big-picture and it is a second or lower priority, organizations run into trouble. By the way, by "big-picture" I mean somebody that is familiar with how development does things _and_ is very familiar with good release engineering practices and has done a variety of releases for different kinds of projects.

This may not always be possible, but the closer an organization can come to having RE/SCM be an important role (as opposed to an afterthought), staffed by somebody that knows when to branch, label, or lock, when to use parallel development, which SCM product is right for an organization, how to set up a good build system which integrates well into the release process, etc., the better off that organization will be. Of course, you may end up with some developers grumbling about how their freedoms have been restricted, but hopefully they will soon realize that a little more discipline is better than broken builds and long post-freeze settle times.