background

At present, the front-end project deployment of the company’s test environment is manually operated by the testers. When the test environment version needs to be updated, the test colleague needs to manually perform the following procedure.

  1. Connecting to the packaging server
  2. Open the SVN management tool, find the target SVN version number, and pull the project
  3. After pulling the project, open the command line and download the dependencies.
  4. Wait for the dependency download to finish. Type the pack command
  5. Wait for the build to finish and compress the resource files into a zipped package and copy it to the desktop
  6. Linking the deployment Server
  7. Find the site folder that you want to deploy
  8. Paste it into the target folder and unzip it

Repetitive operations can be a huge waste of time when there are many projects. If a project is packaged by different teams at the same time, the packaging and deployment servers are queued up, and testers can only waste time waiting. In order to solve these problems, choose to find a suitable continuous integration solution. To automate repeated steps.

I tried a lightweight automated deployment solution (Walle, SPUG). However, the support for Windows and SVN is too low. In the end, Jenkins was the old steady hand.

We use Jenkins to automate the above problems. Pull the code, package the build, and send the resource to the target server. Let test colleagues no longer need to care about the packaging process, and from this tedious process, back to the test program should be focused on the work.

Download docker and Jenkins image

To build Jenkins with the help of docker, the artifact of environment construction, first install Docker

# installation docker
yum install docker
Copy the code
# start docker
systemctl start docker
Copy the code
# Set the image source to speed up the image download
vim etc/docker/daemon.json

{"registry-mirrors": ["http://hub-mirror.c.163.com"]}

Service restart
systemctl restart docker.service
Copy the code
# Install Docker Jenkins
docker pull jenkins/jenkins

# Create Jenkins data store folder
mkdir /usr/jenkins

# set permissions
chown -R 1000:1000 /usr/jenkins

Start Jenkins and map to port 9527
docker run -itd --name jenkins -p 50000:50000 -p 9527:8080   --privileged=true -v   /usr/jenkins:/var/jenkins jenkins/jenkins
Copy the code

Jenkins initialization

After successfully starting the container, access the Jenkins server IP address and port number to initialize Jenkins. The initialization administrator password can be obtained from logs.

Check the container ID
docker ps -a

View the container logDocker logs container IDCopy the code

Select recommended installation and wait until the installation is complete.

Install Jenkins plugins

After initialization. Log in Jenkins with the newly created account to enter the interface, several plug-ins need to be installed to support our business.

In System Administration – Plug-in Management, install the following three plug-ins.

  1. Subversion Plug-in (SVN support)
  2. Publish Over SSH
  3. NodeJS Plugin (front-end resource building)

The plug-in configuration

After the plug-in is installed, configure it.

SSH Plug-in Configuration

In System Administration – System Settings, locate Publish over SSH. Click the Add button to add the remote configuration that you want to publish.

For example, for remote machines that need to be published to the development environment, add the following information.

If the deployment machine runs Windows, you need to install SSH on the deployment machine and enable the SSH service to support SSH connection.

Windows installation SSH

Some machines may be configured with firewalls. Add outbound inbound rules for port 22 on the firewall. SSH connections are allowed.

Node.js plug-in configuration

In System Administration – Global Tools Configuration, locate NodeJS.

It is important to note that the node.js version should not be too high. Developing a stable version can avoid some strange problems caused by too high a version.

Once the plug-in is configured, you can create a new build task.

New Build Task

Task type choose free style software project.

Task information

Add parameterized build procedures to handle builds for different case processing. Two parameters, env, svnUrl, correspond to the build and release environment, and the VERSION of SVN to build.

Env is passed in as a variable when a front-end project is built. Use to dynamically modify the project environment type of the build.

SvnUrl is the SVN address that pulls the code each time the project is built.

SVN Warehouse Configuration

Because the code versioning tool is SVN, you need to select the Subversion option and fill the Repository URL with the variable $svnUrl. Represents the address parameter passed in when building.

At the same time, you need to provide an SVN account certificate to pull the SVN code.

Configure node.js to package front-end projects

Select Node.js to build.

In the build, you can install some source tools, such as YARN, CNPM, and NRM, from the command line to the Node.js environment. You can delete the command used to install the source tool and directly run the dependency installation command.

The command here is responsible for printing common information and executing build commands. After the build, compress the contents of the dist folder into a zip package: “dist.tar.gz”

Configure post-build operations

After the front-end resources are packaged, we need to send the files to the target server. Add the destination server to be sent here.

Click Add Server to Add the target Server to which the files will be sent after the build, specify the name of the file to be sent, dist. Tar.gz, and write the commands to be executed after the build.

The commands in Exec command are different in different operating systems. When the operating system is Unix, the Unix commands are executed. In Windows, the batch processing command is executed.

Bat in Exec Command decompresses the batch file reserved for the target server and sends the file to the deployment directory.

Save this task after the above configuration is complete.

Add batch files on the remote machine

If the target machine is Windows, the file will be sent to the user folder of the account that configured the remote link. After the transfer, the reserved superdeploy. bat file will be executed.

Superdeploy. bat takes two parameters, the current build environment, and the path to the file after the build.

The batch file copies the compressed package to the target folder and decompresses the package in the target folder.

To invoke the decompression function of 7Z on the CLI, install the 7Z decompression software on the deployment machine. It can also be replaced by other decompression software.

7Z official Chinese website

Start the first build

After completing the configuration, click Build with Parameters to start building. Before building, you need to fill in the Build Parameters.

In this case, the SVN pulls the code according to the SVN project address and runs the NPM run build:${environment parameters passed in} command to build the front-end resource. Corresponding to the front-end project package.json environment packaging commands.

{
    "scripts": {
        "build:dev": "vue-cli-service build --mode=dev"."build:test": "vue-cli-service build --mode=test"."build:prod": "vue-cli-service build --mode=prod"}}Copy the code

Vue-cli3.0 build commands and environment variable files are used here to provide packaging commands for each environment. The front-end project needs to configure a variety of packaging commands to support Jenkins’ dynamic environment construction.

Add multiple environment packaging commands to front-end projects

With everything in place, click to start building. Jenkins would pull the code according to the SVN address, execute the construction command, compress the dist folder into a compressed package after the construction, send it to the target server, and execute the batch file reserved in the target server. The batch file moves the compressed package to the execution target directory, where the compressed action is understood. An automated build and deployment process is complete.

The actual build time was 40 to 70 seconds, but much better for manual operation.

The pit of tread

  1. The name of the user directory for file transfer is different

On some computers, the login user is user, but the actual transfer to the destination folder is a folder like user.izjenFhextasd. Pay attention to the correct location of the script.

  1. CNPM installation depends on occasional timeouts

Need to modify the timeout configuration of CNPM source files installed in Jenkins image.

docker cp Jenkins: / var/jenkins_home/tools/Jenkins. Plugins. Nodejs. View NodeJSInstallation/Node_JS_12. 18.4 / lib/node_modules/CNPM/no de_modules/urllib/lib/urllib.js /usr/jenkins/# Modify the contents of the file

docker cp /usr/jenkins/urllib.js jenkins:/tmp/

docker exec-u root -it jenkins /bin/bash mv /tmp/urllib.js The/var/jenkins_home/tools/Jenkins. Plugins. Nodejs. View NodeJSInstallation/Node_JS_12. 18.4 / lib/node_modules/CNPM/node_modul es/urllib/lib/urllib.jsCopy the code

Alternatively, you can use another dependent download command, such as YARN.

  1. Deployment machine network or performance problems, occasionally unable to connect

Ensure that the deployment machine runs properly and does not use up memory or CPU resources.

  1. SSH Connection Failure

Check whether the openSSH service is enabled or whether the firewall disables access to port 22.

  1. Dependency update problem

The Jenkins dependencies will be installed (package-lock.json, yarn-lock) according to the locked version number of the files in the project for the first time. After the installation, the node_modules folder will remain. If you need to update a specific dependency version, manually change the version number in package.json and resubmit the build, or select the “Clear Workspace option” in the task.

I wrote at the end

In the absence of operation and maintenance of the company. At the beginning, I just explored continuous integration solutions with the mentality of trying, but after trying the lightweight deployment solutions such as Walle/SPUG failed, I decided to give up. But every time I want to give up, I remember a joke from my test colleague: “Automatic deployment has been talked about for three years, but it has not been done.” So I made up my mind to accomplish this goal.

I have always believed that if something is delayed, it should be waiting for someone to do it. I’m going to try to be this person.

So I began to collect information, consult documents and build from scratch. Windows and SVN always have a lot of strange problems, in the process of building frequently blocked. It’s hard to build, but you can’t install it. It’s one obstacle after another.

After failing 95 times in a row, the 96th time it all worked out. I was so excited that I almost jumped up in my seat.

In this way, the productivity of your testing colleagues is liberated. You don’t have to worry about packing anymore, everything is so simple.

Thanks to TL for their trust and support. When I proposed such an idea, they helped me get permission to borrow to each production server environment. It also made me realize that only by constantly jumping out of the box. Constantly challenge their unfamiliar content, their own ability to have greater improvement.

Hope this article helps you, have a nice day 🙂