A one-click Deployment strategy for the Jenkins test environment to the production environment (Windows)

A one-click Deployment strategy for the Jenkins test environment to the production environment (Windows) I. Preface

We have initially implemented a continuous integration of the development integration environment, the test environment (automated build, automated testing, automated deployment). However, the automation of production environment has been slow to advance. The reasons are mainly in the following aspects:

• Automated backup before deployment is not implemented
• Automated rollback after a problem with deployment has not been implemented
• Because prior to the deployment of FTP upload requires a production environment open FTP port security issues and FTP due to a variety of speed problems, causing the site to hang up instantly

As long as we solve the above three problems, we can initially realize the automated deployment of the production environment.

Second, the realization of ideas

1. Using the Jenkins distributed feature, where the Jenkins server acts as the master server, the production environment (which can be one or more servers) as a slave server in the Jenkins cluster.
2. The test environment should maintain the release status of the configuration and compilation versions of the simulation and production environments, and the functionality has met the expected release requirements.
3. Copy the deployment files on the test environment to the Jenkins workspace on the production environment through the file replication plug-in.
4. Batch processing of files that you do not need to overwrite, or configurations that you want to modify temporarily.
5. Using RAR Backup to generate the files that will be overwritten on the environment, note that the naming follows a certain rule: Project-folder-{buildid}.bak.rar or date-project-folder-{buildid}.bak.rar.
6. Use batch processing to copy files from the Jenkins workspace to the site, common commands: xcopy.
7. If there is a problem with the production environment, the project manager and the OPS decide whether to fix the bug urgently or enable rollback, and the rollback uses a batch command to compress the backed up files back into the directory under the production environment site.

Through the above strategy can realize the test environment to the production environment of one-click deployment, the implementation of pre-deployment of automated backup, the problem of automated rollback, the use of Jenkins Master-slave features to solve the need to open the FTP port, and will be tested at the test site of the good files, Copy to a buffer on the official site, for warm-up configuration, after the local file replacement, the speed is quite fast, to solve the FTP upload process caused by the network problem site hangs.

Defects and Problems:

1. The production environment needs to be a server in the Jenkins cluster and assume a part of the build task, but it is negligible to configure this issue
2. Production environments need to install JDK and open a Java service
3. Pending discovery

Three, production environment topology diagram

Four, the required Jenkins plug-in

1. Copy data to workspace plugin plugin
2. Copy Artifact Plugin
3. Node and Label parameter plugin plugin

V. Steps of implementation

1. Build slave

1.1 Jenkins System Management--manage nodes--new node
!

1.2 Enter the node name, next, configured as

Among them, there are several points to note:

• "# of Executors" based on the number of CPUs to fill in the quantity

• "Remote working directory" This is used to store the master to slave, the temporary directory, such as slave's service software will be placed here, and will be in each job name to distinguish between

• "Usage" only needs to select "Allow only jobs bound to this machine" in this mode, Jenkins will only build the job assigned to this machine. This allows a node to be reserved specifically for some type of job. For example, in a continuous test run on Jenkins, you can set the number of performers to 1, then there will only be one build at a time, one executor will not block other builds, and the other builds will run on another node. With this configuration the production environment can only do its own building.

• "Startup mode" only needs to select "Launch agent via Java Web start" To start the service, the most widely used and best configuration, the rest are too complex, not recommended. Note: The default version of 2.x does not have this option and needs to be turned on separately. The rest of the basic is selected by default above.

Launch Agent via Java Web start open mode:

jenkins--> System Management-->configure Global security-->agents--> modified to random selection

1.3 Click Save, the node is already configured on Master, then the next step is to install the slave service on the server to the node:
Click on the node server in the list on the right and the node is not connected.

Go to the Details page and you will be prompted how to install the service:

Note: Because the slave service is a Java service, the JDK needs to be installed on the slave server

When the following service appears on the slave server, it represents the installation and the connection is successful

When you return to the Jenkins server, the view status is connected.

Description: Here only to introduce a strategy based on existing requirements, about the Jenkins Master-slave Connection mechanism and principles do not introduce, online about this aspect of the introduction is also a lot, we can search by themselves.

1. Create a production Environment Automation deployment task
   2.1 Parameterized Configuration selection Slave build
   Jenkins creates a free-style software project
   
   Parametric build-Add Parameters--Select node
   
   If you do not have this parameter, install the node and Label parameter plugin plugin
   Parameterized configuration can be done on-demand or self-configuring as needed
   

2.2 Text Copy
Text copy can choose two plugins

Copy data to workspace plugin plugin

You can copy the files of the Jenkins master server into the slave workspace
Cons: Parameterization not supported
Copy Artifact Plugin Plugin

Enables replication between Jenkins Slave-slave Master-slave to copy a job-built build to the current workspace
Cons: Intra-job configuration that needs to be replicated archive the artifact

can choose the plugin according to the need, here in order to be able to parameterize we choose Copy Artifact plugin plugin

Configuration Description:

• Project name: The names of the projects to copy, which you can use to parameterize
• Which build: Select the product after the build, you can generally choose latest successful build
• Stable Build only: Choose a stable build
• Artifacts to copy: The file to copy can be matched to a rule, such as test/**/*, all files under the test folder
• Artifacts not to copy: Exclude certain files according to rules
• Target directory: Within that folder of the local workspace
• Parameter filters: It's useless here, if you use it, you can read it yourself.

Note: The pre-job configuration is required here

Add post-build actions within the job you want to replicate such as:

2.3 Automated Backup
Fill in the backup batch, here you can use the Windowsrar compression command, so if you want to use RAR, make sure the machine is installed Windowsrar. Note that names must have rules and each build cannot be duplicated, so you can use the project name +buildid or date + project name +buildid

//自动备份批处理命令start c:\"Program Files"\winrar\rar.exe a -k -r -s -m1-ag{HS.Shop.My-%BUILD_ID%.bak}  {要备份到的文件夹} {要备份的文件夹}

2.4 Overwrite files under the site Directory
After the backup is complete, copy the files under the Jenkins workspace to the site directory, and you must ensure that the release package has excluded files that you do not need to overwrite and is a stable and usable version. The batch command can take the xcopy command. About the use of xcopy command can be self-Baidu

xcopy  {slave工作空间上的项目文件夹} {要复制到替换的文件夹}  /Y/E

This step completes the task configuration for automating the deployment of the production environment. Click Build to complete a one-click deployment of the test environment to the production environment. You can use Emergency repair or automated rollback if there is a problem with the program.

1. Create a production environment automation rollback task

3.1 also create a free-style software project
Two build parameters can be configured here

1. Rollback which project was built

2. Rollback of which server is built (can be more than one)

Parameterized configuration visible

3.2 Automated rollback batch processing

Setlocal enabledelayedexpansionset "projectKey=ChioceBuild"set "bakUrl=D:\HS.Shop.Bak\HS.Shop.My\"  //备份文件的路径set url="%ChioceBuild%"                  //参数set "rollbackUrl=D:\"set "projectName="set "buildID="set url=%url::=/%set url=%url:///=/%set url=%url://=/%for /f "tokens=1,2,3,4,5,6,7,8* delims=/" %%a in (%url%) do ( set "projectName=%%g" set "buildID=%%h")set projectName=!projectName:%projectKey%=!set "fileName="for %%a in (%bakUrl%%projectName%-%buildID%.bak.rar) do ( set "fileName=%%a")c:\"Program Files"\winrar\rar.exe x -ep2 -o+- %fileName% %rollbackUrl%

Click Save to complete the setup of automated rollback tasks, and click Build selection parameters to roll back.

Vi. concluding remarks

Jenkins is a continuous integration tool that is very powerful and can help us do automated builds, automated testing, automatic publishing, and so on, and it implements a wide variety of functions according to different needs, and it can minimize repetitive work in our daily routine. These are just a few of the strategies that I use to study the current situation, there may be loopholes, there may be problems, but if you are not willing to try to improve the existing process to accept new things, then we will never progress. And my understanding of its use is only bucket, we can study according to the needs of the development of their own use strategy.

Finally, I hope everyone: even move the bricks, but also to move out of the artistic sense! Do a pursuit of the brick!

A one-click Deployment strategy for the Jenkins test environment to the production environment (Windows)