Jenkins (ii)

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

My article, however, is simple enough to describe what features Jenkins offers. More people still want to learn their own ~

The homepage of the website provides a Jenkins installation package for the Windows version number. We are able to download one for learning. After installation, you can see the Jenkins interface by actively opening the http://localhost:8080.

Other needs to be installed are:

1,jenkins is a Java program, so you need to install the JDK.

2, at the same time to perform job needs to provide repository, that is, store Jenkins regular poll source code place. We are able to go to GitHub for a free booklet.

3, pretend to use Ant,maven in Jenkins, and so on, you also need to install separately. But it's not necessary.

Start Jenkins

Jenkins natively supports the unix-like system.

• Direct execution
  

Well, Jenkins is a Java program, so to execute it, it just needs to:

$ Java-jar Jenkins.war

We can also use the Nohup command to let Jenkins execute in the background.

After opening the URL http://MyServer 8080 will be able to easily operate Jenkins.

The official website gave an example of sh to start Jenkins. Can take a look.

• Executing in servlet container

Alternatively, if you had a servlet container that supports Servlets 2.4/jsp 2.0, such as Glassfish v2, Tomcat 5 (or any L ater versions), then you can run them as services, and deployJenkins.war as you would any other war file.

For example,
You could simply place the Jenkins.war file in Tomcat ' s WebApps directory. The URL that is used at this point is changed by default:

Http://localhost:8080/jenkins

At the same time, Jenkins provides some special features that are not started by default, and refer to the link below to enable them.

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

The folder structure of Jenkins

Like Cruisecontroler, JENKINS needs a folder to store related files: Jenkins_home. I feel ~/.jenkins. is a hidden folder under the user's home folder. We can also change the jenkins_home, pointing to where we want to be.

(Note that because it is a hidden folder, you need to use Ls-al talent to see)

Jenkins_home
+ config (Jenkins root configuration)
+-*.xml (other site-wide configuration files)
+-usercontent (files in this directory would be served under your http://server/userContent/)
+-Fingerprints (stores fingerprint records)
+-Plugins (stores plugins)
+-Jobs
+-[JOBNAME] (sub directory for each job)
+ config (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 rights management, you will also have the Users folder under the home folder.

In terms of folder structure, it is similar to Cruisecontroller. In this configuration, config file is important for Jenkins. We all know that Jenkins is used to monitor multiple builds, and the Jobs folder is a place where every build-related information is stored.

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

Backup and Recovery

Backup and recovery is easy, simple copy Jenkins folder is good:

All the settings, build logs, artifact archives is 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 Job

Because each of jobs has its own separate folder, we can be very easy:

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

After the change, run the following command refresh:

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

Here [command] can be: Exit exits, restart restarts, reload overloads.

Create a project

Because Jenkins can be used to perform various CI, test, batch tasks, and so on, these tasks are collectively referred to as "Free-style software Project" in Jenkins.

Jenkins also offers other types of jobs, such as:

1, suppose the project is Maven,jenkins also provides a job for MAVEN project only. But the fact that Free-style software projec can still be used to create MAVEN projects is just as good for MAVEN projects as it is for a better combination.

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

3, or a matrix project, which is Multi-configuration project.

I'm not sure if there are only 4 jobs, maybe using plugins to create many other types of jobs, let's look at the information.

Here's how to create one of the most common "Free-style software Project" Procedures:

Go to Jenkins top page, select "New Job" and 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. Specify where the source code is.

Note:in Software Engineering, software configuration management (SCM) is the task of tracking and controlling ch Anges in the software.

• Optional triggers to control when Jenkins would 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 The script file used when the build was triggered, such as Ant. In this script file, we are able to download the latest code from SVN, delete the last build of the temporary files, create the necessary folders, compile the source code, execute, pack and so a series of work.
  
• Optional steps to collect information out of the build, such as archiving the artifacts and/or recording javadoc and test Results. Collects log information.
  
• Optional steps to notify other people/systems with the build result, such as sending e-mails, IMs, updating issue tracker, etc. notify the result of the build of the relevant person.
  

For example, the build script we use is ant, which executes ant in Jenkins. In the script file, you can directly use some of the variables that Jenkins provides.

At the same time, each job can have multiple step. For example: The execution program is defined as STEP1, the execution unit test is defined as STEP2, and the generated coverage report is defined as STEP3.

You can also define post-build action at the same time. For example: Generate Javadoc, or cleanup program execution temporary files folder.

Self-executing build

There are three ways to trigger a build:

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

The ability to set Jenkins timing checks if SVN has changed and can be checked manually: Http://YOURHOST/jenkins/job/PROJECTNAME/pollong. It is also possible to set Jenkins as Post-commit, which is especially useful when checking if code changes take a very long time.

• Or they can 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 is delegated to multiple "slave" nodes, Allowing single Jenkins installation to host a large number of projects, or provide different environments needed for Bui Lds/tests.

In the reality of the need to use distributed builds situation is very much, such as: a Web application build, you need to verify the behavior of Firefox and IE, then you need to implement IE on the Windows machine.

Or because of performance problems, the build is distributed to multiple slave nodes.

To the management interface of Jenkins, it is easy to join the node. When you configure a node, you need to provide the machine where the node resides, log in Usernamepassword, use the folder, and so on.

But slave does not need to install Jenkins again. Jenkins will actively enable the slave agent itself, and the build will need tools to test the remote machine.

It is important to note that the build results and artifacts would always end up on the master server. So there is no need to run to each node to see the files generated by the build, log, etc.

In fact, in the slave node, a local workspace is created, and this workspace is used at execution time. Because the build executes on the slave node after all, the node must have all the necessary elements to execute the build.

Anyway, it's so convenient to join the node and execute the build remotely.

When you join a node, the configuration file for that node appears under the Master Jenkins home folder.

Jenkins will proactively decide on which node to execute the build, based on the following policy:

Some slaves is faster, while others is slow. Some Slaves is Closer (network wise) to a master, others is 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 previously built.
3. Jenkins tries to move long builds to slaves, because the amount of network interaction between a master and a slave tends To being logarithmic to the duration of a build (IOW, even if Project a takes twice as long to build as Project B, it won ' t R Equire double network transfer.) So this strategy reduces the network overhead.

Jenkins completes the distributed build by executing the slave agents. The most common scenario is that the slave agent executes on each slave node. Master remotely starts/stops the slave agent via SSH, which in turn controls the behavior of each node.

One of the following 4 ways 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.

It is important to note that these 4 methods are suitable for different situations, such as the slave node behind the firewall, which prevents Master from stopping the slave agent via SSH. At this point only can be used in the latter three ways, but often have some drawbacks, such as master can not actively stop/restart slave agent.

Once you join node successfully, you can specify in the job which node the job will execute:

Restrict where this project can be run (assuming that it is not specified, it is up to Jenkins to be able to execute on the slave node, to execute on the master node, and even to switch back and forth in a single build).

Configure Jenkins so that it collects a lot of other logs

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

I think this is too practical for the beginner Jenkins to infer that the problem lies.

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

Jenkinsserver Unified is responsible for the continuous integration of all components within the environment. In other words, a jenkinsserver will have a very multiple build. So the "Monitor an external job" mentioned above is sometimes used.

But not distributed Builds.

At the same time, because Jenkins will enter every environment, including production, so will use auto deployment way, self-actively complete the deployment of Jenkins in various environments.

User Management

There is no doubt that there is a need for utility management in Jenkins, because in addition to developers, people with multiple roles need to see the results of the build.

In the system management in Jenkins, you can set "no matter what the user can do whatever" or "login user can do whatever."

So the previous option means that any user browsing Jenkinsurl can change Jenkins. Or just login user ability to make changes.

So I divided the users in Jenkins into two categories: the user can log in and the non-logged-in user.

1, only if the change of repository, that is, the build has affected the user, will be recorded by Jenkins in the local database. This type of user we are able to browse in the Jenkins interface and view users.

But such users are not official Jenkins users and cannot log in to Jenkins. The permissions of such users are determined by the configuration in the system administration described above. There is usually only permission to view the build and no permissions to change it.

2, only users who are aware of the registration in Jenkins can log in to Jenkins and have permission to control it. Users who have registered at the same time, under the Users folder in the Jenkins_home folder, have a separate folder to store related information. I'm not sure if I can deploy the user to other places through copy/paste and look back and try.

Since there are a variety of needs to be met for Jenkins to use, rights management is far less straightforward. We have to look at the details.

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 is accessed from the "Manage Jenkins" link.

Direct access via URL: http://myserver:8080/hudson/script

It's a pity that I can only use groovy to disprove my ignorance.

Jenkins (ii)