Rollback mechanism of the online environment

"Scenario description" Have you ever experienced this situation in which you want to republish a project in a normal, online environment

"Normal operation is as follows":

1. Turn Tomcat off first;

2, delete the project files under Tomcat (on-demand backup), put the war package in Tomcat corresponding to the correct path decompression;

3, restart Tomcat, after restarting found that the deployment failure code has a problem then execute 4, or end.

4, deployment error, quickly close Tomcat, the last version/backup copy back, and then restart Tomcat, end ....

Does it feel too low? Here tomcat shutdown reboot for too long, and may have to back and forth copy decompression two times ~! Can not endure, to skillfully use tomcat+ soft connection, easy to solve two problems, forcing lattice high ~

"Solution Ideas"

1, the war package decompression to a specific directory decompression, such as/var/webapps/project name/timestamp;

2, close Tomcat;

3, delete the project files under Tomcat (no backup, because it is a soft connection), using a soft connection to copy 1 extracted files into the Tomcat directory;

4, restart Tomcat, after restarting found that the deployment failure code has a problem then execute 5, or end.

5, deployment error, close tomcat, remove soft connection, rebuild soft connection point to/var/webapps/project name/previous timestamp, restart Tomcat, end.

What do you think? Tomcat shutdown restart time basically look at hand speed, war package also just copy decompression once. Written as a script to run, better flavor.

This article is from the "Linux_home" blog, make sure to keep this source http://dmwing.blog.51cto.com/11607397/1885546

Rollback mechanism of the online environment