Using WmDeployer, if I make a Patch release Will it be possible to rollback the release?
For example in my first Patch release I have added a service S1, S2 to the Package and in my second release I have added a service S3 to the same package. But After my deployment I like to rollback the second patch release i.e.to remove the service S3 from the Package. If I use my build1 which is used for the first release and make a deployment to the target server, Will the second patch release will rollback?
I really suspect whether the rollback of patch release will work in WmDeployer?
It will be great if any of u suggest any procedure for this.
Hi Ravi,
I do not think that such a rollback facility for patches is provided in any software. You would have been able to “rollback” provided the list changed components remains the same without any additions or deletions.
It would be interesting to see if it is otherwise!!
Hi Ravi,
I would agree with Harsha,
Lets assume Build1 contains - Service1 + Service2
and Build2 contains - Service1 + Service2 + Service3
As and when you deploy Build2, all the 3 services are available. But if you want to “rollback” build2, the only option is to re-deploy Build1. That will take it to the state before deployment of Build2.
I believe your situation will be able to be rolled back if you merely re-deploy an old build that’s not a patch… So if you have a full build, roll back to that then re-deploy any of the patch releases you’ve done since.
I honestly haven’t mucked around with trying to create patches with WmDeployer, I’ve never had the need.
If you’re talking a DEV/UAT/PROD setup with DEV to UAT deployer running on DEV and UAT to PROD wmdeployer running on UAT you can do your versions that way without having to “patch”.
As a side note:I always try to avoid doing patches when at all possible (I know it’s not always possible), as any type of patching is generally a nightmare to organise.
If you’re having to do it more than once a blue moon: consider splitting up your deployment projects and/or your packages.
e.g. you could have one massive project that deploys everything under the sun and then you patch whatever new functionality you have, but a better idea is work out what’s logically related and use that as a guide for projects in WmDeployer.