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 straightforward.
Continuous Integration is best understood as a development practice which involves the developers to integrate their working code into a shared repository (like an 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 is 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 is 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 of 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 need 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:
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:
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 into 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 is the list of steps/tasks performed by Jenkins when triggered:
Jenkins focuses on the following two important activities to the core, which are given as below:
Following are the features made available by Jenkins for any consumer to use is as mentioned below:
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:
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.
Free Demo for Corporate & Online Trainings.