Previous Article in this Series
Do a thorough QA

Release and Deployment

Many teams consider testing and bug-fixing as the final piece in software development. Well, we are getting there. But you should not let your guard down till it is done as in D-O-N-E. It is human nature, unless controlled by rigorous processes, to become a bit complacent when things have been satisfactorily done till the previous stage.

Companies make the mistake of assuming that handing over of the code and any other required documentation constitutes the completion of the project.

Hang on! Don’t let all the good work done till now be adversely impacted.

Releasing a product is serious business. And, therefore, you should set detailed criteria on what constitutes a release and get an agreement with the client right in the beginning of the project.

When objective rather than subjective criteria are developed, there remains no ambiguity in anyone’s mind about what constitutes a release.

For example, instead of stating that “no serious bugs should remain in the released product”, you could say that “in the release:

• No showstopper bugs are allowed
• No High priority bugs are allowed
• No Medium priority bugs are allowed
• Product can be released with Low priority bugs

In addition:

• No showstopper bug should have been identified in the last 2 days
• Not more than 5 Low priority bugs should have been identified in the last 2 days”

…and so on.

You must also take care to define what is “showstopper”, “high priority”, etc. For example, a “showstopper” is “one due to which one or more of the system’s main functionalities are completely unusable, and there is no work-around.” There should be no scope of interpreting the nature of the bug based on individual “feelings”.

The release must also be accompanied by a document listing the known issues and the plan for fixing the issues.

With these, the product can be deployed on the client’s server and tested yet again to ensure nothing strange happened during transfer. Of course, the specifics depend on the agreement between both the parties.

Releases must be managed through appropriate branches in SVN as well.

And after the final sign-off, have a meeting to document the learnings from the project, the good, the bad and the ugly. This will help you strengthen the positives and avoid or minimize the negatives in the next project.

It, after all, is a continuous learning process.

Only about 10% of an iceberg’s mass extends above the water surface. We have scraped only the tip. But the tip presents a beautiful sight in itself. What you have learned here will surely hold you in good stead.

Have fun managing your software development projects. Good Luck.

We will surely appreciate your feedback on this article. Please do not forget to visit and watch out for our soon-to-be-released product, Celeroo Builder.

Please subscribe to receive updates.

By the way, there is the Resources section next that will help you find a lot of useful information and tools. Many of the resources have more resources ensuring that one day you will get to the bottom of that iceberg and appreciate its full beauty.

Disclaimer: We are not related to any of the companies offering the software tools we have referred to in these articles. But we have used most of them in our work and found them to be useful.

Next Article in this Series
Further reading

Discussion

790Commentshttp://www.celeroo.com/blog/2009/02/plan-and-execute-software-releases/Plan+and+execute+software+releases2009-02-11+09%3A54%3A30Celeroo for “Plan and execute software releases”