Jenkins (2)

Official Website: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

My article is just a simple example of what features Jenkins provides. For details, you still need to learn it by yourself ~

The official website provides the Jenkins installation package for Windows versions. We can download one for learning. After the installation, open http: // localhost: 8080 and you will be able to see the Jenkins interface.

Other things also need to be installed:

1. Jenkins is a Java program, so JDK must be installed.

2. At the same time, the job must provide repository, that is, the place where Jenkins regularly poll source code is stored. We can go to GitHub to add one for free.

3. If you want to use ant or Maven in Jenkins, you must install it separately. But not required.

Start Jenkins

Jenkins naturally supports Unix-like system.

• Direct execution
  

Okay, Jenkins is a Java program, so to execute it, you only need:

$ Java-jar Jenkins. War

We can also use the nohup command to run Jenkins in the background.

Then open the URL http: // myserver: 8080 to facilitate Jenkins operations.

The official website provides an example of sh to start Jenkins. You can take an exam.

• Run the following command in servlet container:

Alternatively, if you have a servlet container that supports servlet 2.4/jsp 2.0, such as glassfish V2, Tomcat 5 (or any later versions), then you can run them as services, and deployJenkins. WarAs you woshould any other war file.

For example,
You cocould simply place the Jenkins. War file in Tomcat's webapps directory. By default, the URL used becomes:

Http: // localhost: 8080/Jenkins

At the same time, Jenkins provides some special functions that will not be started by default. The following links are used to enable them.

Https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties

Jenkins folder structure

Like cruisecontroler, Jenkins needs a folder to store related files: jenkins_home. Mo thinks~ /. Jenkins. This is a hidden folder in the home folder of the user. We can also change jenkins_home to point to what we want.

(Note that you need to use LS-Al to view the hidden folder)

Jenkins_home
+-Config. XML (Jenkins root configuration)
+-*. XML (other site-wide configuration files)
+-Usercontent (files in this directory will be served under your http: // server/usercontent /)
+-Fingerprints (stores fingerprint records)
+-Plugins (stores plugins)
+-Jobs
+-[Jobname] (sub directory for each job)
+-Config. XML (job configuration file)
+-Workspace (working directory for the version control system)
+-Latest (symbolic link to the last successful build)
+-Builds
+-[Build_id] (for each build)
+-Build. XML (build result summary)
+-Log (Log File)
+-Changelog. XML (change log)

If you have permission management, the users folder is displayed in the home folder.

The folder structure is similar to that of cruisecontroller. Config. XML is an important configuration file of Jenkins. We all know that Jenkins is used to monitor multiple builds, and the jobs folder is undoubtedly the place where information about each build is stored.

In general, the Jenkins folder structure is straightforward and concise.

Backup and recovery

Backup and recovery are easy, just copy the Jenkins Folder:

All the settings, build logs, artifact archives are stored under the jenkins_home directory. simply archive this directory to make a back up. similarly, restoring the data is just replacing the contents of the jenkins_home directory from a back up.

Move/copy/rename a job

Because Every job has its own folder, we can easily:

1. Move a job from one installation of Jenkins to another by simply copying the corresponding job directory.
, 2, make a copy of an existing job by making a clone of a job directory by a different name.
3, rename an existing job by renaming a directory.

Run the following command to refresh the changes:

Http: // [Jenkins-server]/[command]

Here, [command] can be: exit, restart, and reload.

Create a project

Because Jenkins can be used to execute various CI, Token test, batch processing tasks, and so on, these tasks are collectively referred to as "free-style Software Project" in Jenkins ".

Jenkins also provides other types of jobs, such:

1. Assume that the project is Maven, and Jenkins also provides a job for Maven project only. But in fact, free-style software projec can still be used to create Maven projects, but this is more suitable for Maven projects and better combination.

2. You can also create a "monitor an external job" to monitor external processes.

3, or a matrix project, that is, the multi-configuration project.

I'm not sure whether there are only these four types of jobs. Maybe I can use a plug-in to create many other types of jobs. Let's read the information.

The following describes how to create the most common "free-style software project:

Go to Jenkins top page, select "new job", then choose "build a free-style Software Project". This job type consists of the following elements:

• Optional SCM, such as CVS or subversion where your source code resides. specifies where the source code is.

Note: in software engineering,Software Configuration Management (SCM)Is the task of tracking and controlling changes in the software.

• Optional triggers to control when Jenkins will perform builds. specifies when Jenkins triggers a build.
  
• Some sort of build script that performs the build (Ant, Maven, shell script, batch file, etc.) where the real work happens triggers the build, the script file used, such as ant. In this script file, we can download the latest code from SVN, delete the temporary file of the previous build, create necessary folders, compile the source code, execute, package and other work.
  
• Optional steps to collect information out of the build, such as archiving the artifacts and/or recording Javadoc and test results. Collect log information.
  
• Optional steps to notify relevant personnel of the build results, such as sending e-mails, IMs, updating issue tracker, etc.
  

For example, the build script we use is Ant and ant is executed in Jenkins. Some variables provided by Jenkins can be directly used in the script file.

At the same time, each job can have multiple steps. For example, define the execution program as step 1, the execution unit as step 2, and the coverage report as step 3.

You can also define post-build actions at the same time. For example, generate javadoc, or clear temporary file folders executed by the program.

Manually execute build

There are three ways to trigger a build:

• Builds in Jenkins can be triggered periodically (on a schedule, specified in configuration) the syntax defining schedule here is a common cron syntax in UNIX.
  
• Or when source changes in the project have been detected

You can set Jenkins to regularly check whether SVN has changed or manually check: http: // yourhost/Jenkins/job/projectname/pollong. You can also set Jenkins to post-commit. This method is especially suitable for situations where it takes a very long time to check whether the code is changed.

• Or they can be automatically triggered by requesting the URL:

Http: // yourhost/Jenkins/job/projectname/build

Distributed builds

Jenkins supports the "Master/Slave" mode, where the workload of building projects are delegated to multiple "slave" nodes, allowing single Jenkins installation to host a large number of projects, or provide different environments needed for builds/tests.

In reality, there are many situations where you need to use distributed builds. For example, to build a web application, you need to verify Firefox and IE respectively, so you need to execute ie on a Windows machine.

Or, the build is distributed to multiple slave nodes due to performance issues.

To the Jenkins management interface, you can easily add nodes. When configuring a node, you must provide the machine where the node is located, log on to usernamepassword, and use folders.

However, slave does not need to install Jenkins again. Jenkins automatically enables the slave agent and tests the build tools on a remote machine.

Note that the build results and artifacts will always end up on the master server. Therefore, you do not need to run to each node to view the files and logs generated by the build.

In fact, a local workspace is created on the slave node and used during execution. After all, because the build is executed on the slave node, this node must have all the factors required to execute the build.

In short, it is too convenient to join the node and remotely execute build ~

After a node is added, the configuration file about the node appears in the master Jenkins home folder.

Jenkins takes the initiative to decide on which node to execute the build based on the following policies:

Some slaves are faster, while others are slow. some slaves are closer (Network wise) to a master, others are far away. so doing a good build distribution is a challenge. currently, Jenkins employs the following strategy:

1. If a project is configured to stick to one computer, that's always honored.
2. Jenkins tries to build a project on the same computer that it was previusly built.
3. Jenkins tries to move long builds to slaves, because the amount of network interaction between a master and a slave tends to be logarithmic to the duration of a build (IOW, even if project a takes twice as long to build as Project B, it won't require double network transfer .) so this strategy has CES the network overhead.

Jenkins completes distributed build by executing slave agents. The most common situation is that the slave agent is executed on each slave node. The master remotely starts/stops the slave agent through SSH to control the behavior of each node.

One has the following four methods to start the slave agent:

? The master starts the slave agents via SSH
? Starting the slave agent manually using Java Web Start
? Installing the slave agent as a window service
? Starting the slave agent directly from the command line on the slave machine from the command line

Note that these four methods are applicable to different situations. For example, after the slave node is in the firewall, the master node cannot start or stop the slave agent through SSH. At this time, only the last three methods can be used, but there are often some drawbacks. For example, the Master cannot manually stop/restart the slave agent.

Once the node is successfully added, you can specify the node where the job is executed in the job:

Restrict where this project can be run (if not specified, it is determined by Jenkins, that is, it can be executed on the slave node or the master node, you can switch back and forth even in one build ).

Configure Jenkins to collect many other logs

Https://wiki.jenkins-ci.org/display/JENKINS/Logging

I think it is too practical for Jenkins beginners to infer the problem.

In today's popular continuous integration, we have deployed a unique jenkinsserver in various environments: Alpha, beta, and production.

Jenkinsserver is responsible for continuous integration of all components in the environment. That is to say, a jenkinsserver has many builds. So sometimes the "Monitor an external job" mentioned above is used.

But not distributed builds.

At the same time, because Jenkins enters every environment, including production, it uses auto deployment to automatically deploy Jenkins in each environment.

User Management

There is no doubt that Jenkins requires user management functions. In addition to developers, there are multiple roles who need to view the build results.

In System Management in Jenkins, you can set "no matter what users can do whatever things" or "login users can do whatever things ".

Therefore, the previous option means that Jenkins can be modified by any user who browses jenkinsurl. Or only a logged-on user can make changes.

Therefore, I divide Jenkins users into two categories: logged-on users and non-logged-on users.

1. If the repository is modified, users that have an impact on the build will be recorded in the local database by Jenkins. This type of user can be viewed on the Jenkins interface> View user.

However, these users are not formal Jenkins users and cannot log on to Jenkins. The permissions of such users are determined by the System Management Configuration mentioned above. Generally, you only have the permission to view the build and do not have the permission to change it.

2. Only users who explicitly note the token in Jenkins can log on to Jenkins and have permission control. For users who have been noted at the same time, there is a separate folder in the users folder under the jenkins_home folder to store relevant information. I am not sure if I can deploy the user elsewhere through copy/paste. I will try again later.

Permission management is far from that simple to meet the various requirements of Jenkins users. You have to check the details yourself ~

Jenkins script Console

Jenkins provides a script console groovy script which allows to run arbitrary scripts on the Jenkins server or on slave nodes. This feature can be accessed from the "manage Jenkins" link.

You can also use the URL to directly ask: http: // myserver: 8080/Hudson/script

Unfortunately, I don't understand it.

Jenkins (2)