Jenkins Spring Boot Automatic deployment scenario

Original address: http://www.cnblogs.com/skyblog/p/5632869.html

Most of the current automated deployment scenarios are based on Docker, but traditional automated deployment scenarios are more suitable for small and midsize companies, and the following scenario is a more traditional automated deployment scenario.

1. Why automatic deployment is required

With a microservices-based architecture, automatic deployment is important. Because each service needs to be deployed. If it is a manual deployment, then there are M services, then you need to deploy at least m, if each of the same service deploys n instances, then you need to deploy m*n times. So automatic deployment is almost necessary for microservices architectures, which differs from traditional applications.

2. How to implement automatic deployment

Automatic deployment is typically done in the following steps. It is preferred that the continuous integration tool be automatically compiled to produce the output of the project, which is the jar package for us. The jar is then tested for distribution to each server, and the monitoring script for each server monitors the new version and automatically stops the old instance from re-running the new instance.

The above is just a general step, and the actual implementation requires more detailed steps, as follows:

The results of the Jenkins compilation need to be stored temporarily for testing by the tester pull. This is stored in the MAVEN library. The tests also need to be manually pushed to the production environment, because it is not possible to push each version into production. The production environment requires an FTP or GIT, SVN server as a transit, staging the packaged app, and then the production server polls the connection through the script to get a new version. After getting the new version, automatically stop the old version and run the new version.

Jenkins Spring Boot Automatic deployment scenario