Continuous Integration with Jenkins

Continuous integration
Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies to a shared mainline several times a day. It was first named and proposed by Grady Booch in his 1991. although Booch did not advocate integrating several times a day.

The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI isn't universally accepted as an improvement over frequent integration, so it is important to distinguish between the two as there is disagreement about the virtues of each.

In XP, CI was intended to be used in combination with automated unit tests written through the practices of test-driven development.

Continuous integration (CI) is an integral part of an agile software development setup. Sprint after sprint, teams strive to "not break the build" while delivering incremental features. But when developers focus completely on adding features, code errors can sometimes creep in and render the software unusable. To stop such errors from being integrated into the software configuration management (SCM), a CI server is the gatekeeper that helps keep a tab on code quality. Even if the code is integrated to SCM, a CI server can quickly tell you what went wrong

Tools for CI
  • Jenkins
  • Buildbot
  • Travis CI
  • Strider
  • Go
  • Integrity
here we talk about the Jenkins

    Jenkins is an open source continuous integration tool written in Java. The project was forked from Hudson after a dispute with Oracle.

In a nutshell, Jenkins is the leading open source automation server. Built with Java, it provides hundreds of plugins to support building, testing, deploying and automation for virtually any project.

Features
Jenkins offers the following major features out of the box, and many more can be added through plugins

Easy installation:  Just run java -jar jenkins.war, deploy it in a servlet container. No additional install, no database. Prefer an installer or native package? We have those as well

Easy configuration: Jenkins can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help

Rich plugin ecosystem: Jenkins integrates with virtually every SCM or build tool that exists. View plugins

Extensibility: Most parts of Jenkins can be extended and modified, and it's easy to create new Jenkins plugins. This allows you to customize Jenkins to your needs

Distributed builds: Jenkins can distribute build/test loads to multiple computers with different operating systems. Building software for OS X, Linux, and Windows

Installation on Linux
$ 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

to do more refer the links
1 : https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu
2 : http://www.vogella.com/tutorials/Jenkins/article.html

JENKINS_HOME directory
Jenkins needs some disk space to perform builds and keep archives. You can check this location from the configuration screen of Jenkins.
By default, this is set to ~/.jenkins, but you can change this in one of the following ways:

Set "JENKINS_HOME" environment variable to the new home directory before launching the servlet container.

Set "JENKINS_HOME" system property to the servlet container.

Set JNDI environment entry "JENKINS_HOME" to the new directory.

See the container specific documentation collection for more about how to do this for your container.

You can change this location after you've used Jenkins for a while, too. To do this, stop Jenkins completely, move the contents from old JENKINS_HOME to the new home, set the new JENKINS_HOME, and restart Jenkins.

JENKINS_HOME has a fairly obvious directory structure that looks like the following

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)
     +- workspace (working directory for the version control system)
     +- [JOBNAME] (sub directory for each job)
     +- jobs
     +- [JOBNAME] (sub directory for each job)
     +- config.xml (job configuration file)
     +- 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)

Jenkins Build Jobs
Creating a new build job in Jenkins is simple: just click on the “New Job” menu item on the Jenkins dashboard. Jenkins supports several different types of build jobs, which are presented to you when you choose to create a new job

Freestyle software project
Freestyle build jobs are general-purpose build jobs, which provides a maximum of flexibility.

Maven project
The “maven2/3 project” is a build job specially adapted to Maven projects. Jenkins understands Maven pom files and project structures, and can use the information gleaned from the pom file to reduce the work you need to do to set up your project.

Workflow
Orchestrates long-running activities that can span multiple build slaves. Suitable for building pipelines and/or organizing complex activities that do not easily fit in free-style job type.

Monitor an external job
The “Monitor an external job” build job lets you keep an eye on non-interactive processes, such as cron jobs.

Multiconfiguration job

The “multiconfiguration project” (also referred to as a “matrix project”) lets you run the same build job in many different configurations. This powerful feature can be useful for testing an application in many different environments, with different databases, or even on different build machines.

Building a software project (free style)

Jenkins can be used to perform the typical build server work, such as doing continuous/official/nightly builds, run tests, or perform some repetitive batch tasks. This is called "free-style software project" in Jenkins.
Setting up the 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.

optional triggers to control when Jenkins will perform builds.

some sort of build script that performs the build (ant, maven, shell script, batch file, etc.) where the real work happens

optional steps to collect information out of the build, such as archiving the artifacts and/or recording javadoc and test results.

optional steps to notify other people/systems with the build result, such as sending e-mails, IMs, updating issue tracker, etc.

Builds for Non-Source Control Projects
There is sometimes a need to build a project simply for demonstration purposes or access to a SVN/CVS repository is unavailable. By choosing to configure the project as "None" under "Source Code Management" you will have to:

Build the Project at least once, (it will fail), but Jenkins will create the structure jenkins/workspace/PROJECTNAME/

Copy the project files to jenkins/workspace/PROJECTNAME/

Build again and configure appropriately

Jenkins Set Environment Variables
When a Jenkins job executes, it sets some environment variables that you may use in your shell script, batch command, Ant script or Maven POM . See the list of variable by clicking on ENVIRONMENT_VARIABLE
Configuring automatic builds

Builds in Jenkins can be triggered periodically (on a schedule, specified in configuration), or when source changes in the project have been detected, or they can be automatically triggered by requesting the URL
http://HOST/jenkins/job/PROJECTNAME/build
This allows you to hook Jenkins builds into a variety of setups.

Builds by source changes
You can have Jenkins poll your Revision Control System for changes. You can specify how often Jenkins polls your revision control system using the same syntax as crontab on Unix/Linux. However, if your polling period is shorter than it takes to poll your revision control system, you may end up with multiple builds for each change. You should either adjust your polling period to be longer than the amount of time it takes to poll your revision control system, or use a post-commit trigger. You can examine the Polling Log for each build to see how long it took to poll your system.

Alternatively, instead of polling on a fixed interval, you can use a URL trigger (described above), but with /polling instead of /build at the end of the URL. This makes Jenkins poll the SCM for changes rather than building immediately. This prevents Jenkins from running a build with no relevant changes for commits affecting modules or branches that are unrelated to the job. When using /polling the job must be configured for polling, but the schedule can be empty.

Builds by e-mail (sendmail)
If you have the root account of your system and you are using sendmail, I found it the easiest to tweak /etc/aliases and add the following entry:

jenkins-foo: "|/bin/wget -o /dev/null http://YOURHOST/jenkins/job/PROJECTNAME/build"

and then run "newaliases" command to let sendmail know of the change. Whenever someone sends an e-mail to "jenkins-foo@yoursystem", this will trigger a new build.

With qmail, you can write /var/qmail/alias/.qmail-jenkins as follows:

|/bin/wget -o /dev/null http://YOURHOST/jenkins/job/PROJECTNAME/build

Building a Maven project
Jenkins provides a job type dedicated to Maven 2/3. This job type integrates Jenkins deeply with Maven 2/3 and provides the following benefits compared to the more generic free-style software project.

Jenkins parses Maven POMs to obtain much of the information needed to do its work. As a result, the amount of configuration is drastically reduced.

Jenkins listens to Maven execution and figures out what should be done when on its own. For example, it will automatically record the JUnit report when Maven runs the test phase. Or if you run the javadoc goal, Jenkins will automatically record javadoc.

Jenkins automatically creates project dependencies between projects which declare SNAPSHOT dependencies between each other. See below.

Thus mostly you just need to configure SCM information and what goals you'd like to run, and Jenkins will figure out everything else.

this project type can automatically provide the following features:
  • Archive artifacts produced by a build
  • Publish test results
  • Trigger jobs for projects which are downstream dependencies
  • Deploy your artifacts to a Maven repository
  • Breakout test results by module
  • Optionally rebuild only changed modules, speeding your builds
  • Automatic build chaining from module dependencies
Jenkins reads dependencies of your project from your POM, and if they are also built on Jenkins, triggers are set up in such a way that a new build in one of those dependencies will automatically start a new build of your project. Jenkins understands all kinds of dependencies in POM. Namely, parent POM

<dependencies> section of your project
<plugins> section of your project
<extensions> section of your project
<reporting> section of your project

This process takes versions into account, so you can have multiple versions/branches of your project on the same Jenkins and it will correctly determine dependencies. This feature can be disabled on demand - see configuration option Build whenever a SNAPSHOT dependency is built

The Maven Integration Plugin
The Maven 2 project type is contained in the Maven Integration plugin, which is bundled with Jenkins. If you are running any version of Jenkins earlier than the current release, it may show up in the list of plugins having available updates. It is recommended not to upgrade the Maven Integration plugin separately from Jenkins itself. While it is technically a plugin, it is developed, tested, and released as part of the Jenkins core.
Installation
1 . go into Manage Jenkins>>configure System
2. in maven tab “Click on maven installation......

You can either get Jenkins to install a specific version of Maven automatically , or provide a path to a local Maven installation (You can configure as many versions of Maven for your build projects as you want, and use different versions of Maven for different projects.

If you tick the Install automatically checkbox, Jenkins will download and install the requested version of Maven for you and install it to the tools directory in the Jenkins home directory.

How to Use It
First, you must configure a Maven installation (this step can be skipped if you are using DEV@cloud). This can be done by going to the system configuration screen (Manage Jenkins-> Configure System). In the “Maven Installations” section, 1) click the Add button, 2) give it a name such as “Maven 3.0.3” and then 3) choose the version from the drop down.

Now, Jenkins will automatically install this version any time it’s needed (on any new build machines, for example) by downloading it from Apache and unzipping it.

Create a new Maven Job
1. Clicking “New Job / New Item” on left hand
2. Give it a name
3. Choose the “Build a Maven 2/3 project”
4. Save your job

Now you need to configure of your job

1. Choose the SCM you want to use (ex. Using git)
2. choose maven target to call
3. add Repository URL and Credential.
4. check user private maven repo

You can also define the customer path for the same.

Build Project
Build your project by clicking on build now and click on the progress bar in the left hand “Build Executor Status” to watch jenkins install Maven, checkout your project, and build it using maven.

Comments

Post a Comment

Popular Posts

Enable JMX Port in Tomcat with authentication

Load Balancing usign HAProxy for Openfire

Enable Clustering in Openfire