Jenkins Basics

Jenkins is widely used tool in the software development companies. Today I am going to explain basics of Jenkins. Also the sample setup with maven project and svn.

What is Jenkins?

As quoted from the Jenkin’s official website, “Jenkins is a self-contained, open source automation server which can be used to automate all sorts of tasks related to building, testing, and deploying software.” In simple words, we can say that it’s a continuous integration and delivery tool.

What are Continuous Integration and Continuous Delivery?

Continuous integration is nothing but merging the code from all the developers to one central branch and trying to avoid conflicts. CI is development practice where each check-in by a developer triggers a build. Normally the CI servers are linked with some version control tool like SVN allowing automating build process.

Continuous delivery involves automated builds followed by acceptance tests and deployment to server. The main aim of CD is to keep the code in deployable state at any given time.

Jenkins can be used as a simple CI server or turned into the continuous delivery hub for any project.

What is build?

A software build can be thought of final deliverable of a project. Every project has some final deliverable be it war file, jar file or anything else. In order to prepare this build, build script is written. This script decides what gets packaged in the final deliverable.

What is the use CI?

CI becomes important when multiple developers work on the same project code and it’s really important to keep your project in ready state any moment of time. The ready state here doesn’t mean feature or functionality wise ready. It just means that the build should be stable.  Consider the advantage of using CI from developer’s and QA’s perspective:

Developer’s perspective: Since after every check-in a build runs, the developer will come to know if there are any issues with his code immediately after build is ready. If the build is successful, developer can go on to develop next features while if build fails it displays the error trace which helps developer to fix the issue and keep on checking until his build becomes successful.  Since, CI is linked with version control tool, one can see who made the changes or who triggered the build.

QA’s perspective: In traditional ways, the QAs get the build only after all the development is done. In cases of huge applications, it becomes cumbersome for them to test the entire functionalities in one go. While with CI, once a developer is done with developing a feature, QA can take up corresponding build and test the functionality. The build for which the issue was raised and the build in which it was fixed can be maintained with some issue tracking systems like JIRA. This creates a systematic development and testing environment.

How does it work?

As mentioned earlier, Jenkins is linked with some version control tool like SVN. Every project has a unique path in SVN. While setting up a project in Jenkins, one has to provide this path. Once developer checks-in the code, a trigger is activated and Jenkins fetches the code from the mentioned path and tries to prepare the build. The build parameters can be configured within project on Jenkins.

Sample Jenkins Setup:

Note: Following mentioned steps are considering you have a maven project and SVN as code repository.

Step 1: Download the Jenkins distribution and make the server up on any port. Make sure that you have installed the required plugins for Jenkins like Subversion or Git.

Step 2: From the home page of Jenkins, go to New Item. Here, you will be able to see various options for configuring your project in Jenkins. For simple configuration, choose Freestyle Project.

Step 3: Configure the project. In order to do so, you have fill in following information:

1. General details: Includes basic information about project like project name and description, options like discarding old builds etc.                                                                                                                   
2. Source Code Management: Here, one will be able to mention source of code which can be Git or Subversion. When you choose Subversion, you have to fill information like URL – link to your project in SVN, Credentials- used to checkout code from SVN, Checkout strategy- Can choose from various available strategies.                                                                                                                         
3. Build Triggers: Various options are available like trigger build remotely or schedule builds etc. For normal use, we can choose Poll SCM . The schedule here can be mentioned by using Cron Expressions                                                                                                                                                                                                                                                                                                              
4. Build Environment: This adds extra information to build like timestamp.                                                                                                                                                                                                                                                                                                                          
5. Build: This decides which technique is to be used for building the project like Ant script or Gradle script etc. For maven projects, we can define the maven goal and corresponding maven information as shown below                                                                                                                                                                                                                                                                                       
6. Post-build actions: This decides what to do when the build is ready. Suppose we have to send mail to group of people after every build, we can add their email addresses here as shown                              

Step 4: Once you apply the changes, on the home page you will be able to see the project you just configured                                                                                                                                  

Step 5: Monitor build: You will be able to see build history on left hand side of home page. If you click on particular build it will display the build logs.