of Joel on Software  talking about extending HTML to make web applications work better, and Joel's piece on How Microsoft Lost the API War  suggesting that making DHTML work better in Internet Explorer was too dangerous to Microsoft's core business as it would make servers more of a commodity! Worth a consideration. For an internal product where you have more control of the desktop software and capabilities, such decisions can be much easier - choose the architecture that makes development easier.
The concept of application services provision by companies such as Salesforce.com can also make life a lot easier for customers (at the risk of entrusting your data to a third party). As an ASP, producing new releases is vastly easier with full control of all the servers and the data.
The environment in which a system functions is very important. This includes many items such as databases, third party systems, specialised hardware etc. Not only do you have to consider compatibility between releases of the system, but testing can be very difficult. Resources to fully duplicate live environments can sometimes be prohibitive, requiring more risky testing procedures. Anything that can be done to minimise the dependencies on such external items is going to make releasing easier.
Databases are a common challenge for controlling using CM tools. You need to identify structure changes, upgraded/downgrade scripts, etc. Enough for a whole article on its own!
There are many applicable patterns for the process of development which can ease releasing of software. It has long been understood that software design principles such as modularity, cohesion, coupling, understandability and adaptability are all of benefit, and these carry through to the releasing of software.
These days, the production of software as groups of components is very widespread since it builds on these principles, and makes the construction of larger systems from component parts more manageable. I liked the metaphor mentioned by Laura Wingerd of Perforce Software at the BCS CMSG 2003 Conference : it is easier to take a group of 40 adults on a trip than 5 children. The adults can be treated as components each of whom is responsible for their own luggage etc. For the children, you have to ensure they have packed appropriately down to the last toothbrush.
There are a number of SCM Patterns particularly applicable to releasing. From the book of the same name by Berczuk & Appleton , I would like to briefly mention:
- Task-Level Commit
- Integration Build
- Release Build 
- Smoke Test/Regression Test
- Release-Prep Codeline
- Codeline Policy
For more details, please see the book and previous articles in CMCrossroads.com "Agile SCM" column (particularly , and )
Producing Release Notes
From my personal experience of managing releases, I have found one activity to be a key indicator for process health - the production of Release Notes. These are typically a list of changes: bugs fixed and features added. They are very useful to everyone to understand what is in the release, how it differs from previous releases, and whether a particular problem will be fixed by upgrading or not.
I have certainly had the experience of producing release notes being a major chore. Having volunteered (or been volunteered) to do the job, I had to find out what had changed. The first approach was email all the developers asking for a list of changes. One deafening silence later, and I would go around and bug them in person until they gave me some sort of list. This I would use to compare with and revise the project manager's rather optimistic list of changes. Being a