Late last week I spoke with a manager who asked me about my release process. While I have worked in many shops with different patterns, I thought it would be of value to show the pattern that I would use if I had that form of control. This article is just a "top of my head" and there will be additional details added as I think of them and, of course, you should adjust these as your requirements demand.

Of course some of these items are obvious, but the number of times I have encountered processes that are opposite the logical flow "just because".

Specifications

Getting customer ideas. I prefer to get as many users involved in the initial request. Knowing what everybody wants helps me to plan those functions before I write myself into a corner that I later have to untangle. Of course not all features are going to make it into the initial release, if ever, so it's also important to manage the users expectations so that they are less disappointed when they don't get those functions. (and they will be disappointed and they will say; "you promised" when in fact you have not promised.)

Divide up the tasks into manageable pieces. At this moment in history, especially with web based projects, it is often better to make smaller and more frequent changes. This gives the users some of the functions they want asap.

Documentation! Do it up front, like source code comments they are an investment that will pay off sooner

Development

All developers should be using source control such as Source Safe, CVS. No excuses! I use source control at home.

Bug tracking systems such as Bugzilla

All database changes are to be scripted!

Always use stored procedures. There are some who believe that using stored procedures is not of value, I disagree.

Release

I prefer to have a three tier enviorment: Development, Test, Production

Backup Production enviorment (obviously daily!) and restore to Test. Register new components, run scripts and then run test scenarios. (for more detail on testing consult someone else. I do extensive function testing, but I strongly believe that testing should not be do by developers and definatly not done by the developer who wrote the code. The person who wrote the changes has the suposition of what should happen. To remove this issue, at the very least a different developer should test the changes. The specification written in the first step should be a good start, if not a complete document on what should be tested.

Releases should be scheduled for a time of day and day of week that is least likely to affect the most amount of users.

Additional:

Backups of source code, documents, database and all other documents should be done, at very least daily and stored in an offsite location. There are too many encrypted cloud based services to not having a backup. (yes, I have worked at companies that did not have backups)

Quiet space. Developers need personal space, their own office so that they can concentrate and give you the project results you need.

Good computers: Developers should not have to work on a 4+ year old computer. Period. Spent the money and make the developers happy, or management will spent much more money in lost time.