Zero-Downtime Deployment for Spring Batch Using Symbolic Links

The 11st Claim Development Team experienced a problem where NoClassDefFoundError and ClassNotFoundException occurred as the jar file changed during deployment, on a batch server that runs Spring Batch Jobs periodically via Jenkins.

The core of the problem was that when deployment proceeded while a Job was running, the jar file that was being executed would get updated or deleted. To solve this without changing the deployment structure, a symbolic link approach was applied to stabilize the behavior.

The approach was applied as follows.

• In the post-deployment step, the jar file at the Deploy Path is copied to a new directory in the form batch-YYYYMMDDHHMMSS.
• After removing the existing link, the link is re-created to the jar in the new directory using ln -Tfs.
• In the Job execution step, readlink is used to obtain the actual jar path that the symbolic link points to, and that is what gets executed.

To prevent files from continuously piling up after deployment, a remove-old-directories.sh script is also included, which keeps only the most recent 10 directories and deletes older ones. This way, the jar referenced by a running Job stays intact, and since deployment is separated into a new directory, deployment and execution no longer interfere with each other.

As a result, while keeping Jenkins' Execute Shell unchanged, they were able to build a zero-downtime deployment structure in which a running batch job is not broken by deployment.