Managing Software Releases Effectively

 Software release process varies from organization to organization depending on the kind of the business and development team. When the team working on a software product that is geographically dispersed, the software releases throw more challenges. The process should not even be thought without a global release manager (GRM) or a release co-coordinator or a central release management tool. A solid build/release infrastructure has to be in place.

What's the difference between build and release?

Let’s clarify certain terminologies before proceeding. We often use the terminologies build and release. Sometimes we use these terminologies interchangeably. However there is some difference between build and release.  According to me builds are the deliverables that are used by developer themselves and testing teams internally and releases are something that we hand it over to our end customers.

How do we perform the builds?

Each programmer can build the project source code he/she is working on and continue the work, however this is bad practice. A programmer's code may work well because its not yet merged with every other programmer's code. So as a best practice the builds must be performed by a system that is updated with the latest source code of the entire project.

For effective builds, the build process needs to be automated and continuous improvement tools such as Hudson, CruiseControl etc should be used. I prefer and suggest Hudson which is easy to use. The builds can be categorized into different types as Daily Builds, Weekly Builds, Force Build etc and these builds are triggered by Hudson running on dedicated computer (we call it build machine).  Daily builds ensure that there are no compilation errors.Daily builds are also referred as nightly builds since they are triggered during the night.  Apart from daily builds, the best practice is to initiate builds every time when there is CM change (source file check-ins into repository) and build machine configured to send mails to all team members if there is a build failure. We can configure Hudson to send build failure emails to the commit author due to which the build was failed.  We can enable this kind of builds once the source code is stabilized and every team member are required to be cautious about the code stability. The problem is that if a particular commit by a team member caused a build failure, the other members in the team can’t proceed with their work unless the build failure is corrected and hence it’s important to know what change and by whom the build was failed and same should be corrected by the member as early as possible.To exploit the real advantage of having daily builds is to run automated test cases after the build, by seeing the test execution reports we can better understand how well the code changes are being integrated. 

Managing Software dependencies 

Some software products have dependencies on other software may be developed by the same company or a third party company. It depends on the software product design. Most of the product development is to develop the reusable software pieces. We called them core assets and some may call them as reusable library (in the forms of dll files or java jar files etc). Core assets are software components which are tested, stabilized and ready to use. Core assets can be compared to car parts. To manufacture a car, first the car spare parts are made and then they are assembled together. There can be changes in core assets from one release to another and since a core asset may depend on another core asset, all dependent assets must also be rebuilt along the asset where the change was made. The build machine should be configured to handle these dependencies automatically. Imagine there are 100's of reusable software components and if you are required to modify at least in 10 components, its tedious job to manually identify the inter-dependencies and make releases.

If the product is internet based, the product can be programmed to download all the required versions of dependencies from the web during product installation. 

Packaging(Bundling) the software into an executable 

Any software consists of multiple files such as jar files, dependent software component files, resource files, icons, text files etc. All  these files have to be packaged into a single executable file called Installer. InstallShield is an example. This makes it easier for our customers to install the software product. See how to make executable installer using Java. The packaging process has to be automated, we can have a packaging script that knows what files to package into an installation file. Its important to make it very simple for the customer to install the software. Special care has to be taken when customer is upgrading to new version of the same product. Installation script must be thoroughly reviewed and must not pose any issue after product up gradation. 

Releasing the Software product to customers 

There are various channels as to how a product reaches the customers. It could be contractors, marketing people or through advertisements over the web. The internet media has made it simpler for the customer to access the new product these days.The new product release can be published in the companies websites giving download links for the customers. We did it using Hudson server itself, the company contractors can download the software from build PC and then distribute it to the end customers. I mean it depends on the marketing model of the company.

Certain questions must be asked and answered before releasing the product to the market. I've tried to summarize few, there could several such questions to be answered.

1. Have all the test cases covered and passed? - Test coverage is very crucial
2. All the deployment scenarios have been tested? - Its very important to understand the user deployment scenarios. Not all the customers run our product in power PCs and speed network connectivity.
3. Are there any critical issues still open? All critical issues must be resolved, certain marginal issues can go as open issues.
4. Is the software release bulletin been prepared? - The Software Release Bulletin (SRB) has information on what are the various product deliverable, open issues (if any), installation instructions etc
5. Has the intent of releasing this version of the product  been documented? - This is required because a there will be several product releases and over the time, one needs to know why this version of  product release was made.
6. Is the user guide complete and covers all the functionalities of the product?  - This is very important if you are launching an entirely new product. User guide(manual) is one aspect, its also important to have some training sessions with the customers about the new product.

In Summary

Software release processes must be given more attention because these are the processes that are almost ignored and also since software releases management directly impacts our customers. Its advisable to automate the software release activities and standardize them as much as possible since manual activities are always error prone. Also its good to write something called Build Verifier that will verify the if the build/release was done properly, doing it manually will still be error prone. Build verifiers can  check if the required versions of project files/dependent files  have been bundled/packaged etc.