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