In this article, we will introduce you to the concepts of Continuous Integration and once we are able to digest the concepts well, we will take a step further to understand the need of Jenkins (in the grounds of Continuous Integration). Let us not delay this fantastic topic and get to the topics straight forward.
Continuous Integration is best understood as a development practice which involves the developers to integrate their working code into a shared repository (like a SVN, or a CVS) at frequent intervals to achieve a common objective. This concept was designed such to eliminate the occurrences of issues in the build lifecycle (in software development). With the concept of Continuous integration, there lies the need to have frequent builds. Rule of the thumb goes like this, there should be a build whenever there is a commit that occurs from a developer.
Continuous integration also ensures that all the day to day development activities are integrated at a given point in time by compiling and building the project, for a well-tested and error free build. The basic idea behind this concept would then be to ensure that there are no compilation issues at the time of build as there can be many check-in’s from a lot of developers from the development team. This will ensure that there are no compilation related issues at an earlier stage than later when there is a desperate need of a build but would’ve failed because of a compilation error without the usage of Continuous integration technique.
This process will remain successful until and unless all the activities carried out by all the developers are done in a collaborative manner and the code then be merged to a Central Repository system (such as SVN or CVS). This ensures that the integration related troubles are eliminated. Continuous Integration enables that the each and every integration is automatically built, deployed and tested thoroughly (with the help of the regression tests run against the code checked in).
With the understanding of the concept Continuous Integration well understood, let us get into some historical details of Continuous Integration. The term Continuous Integration was termed by Grady Booch in the year 1994. This was coined in the Object Oriented Analysis & Design application – to explain the key role that small internal releases play in the development of micro-processes. This was taken a step further by two Software Engineers named Kent Beck and Ron Jeffries with the invention of ‘Extreme Programming with Continuous Integration’.
Continuous Integration was originally invented or designed to use in conjunction with the automated unit test-cases written in a test driven development (TDD) environment. This means to run all the unit test-cases in the environment of the developer to ensure that all these unit test-cases are successful without any issues before checking-in any modified code from the developer’s machine to the central repository. This was an additional care taking step to avoid any build breaks on the working copy (available in the main stream) when the developers work on the same module.
Now the understanding of Continuous Integration, let us now try to also understand the best practices that needs to be used within our projects. These not only help us achieve the common goal of Continuous Integration well but also ensures that there is a better software quality of the product that is being developed. Let us take a look at each of these best practices for us to apply them in our projects:
1. To maintain a proper code repository
2. To automate the build process of the code
3. Ensuring code check-ins on a daily basis as against batch commits
4. Ensure that the commit made should always be buildable
5. Results of the build should be transparent, made available to developers so as to keep them aware of the software quality of the product on a daily basis
6. Testing the build on a Production like environment always
7. A build broken by a commit should be fixed immediately
8. Latest build should be available to everyone from the main stream
9. To automate the deployment process
Following the best practices that Continuous Integration makes a project apply on each of the projects, the following are the advantages that can be reaped from the same. Let us take a look at the following advantages of Continuous Integration:
1. Level of risk is automatically reduced
2. Integration processes are no longer bigger
3. Code analysis will be performed on each build ensuring the software quality
4. Bugs can be reduced at earlier stages of software development process itself
5. Faster and easier deployment process
6. Process gets even easier with use of tools like Jenkins and Cruise Control
In the previous sections of the article, we have tried to understand the concept of "Continuous integration". In order to create an environment that supports Continuous Integration, tools as like Jenkins can fill the void. Let us get in to action and let us understand how Jenkins jumps into action when you want to work with Continuous Integration as such.
To start with, Jenkins is an Open Source tool that makes Continuous Integration easy task. It can be integrated with a various number of testing and deployment technologies. Jenkins is the project that was forked from Hudson due to issues with Oracle. Jenkins is nothing but a server based system running in a servlet container (as like Apache Tomcat). Supports tools as like Git, SVN, Clearcase and etc.
The primary job of the Jenkins is to execute a list of steps configured which is based on a trigger. Below are the list of steps/tasks performed by Jenkins when triggered:
1. Run code compilation, build the software with ANT or Maven or Gradle
2. Run an internal shell script
3. Archive resultant builds
4. Trigger execution of integration tests
5. Monitoring the execution of tasks
6. To be able to stop building in case of failure in any steps
7. Notification of success or failure of each build.
Jenkins focuses on the following two important activities to the core, which are given as below:
1. Continuous build of Software: It should be able to create a continuous integration environment.
2. Monitoring execution of external jobs: This monitors the CRON jobs.
Following are the features made available by Jenkins for any consumer to use is as mentioned below:
1. Easy to configure and installation
2. eadable URLs for the builds
3. Notifications via email integration
4. Reporting Junit tests
5. Every successful build to support tagging
6. Distributed builds
7. Plugin support
8. Managing dependencies via file fingerprints
Following are some of the best practices that can be used while Jenkins is being used as your Continuous Integration software option, listed as below:
1. Always secure Jenkins with user authentication.
2. Integrate Jenkins with the ticket tracking systems as like JIRA
3. Configure Jenkins to generate a trend report
4. Jenkins should be setup on a disk with bigger space
5. Setup various jobs segregating maintenance and development activities
6. Archive unused jobs and then delete them
7. Email notifications to be setup to all developers
8. To tag branch, baseline after every successful build
In this article, we have gone through the concepts of Continuous Integration in great detail. We also have tried to understand how Jenkins fills the void of Continuous Integration in your software development process. Hope that these details are good enough for you to take the better suggestions to your projects, if they are not following these tips and tricks.
Get Updates on Tech posts, Interview & Certification questions and training schedules