Objective
Jenkins is an open source continuous integration tool, which can be easily built, automatically compiled and deployed by using Jenkins to build a continuous integrated environment.
In the case of fewer servers, the advantages of Jenkins are not obvious, but with the development of the project, the number of servers increased, Jenkins advantage will be highlighted, can be very good to improve efficiency, reduce a lot of manual operation.
Now the company's development is to use Git management code, MAVEN management of multiple modules and project dependencies, therefore, the implementation of automated packaging, building imminent. Install Jenkins installation package
Official Download Address: https://jenkins.io/download/
Click to download and install according to the platform
Tips: There are Jenkins sources on the Web, add the following
Wget-q-o-https://pkg.jenkins.io/debian/jenkins-ci.org.key | sudo apt-key add-
sudo sh-c ' echo deb http://pkg.jenkins.io/debian-stable binary/>/etc/apt/sources.list.d/jenk Ins.list '
sudo apt-get update
sudo apt-get install Jenkins
Jenkins.war
Directly in the Tomcat container can be more convenient (recommended, the reasons are: simple, follow Tomcat launch release, reduce unnecessary expenses, pit less, I have both installed, directly installed a lot of pits) deployment Jenkins
Follow the prompts to enter the ciphertext, the interface is as follows:
Then you will fill out the user information, install the basic plug-ins, prompts to do good.
Click on the System-managed global tool configuration, as follows: JDK git maven configuration
Git project build (three images)
Jenkins deployed to Tomcat
Method One: Plug-in
1.
2. Plug-in configuration (configure users)
3. Tomcat Configuration
Find Tomcat-->config-->tomcat-users.xml
open to increase the following user information between <tomcat-users></tomcat-users>:
<role rolename= "Manager-gui" ></role>
<role rolename= "Manager-script" ></role>
<user username= "Tomcat" password= "admin" roles= "Manager-gui,manager-script"/>
Method Two: script (self modification I did not test)
#!/bin/sh
#defined
tomcat_home= "/usr/java/tomcat/apache-tomcat-7.0.67/"
id= ' ps-ef | grep java | grep Tomcat|awk ' {print $} '
echo $ID
echo "Kill Tomcat"
kill-9 $ID
echo "Remover War file
CD" $TOMC At_home "/webapps
rm-rf javaweb-0.0.1-snapshot
rm-rf javaweb-0.0.1-snapshot.war
echo" copy War to WebApp "
Cd/home/lin
cp javaweb-0.0.1-snapshot.war" $TOMCAT _home/webapps
cd "$TOMCAT _home"/bin
echo "Start Tomcat"
./startup.sh
Timed tasks
Build after the other projects are built: triggered when other projects are triggered, there are three kinds of situations, which are other project construction success, failure, or instability when the trigger project;
Poll SCM: Periodically check the source changes (according to the version number of the SCM software), if there is an update checkout the latest code down, and then perform the build action.
H/5 * * * * * (check source change every 5 minutes)
Build periodically: The cycle of project construction (it does not care whether the source is changed), as shown in the following figure configuration:
H 2 * * * * (every 2:00 must build one time source)
Fill in the Schedule 0 * * * *.
The first parameter represents the minute minute, the value 0~59;
The second parameter represents the hour hour, the value 0~23;
The third parameter represents day, value 1~31;
The fourth parameter represents the month month, and takes the value 1~12;
The last parameter represents the week week, 0~7,0 and 7 are meant for Sunday.
So 0 * * * * represents the first 0 minutes of each hour to perform the build. Build Examples:
Because the code for the project typically exists in SVN, an SVN often has multiple project teams submitting code, and each team has more than one person, and each of them is constantly maintaining their own piece of code, so for a company, SVN's submissions are often frequent, and because of that, Jenkins is often executed in days when performing an automated build, and the following example is the regular build example that is commonly used during the day.
Build once every 5 minutes
H/5 * * * * * *
Build once every two hours
H H/2 * * *
Build once a day before work at noon
0 12 * * *
Build once every afternoon before work
0 18 * * *
Project rollback
Although the automatic deployment of the project is achieved, sometimes when the deployment fails we need to roll back to the build of the specified version, so that the project can be more flexible to build deployment. We can choose the parameterized build process to pass different parameters to choose whether to make a new build or roll back
Steps:
1. Post-Build archive
After construction, the completed files are archived for easy rollback later use
2. Parameters and build process
Use the parameterized build process so that the following steps can perform different operations depending on the variable. Add the "Choice" parameter to configure different options for publishing or rolling back, adding a String Parameter parameter to pass the version number to be rolled back.
3. Execult build (no maven)
Build a script that chooses "Execute Shell" to customize the build based on the variables, at this point if the build process for the release of Maven is a new build, and if it is rolled back, know the history-built file and copy it to the current build results directory.
4. Click Build, choose whether to publish or rollback according to different parameters, and fill in the history version number that you want to roll back to when rolling back
Distributed Deployment (temporarily not written, not) Classic error
1. Error: Solve git Problem: "Tell me who you are" fix: Enter git Username and Email, add user plus password on git plugin
2. Error: Maven Error:cannot Run Program "MVN" Analysis: Cannot find the command, that is Jenkins users do not have the right to use, I resolved the way relatively low resolution: MAVEN global configuration using the auto-turn of MAVEN is not customized OK
Monkey Hurry I can solve these things by a script. The answer is still in the actual application of ING, Jenkins is usually applied in the distributed system, at the same time deploying multiple servers, usually access to Jenkins on the machine download the war package to deploy the bottom of the buildsetting can set the Mail recipient list, At the end of each build, you can send related information to the mailbox. I personally prefer parametric build, do not recommend the use of Maven Plug-ins, for reference only. The fool type operation, basically is in configures that page.
https://oliverveits.wordpress.com/2017/02/27/ An article by jenkins-part-5-1-using-the-job-dsl-for-automatic-creation-of-jenkins-jobs/
http://blog.csdn.net/gld824125233/article/details/52549449
http://blog.csdn.net/e295166319/article/details/52920036
Http://www.jianshu.com/p/dceaa1c7bb49