Continuous Delivery Scenario - implementing Rollback

Question

Imagine I have a vanilla continuous delivery scenario with a Java webapp.

This scenario has: - one build server running cruisecontrol - one web server running Tomcat with tomcat manager running

One of the Ant build targets running on the build server builds a war file and then uses catalina-ant to remotely deploy the web server using the Tomcat manager.

To be truly useful - we need to be able to roll back the deployment. Given this vanilla setup, what extra pieces of the puzzle do I need to be able to roll back to the last known good configuration?

Answer 1

The primary tools seem to be AntHill Pro and UDeploy (both from UrbanCode - now part of IBM). It seems Anthill OS has been retired.

It looks like Go CD Sever can also be used for this as well.

Answer 2

1. Go for build-once-deploy-many-times approach

2. Maintain your binaries (war files) in some repository (say last 10 builds)

3. Keep track of what version is currently deployed

4. To rollback new version, simply re-deploy older version form #2 based on #3

Answer 3

you can try a bit different approach, steps are:
1. lets assume you have folder called /opt/wars
2. in this folder you have subfoders with versions, e.g.

/opt/wars
        |-my-server-0.0.1/
        |--my-server.war
        |-my-server-0.0.2/
        |--my-server.war
        |-my-server-0.0.3/
        |--my-server.war
        |-current --> my-server-0.0.3

3. before deployment you create always new folder with new version, e.g. version 0.0.4

/opt/wars
        |-my-server-0.0.1/
        |--my-server.war
        |-my-server-0.0.2/
        |--my-server.war
        |-my-server-0.0.3/
        |--my-server.war
        |-my-server-0.0.4/
        |--my-server.war
        |-current --> my-server-0.0.3

4. once use see that version is ready, you will need to change link of "current" to my-server-0.0.4 folder
5. in case of rollback you can switch to previous copy, just by changing link.

Answer 4

Consider CloudMunch to solve this. CloudMunch stores the complete history of your builds and the artifacts linked to them and allows you to perform a tag based search to get to the right build (beyond the obvious last best one to build with a given defect fixed etc.)

Once you pick the build, in the absence of any SQL server the rollback would be much simpler. If you have a database, refer my answer in this to manage the SQL changes incrementally - How to continuously delivery SQL-based app?

Disclaimer: I work at CloudMunch.