Need advice or pointers on Release Management Strategies

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 ea开发者_StackOverflow中文版ch 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.

It seems to me that rolling back the changes that are pushed into the Release branch seems to me a normal practice in your case, which I think might not be appropriate.

One thing that I find bit surprising is that why would users test changes and then either reject or approve the release ? IMHO testing of the changes and making sure that it fixes the issues raised by the users should be the task of a test team. The users are not testers. If there is a test team you can have a Testing (say) branch where the fixes/changes are pushed to, and the test team uses that branch for testing and qualifying the changes. Once the changes are qualified by the test team you can push the changes to the Release Branch (say) and do deployment from there. Even with this approach there will be chances that users will find issues with the changes made, but with the test team doing the internal testing the need for rollback would become an exception rather than the norm.

I am thinking about feature branching, not something I would attempt using Subversion.

Basically you create a branch for each issue. This branch you can build, deploy and have tested by users or testers. If the fix is not accepted you can continue improving the fix on the branch.

If the fix does get accepted you would still need to integrate it with any other fixes or pending changes before you can really release it any shape or form. You can go two routes here, you can integrate the fix on the version that is currently in production to create a 'maintenance release' or you can just merge the 'fix branch' with the mainline/trunk for it to get released together with whatever next release of the trunk. When working with a maintenance releases you need to be extra cautious and remember to merge the changes to the trunk at some point after acceptance or having gotten OK from testers. If not you may suffer from re-occurring bugs when the trunk gets released later on.

All forms of integration may warrant further testing; the fix might have been OK in isolation but perhaps doesn't perform too well when integrated with all the newest changes to the system. If the integration involved merges and such there may have been errors there also. With this in mind, I would stick to negotiating releases. Testers should test releases, not individual fixes in isolation.

Finding and fixing an issue doesn't always mean it has to be deployed instantly. Sometimes you can negotiate with your customer; "Is it OK if we release this bug-fix together with our next regular release?".

The whole bookkeeping and administration of chances, hot-fixes and out of band releases gets overly complex very quickly, I'd avoid it as much as possible. If you have 4 fixes and 1 is not OK yet and the other 3 can wait... go for that route.

We decided to go with a multi stream approach. Basically each developer works on a new branch for each change and when ready the change is merged into the Dev stream, this is watched by TeamCity and the application built and released to the Dev server for Integration testing.

If this passes than the changes are merged from the original branch to the UAT stream. Again this is released by TC to the UAT server.

Once signed off the change is again merged from the original branch into the Live stream and TC releases this to the live server.

It should be noted that the relevant stream has to be merged into the branch before each release to allow testing by the developer.

This is a bit of a drawn out process but as we are far to small for a testing department and until I can convince the business to consider sprints or some other periodic/packaged release process we will have to live with it.

Many thanks for all comments and suggestions above.