How to integrate github with Jenkins ?

Github plugin can be used to receive push notifications that can trigger a Jenkins job.

Install Github plugin

• Open Jenkins home page and Login as Admin (if security is enabled)
• Click manage Jenkins
• Click Configure Jenkins
• Go to Manage Plugins link on left side
• Select Github plugin from available plugins
• Click Download and Install
• Restart Jenkins

Configuration of Github project in a Jenkins job

• Open Jenkins home page
• Select the job
• Click Configure link on left side
• Inside Source code management section, Enter URL of Github projecthttp://github.com/username/project
• For authentication, provide username / password in advanced... options.

Receiving the push notifications from GitHub

• Open Jenkins home page and Login as Admin (if security is enabled)
• Click manage Jenkins
• Click Configure System
• In Github Web hook section, select auto-manage hook URLs
  
  OR
• In Github Web hook section, select Manually manage hook URLs
• Go to Github project page
• In Service Hooks tab, select Post-Receive URLs hook
• Add URL <root_URL_of_Jenkins>/github-webhook
• Open Jenkins home page
• Select the job
• Click Configure link on left side
• Select Build when a change is pushed to GitHub and Save.
 

How to integrate git with Jenkins ?

Plugin site : https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin

Git can be used to checkout the code in Jenkins jobs using Git plugin of Jenkins.

Install Git plugin

• Open Jenkins home page and Login as Admin (if security is enabled)
• Click manage Jenkins
• Click Configure Jenkins
• Go to Manage Plugins link on left side
• Select Git from available plugins
• Click Download and Install

Configuration of Git repo in a Jenkins job

• Open Jenkins home page
• Select the job
• Click Configure link on left side
• Inside Source code management section, Enter URL of Git projecthttps://www.myrepo/git/projects/myproject.gitBy default, it will checkout all branches of the repository
• To build a particular branch, provide branch name
• For authentication, provide username / password in advanced... options.

What solution can be provided by Continuous integration ?

Continuous integration (CI) is the practice of merging all developer workspaces with a shared mainline.

It was first named and proposed as part of extreme programming (XP).

Its main aim is to prevent integration problems.

Problem

When embarking on a change, a developer takes a copy of the current code base on which to work.

As other developers submit changed code to the source code repository, this copy gradually ceases to reflect the repository code.

Not only can the existing code base change, but new code can be added as well as new libraries, and other resources that create dependencies, and potential conflicts.

The longer a branch of code remains checked out, the greater the risk of multiple integration conflicts and failures becomes when it is reintegrated into the main line.

When developers submit code to the repository they must first update their code to reflect the changes in the repository since they took their copy.

The more changes the repository contains, the more work developers must do before submitting their own changes.

In a worst-case scenario, developers may have to discard their changes and completely redo the work.

CI  as a solution

The practice aims to reduce rework and thus reduce cost and time.

A complementary practice to CI is that before submitting work, each programmer must do a complete build and run (and pass) all unit tests.

Integration tests are usually run automatically on a CI server when it detects a new commit.

All programmers should start the day by updating the project from the repository. That way, they will all stay up-to-date.

What are the advantages and disadvantages of Continuous integration ?

Advantages of Continuous integration

• When unit tests fail or a bug emerges, developers might revert the codebase to a bug-free state, without wasting time debugging.

• Developers detect and fix integration problems continuously — avoiding last-minute changes at release dates.

• Early warning of broken / incompatible code

• Early warning of conflicting changes

• Immediate unit testing of all changes

• Constant availability of "current" build for testing, demo, or release purposes
• Immediate feedback to developers on the quality, functionality, or system-wide impact of code they are writing

• Frequent code check-in pushes developers to create modular, less complex code

Disadvantages

• Initial setup time required

• Well-developed test-suite required to achieve automated testing advantages

What are the principles of Continuous integration ?

Principles of Continuous integration

Continuous integration is the practice of frequently integrating one's new or changed code with the existing code repository – should occur frequently enough that no intervening window remains between commit and build, and such that no errors can arise without developers noticing them and correcting them immediately.

Automated tools such as CruiseControl, Jenkins, Hudson, Bamboo, BuildMaster, AnthillPro or Teamcity offer this scheduling automatically.

Another factor is the need for a version control system that supports atomic commits, i.e. all of a developer's changes may be seen as a single commit operation.

Continuous integration relies on the following principles :

1. Maintain a code repository

• Use of a revision control system for the project's source code.
• All artifacts required to build the project should be placed in the repository.
• System should be buildable from a fresh checkout and not require additional dependencies.
• The mainline (or trunk) should be the place for the working version of the software.

2. Automate the build

• A single command should have the capability of building the system.
• Tools like Ant, Maven, Gradle, MSBuild, OpenMake Meister or IBM Rational Build Forge are frequently used in continuous integration environments.
• The build script not only compiles binaries, but also generates documentation, website pages, statistics and distribution media.

3. Make the build self-testing

• Once the code is built, all tests should run to confirm that it behaves as the developers expect it to behave.

4. Everyone commits to the baseline every day

• By committing regularly, every committer can reduce the number of conflicting changes.
• In addition performing a nightly build is generally recommended.

5. Every commit (to baseline) should be built

• The system should build commits to the current working version in order to verify that they integrate correctly.
• Automated Continuous Integration can be used where a continuous integration server or daemon monitors the version control system for changes, then automatically runs the build process.

6. Keep the build fast

• The build needs to complete rapidly, so that if there is a problem with integration, it is quickly identified.

7. Test in a clone of the production environment

• Having a test environment can lead to failures in tested systems when they deploy in the production environment, because the production environment may differ from the test environment in a significant way.
• Building a replica of a production environment is cost prohibitive.

8. Make it easy to get the latest deliverables

• Making builds readily available to stakeholders and testers can reduce the amount of rework necessary when rebuilding a feature that doesn't meet requirements.
• Finding errors earlier also, in some cases, reduces the amount of work necessary to resolve them.

9. Everyone can see the results of the latest build

• It should be easy to find out whether the build breaks and, if so, who made the relevant change.

10. Automate deployment

• Most CI systems allow the running of scripts after a build finishes.

What is Continuous integration (CI) ?

Continuous integration is a process in which all development work is integrated at a predefined time or event and the resulting work is automatically tested and build. 

Development errors are identified very early in the process.

Several open source Continuous integration tools can be used to perform continuous integration, like Jenkins, Hudson etc.

What is Jenkins and its features ?

What is Jenkins ?

• Open source tool to perform continuous integration 
• monitors a version control system and if changes occurs to start and monitor a build system (for example Apache Ant or Maven)  
• monitors the whole build process and provide reporting functionality and notification functionality to report success or errors.
• It can be extended by additional plug-ins, e.g. for building and testing applications. 

Features of Jenkins

• Easy install 
  Just deploy jenkins.war in a servlet container. No additional install, no database.

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

• Change set support
  Jenkins can generate a list of changes made into the build from Subversion/CVS.

• Permanent links
  Jenkins gives you clean readable URLs for most of its pages, including some permalinks like "latest build"/"latest successful build", so that they can be easily linked from elsewhere.

• e-mail integration
  Get real-time notifications on failures.

• After-the-fact tagging
  Builds can be tagged long after builds are completed.

• JUnit / TestNG test reporting
  JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc.
  
  History trend is plotted into a graph.

• Distributed builds
  Jenkins can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers' desks.

• File fingerprinting
  Jenkins can keep track of which build produced which jars, and which build is using which version of jars, and so on. 
  
  This works even for jars that are produced outside Jenkins, and is ideal for projects to track dependency.

• Plugin support
  Jenkins can be extended via 3rd party plugins. You can write plugins to make Jenkins support tools/processes that your team uses.

What activities could be integrated in Jenkins ?

How to install and configure Jenkins ?

Installation

1. Download jenkins.war

2. Move WAR to a web deployment dir of Servlet container.

3. Start the server (container).

4. Open web browser and go to URL http://myServer:8080, where myServer is the name of the system running Jenkins.

JENKINS_HOME

Jenkins needs some disk space to perform builds and keep archives.

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.

To change this path in between :

   1. Stop Jenkins completely

   2. Move the contents from old JENKINS_HOME to the new home

   3. Set the new JENKINS_HOME

   4. Restart Jenkins

Contents of JENKINS_HOME

How to take backup and restore the Jenkins ?

Backup and restore the Jenkins

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.

Back ups can be taken without stopping the server, but when you restore, please do stop the server.

How to setup the project in Jenkins ?

Setup 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 :

 1. optional Source code management, such as CVS or SVN where your source code resides.

 2. optional triggers to control when Jenkins will perform builds.

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

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

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