Jenkins continuous Integration Tutorial
When someone from Software industry hears the word Jenkins, what comes first to his/her mind is “Continuous Integration software”. Well it helps to automate the less interactive human part of the software development process, with 24x7x365 days of continuous integration feature available at its disposal and also enabling technical aspect of continuous delivery.
Jenkin is a server-based system that has inherited from Apache Tomcat. Jenkins was initially released under MIT License and Mr. Kohsuke Kawaguchi is responsible for its development. And the best part, it’s FREE.
So, why it is so popular:
- Being open source implementation is FREE
- Good community support online
- 1500+ plugins at your disposal
- Customize or custom create your plugin and share it on internet
- Portability with several platforms since its coded in Java
- Easy to install and configure
- Schedule the builds as and when required
- Good documentation and tones of quality information available on internet.
Another important aspect of Jenkins is its ability to integrate with multiple software applications and frameworks.
The Jenkins effect
Before Jenkins came into picture this is how the entire continuous integration cycle use to take place manually:
- Gather the requirement and build the software as a whole.
- Test the software as a whole. Identify defects and get them fixed by responsible developer
- Due to defect fixes, perform Regression test across platforms
- Post deployment gather new requirements
- Build the software in such a way that the new functionality does not affect the existing one. So, integration was the major challenge and nightmare for most of the experienced developers
- Post development, testing use to start and so developers have to wait to get feedback on their developed work
- Since the whole process was manual, it was extremely time consuming and does not stay true to Quality Assurance.
After Jenkins came into picture things totally changed:
- Developer downloads locally on his machine the copy of the code that he needs to work on.
- Post changes he/she makes a commit and his/her code gets integrated immediately with the main centralized repository
- A build is automatically triggered by Jenkins for this particular commit
- And once the build is triggered an automation unit test scripts starts getting executed in the background.
- If there is a failure then an automated mail is dropped to the developer who has committed the changes, asking him/her to have a check and fix the issues then and there
- Thus, developers now need to focus only on that particular commit
- Developers now know the test results with each and every commit.
Now, that’s what I call “The Jenkins Effect”
When to use Jenkins
Let me share with you my live experience with one of the best companies that I have worked on TCS – Mumbai. I am pretty sure that you all would have heard of Tata Consultancy Services. I used to work in the banking and insurance domain of TCS. There were lots of quality software development processes being implemented in our project. One of the project was called as the Nightly deployable build.
That means all the developers use to check out their codes in the central repository throughout the day and having a cut off time of 9pm. Post 9 pm all the newly code merges i.e. the newly code that were added throughout the day use to create a build by an in-house software. Now this sounds similar to Continuous Integration practices by Jenkins. However, since there is a difference i.e. the code size was huge so defect fixing and maintenance of an existing code use to create havoc on the floor.
Diagram above shows the solution schematics.
The solution can be easily understood if you keep the above picture in mind.
Now to solve this problem, the best fit solution would have been handling continuous integration via Jenkins. So, with every commit being made in the repository a new build gets generated. Thus, if there is an issue in the merge then it is tracked then and there with an immediate mail to the responsible developer, asking them to look into in and provide a fix. Thus, this will save a hell of a time for all of the persons involved in the project implementation. Here with the implementation of Jenkins life becomes easy for developers too as in case of any issue then developer will have to look only into that piece of code thus maintenance becomes easy too.
Usage of Jenkins
Below are the reasons on “Why Jenkins is used?”
- Jenkins helps in version controlling
- Helps in executing shell scripts, bash scripts
- Have integration facility with Maven and ANT
- One can specify time when he/she wants the build to be triggered
- If there are any failures then notification is mailed to all stakeholders
- Jenkins is highly customizable and configurable as per ones needs. Thus, making it flexible enough to use
- Have facility to trigger build by polling intervals or periodic
- Jenkins can be configured for Git, GitHub, SVN and various other repositories too.
- Easy to install and great documentation support
To conclude, Jenkins has become a tool of choice for all continuous integration initiatives. This Jenkins tutorial handled the topic at a conceptual level.
This tutorial is brought to you by Techcanvass.
Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.
Techcanvass offers a course on Continuous Integration with Jenkins.