Software Release Management System Requirements
We have gone through a requirement process to identify the key requirements for Tonido‘s release management. I thought this requirements would be useful for other developers too. So here are the key requirements that we have identified.
- Continuous Check-In – Team members should use SCM (In our case subversion) for any code or artifacts that they create and it should be checked ASAP. This will help us to have only one repository for all our artifacts and code needs.
- RMS (Release Management System) should build the application in all the OS’s we intend to support daily or triggered by a change or update in subversion.
- RMS should have a web front end that will allow the team members to see the results of a particular build from a browser. Further, it should provide an interface to start a build through web interface.
- Every build should have a build number. In our case, we are using the subversion revision number.
- Every build should have a build version. Build version format is Major Version: Minor Version: Patch: Build Number
- RMS should provide unit test results for all the builds.
- RMS should archive the unit test results for important builds (QA builds and Production builds)
- RMS should provide the mechanism to deploy or install the applications in the target OS and do at least minimal amount of end to end testing . In our case we are using custom Perl scripts to test our software.
- RMS should archive end-to-end test results for important builds (QA builds and Production builds)
- End to End testing results should be updated in the RMS .
- RMS should provide an automated mechanism to promote a daily build to QA build and if the results are satisfactory then RMS should be able to promote the QA build to Production build.
- RMS should have defined criteria for promoting the builds like QA results or successful unit test results.
- RMS should have an automated mechanism to update the production server after a build is promoted to a production build.
- RMS should archive all the production builds.
- RMS should archive debug symbols for all the production builds.
- RMS web interface should have proper access security policies (Password or key Pair).
- RMS should maintain the history of all the important builds.
We have evaluated Hudson and Cruise control to fulfill the above mentioned requirements. Finally we chose Hudson. We felt cruise control is Java focused and little complex for our purpose. So far, we are happy with our decision to choose Hudson . It is light weight, extensible and supports distributed build feature, which we are using to build Tonido in 3 major OS’es (Windows, Mac and Linux). In case if you want to know more about Tonido, please check out Tonido’s website. We promise you won’t be disappointed.