Need advice or pointers on Release Management Strategies
- by Murray
I look after an internal web based (Java, JSP, Mediasurface, etc.) system that is in constant use (24/5).
Users raise tickets for enhancements, bug fixes and other business changes. These issues are signed off individually and assigned to one of three or four developers.
Once the issue is complete it is built and the code only committed to SVN. The changed files (templates, html, classes, jsp) are then copied to a dev server and committed to a different repository from where they are checked out to the UAT server for testing. (this often requires the Tomcat service to be restarted and occasionally the Mediasurface service as well).
The users then test and either reject or approve the release. If approved the edited files are checked out to the Live server and the same process as with UAT undertaken.
If rejected the developer makes the relevant changes and starts the release process again.
This is all done manually without much control. Where different developers are working on similar files, changes sometimes get overwritten by builds done on out of sync code in other cases changes in UAT are moved to live in error as they are mixed up in files associated with a signed off release.
I would like to move this to a more controlled and automated process where all source code and output files are held in SVN and releases to Dev, UAT and Live managed by a CI system (We have TeamCity in house for our .NET applications).
My question is on how to manage the releases of multiple changes where some will be signed off and moved on and others rejected and returned to the developer. The changes may be on overlapping files and simply merging each release in to a Release Branch means that the rejected changes would have to be backed out of the branch.
Is there a way to manage this using SVN and CI or will I simply have to live with the current system.
