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.

  1. 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.
  2. 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.
  3. 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.
  4. Every build should have a build number. In our case, we are using the subversion revision number.
  5. Every build should have a build version. Build version format is Major Version: Minor Version: Patch: Build Number
  6. RMS should provide unit test results for all the builds.
  7. RMS should archive the unit test results for important builds (QA builds and Production builds)
  8. 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.
  9. RMS should archive end-to-end test results for important builds (QA builds and Production builds)
  10. End to End testing results should be updated in the RMS .
  11. 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.
  12. RMS should have defined criteria for promoting the builds like QA results or successful unit test results.
  13. RMS should have an automated mechanism to update the production server after a build is promoted to a production build.
  14. RMS should archive all the production builds.
  15. RMS should archive debug symbols for all the production builds.
  16. RMS web interface should have proper access security policies (Password or key Pair).
  17. 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.

2 Responses

  1. You may also look at our Parabuild. It satisfies *all* requirements for RMS that you have outlined.

  2. steve says:

    Finding a robust patch management solution is becoming more and more difficult as machines are less and less accessible to the management console. I have found success using patch management software from Kaseya. Because of the agent based framework, I have connectivity to every machine that is connected to the Internet, independent of location. – URL: http://www.kaseya.com/products/patch-management/features.aspx

Leave a Reply