Build Jenkins for automated deployment

Jenkins is a very well-known CI tool, open source, free, through Jenkins we can more intelligent, rapid continuous integration, early detection of problems in the code and timely deployment up. Install Jenkins on Ubuntu

Wget-q-o-https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add-
sudo sh-c ' echo deb Http://pkg.jenkins-ci.org/debian binary/>/etc/apt/sources.list.d/jenkins . List ' sudo apt-get update
sudo apt-get install Jenkins

Open http://localhost:8080 If you see the home page of Jenkins you have successfully installed it. Change Port

If port 8080 is already occupied, modify the configuration file to change the port.

sudo vi/etc/default/jenkins

Find http_port=8080, change 8080 to 8000, then

sudo service Jenkins restart

Configure access Rights

It's definitely not safe for Jenkins to have all the permissions by default without having to sign in. Here is a simple configuration, let the user log in before you can operate.

Screenshot of the final result after configuration:

Click on "System Management" in the left sidebar of Jenkins, then "Configure Global Security", tick "enable secure". Select "Jenkins Proprietary user Database" in the security domain and tick "allow user to register". After saving, go to the homepage to register an account, for example, we register a user named Jenkins here. Then go back to the configuration page, select "Project Matrix Authorization Policy" in "Authorization Management", add the Jenkins user to the user group, and tick "Administrator" on the Jenkins line, and cancel all authorization of "anonymous user". Finally, cancel the Allow user to register and click Save. In this way, you can only use the Jenkins account login to do the follow-up operation. New Task

In the left column select New, fill in the name, choose to build a free-style software project, click Save, go to the configuration page. This page covers all the configurations for this task, which are somewhat complex and are explained below.

Source Management

Choose Git, Repository the URL with GitHub's address, add Credentials, and fill in the GitHub username and password. This is the certificate that Jenkins needs to draw the source code. "Branches to Build" fills in the branch name, indicating that Jenkins pulls the source of the branch, and the trigger is only for that branch.

Building triggers

Indicates under what circumstances the project is built, if you choose Poll SCM, and then fill in the cron expression in the schedule, for example, "H/5 * * *", it means checking every 5 minutes and building the project with code changes. Here we do not choose poll SCM, but with gitub plug-in to do real-time construction. GitHub Plugin

"System Management", "plug-in Management", "Optional plug-ins", search "Github plugin", Hook, direct installation. Go to the Plugin installation page, and after the installation is successful, go to the project configuration page again. In this case, "build triggers" should have one more "build when a-change was pushed to GitHub", select. Next go to GitHub to configure the hooks.

Log on to GitHub and fill in http://jenkins_url/github-webhook/in the Add Hook, Webhooks & Services, settings, the project, remembering content type Be sure to choose "application/x-www-form-urlencoded", otherwise there is no way to work properly, secret do not fill.

Build

In the build configuration, select Add Build step and select Execute shell to fill in the build command you want to execute. For Java projects, this is typically an ant or Maven command. For our project, the main execution is the shell command.

Add the following build command in turn:

NPM Installgrunt Deploy
cd public/assets/javascript
gruntbin/migrate_database.sh
node_env=test bin/ migrate_database.sh

The above is in order to install the dependency package, compile coffee, update the database and the Model field. Plus the final step-test:

Node_env=test Mocha--compilers coffee:coffee-script/register test/spec/**/*.coffee-r doc > test_result.html

These commands can be placed in one or open, but the order must be maintained. Especially the last step. If the test passes, the build results are successful; instead, the build is flagged as failed. This determines the post-build operation to be said later.

After completing the above steps, the task is automatically built, but in order for the script to run, the final step is to configure the development environment for the Jenkins user.

When Apt-get install Jenkins, the system has more than one Jenkins user, whose home directory is running as the user's identity in/var/lib/jenkins,jenkins. So in this environment, the user you are currently logged on with, such as NPM grunt, cannot be used normally in Jenkins. You must first configure the environment for Su Jenkins, before which you may want to sudo passwd Jenkins to set a password for Jenkins and add the Jenkins user to the sudo list to install NPM.

Once you've done the above configuration, you can click Build now to test the build process correctly. Then push it to GitHub to see if it will trigger Jenkins to build. Make sure that none of the above issues are followed by the configuration. Post-build actions

Post-build operations are divided into two scenarios:

After the successful construction, the program is deployed;

After the build fails, send a notification message.

However, whether you deploy a program or send a message, the option is not found in the Add post build action. So you also need to install some additional plugins.

Install the following two plugins as described above in installing the plugin:

Post Build Task

Postbuildscript

Both plug-ins are used to execute shell scripts, unlike the post build task plug-in, which can perform different actions depending on the build output, and when the current polygon build fails, the Send mail operation can be performed by matching the failed output.

Post-build operations, add post Build Action step-after-construction-build task, fill in the log text with marked build as failure, which is a piece of text that the log outputs when the build script executes unsuccessfully. and fill in the script.

Coffee ~/mailer/mailer.coffee-f Graphite Notice-t chenxu@1heart.cn,a@1heart.cn-s "Jenkins Build Fail $BUILD _display_name"-C $BUIL D_url-a test_result.html

This section is the script to send email,-a test_result.html is to let the message with the test results as an attachment. Mailer.coffee is the script that I wrote with Nodejs. The specific parameters are as follows:

Coffee ~/mailer/mailer.coffee-h

Usage:mailer.coffee [options]

options:

-H,--help output Usage  Information-v,--version output the version number-f,--from [value] Sender name-A,--attachment <file> Attachment path-T,--to [value] recipient e-mail address, if more than one, separates-S,--subject [value] message subject-C,--content [value] message content

Mailer.coffee is temporarily placed in a GitHub private warehouse because it involves email account passwords. Automatic deployment after successful build

Add the Post Build Action step, execute a set of scripts, fill in the command with the deployment script, and tick the Execute script only if build success. This enables the build to be successfully deployed automatically. Here is the deployment script:

# back up the files uploaded by the user if [-D "/var/lib/jenkins/shimo/public/uploads"]; Then
cp-r/var/lib/jenkins/shimo/public/uploads//var/lib/jenkins/backups/fi# Delete the program that was originally deployed in PM2 rm-rf/var/lib/ jenkins/shimo/# Copy the built version of the Jenkins workspace Cp-r/var/lib/jenkins/jobs/shimo/workspace//var/lib/jenkins/shimo/# Restore an uploaded file Cp-r/var/lib/jenkins/backups//var/lib/jenkins/shimo/public/uploads/# establish a soft link rm/var/lib/jenkins/shimo/node_ Modules/shimo
ln-s/var/lib/jenkins/shimo//var/lib/jenkins/shimo/node_modules/shimo# deployment to PM2PM2 StartOrRestart Processes.json

/var/lib/jenkins/jobs/shimo/workspace/is the location where Jenkins is automatically built, which is the project root, but it is not possible to deploy this location directly to PM2. The reason is that if the build fails, even if you do not restart the PM2, the front-end HTML, JS have been updated and effective. To prevent this, copy the project to another path after each build succeeds and deploy it under that path.

When the above configuration is completed, the CI/CD of the project is realized. Jenkins is very flexible, and the above steps need to be adapted to your situation.