Being able to get immediate feedback from new code is important. The faster you can get feedback the sooner a problem can be resolved and not find its way into production. One common way to get feedback is to run tests after the new code, but that naturally leads to other problems. When the code is compiling and tests are running, the developer can’t proceed with their work until the tests finish. Every development machine is a little different and that can result in inconsistent builds and test results.
Naturally, there must be a better way to get feedback about the new code. Jenkins is a solution to the problem by offering continuous integration capability. When new code gets merged, Jenkins can automatically do a build, run tests, and deploy the application.
This post will give you an overview of what is Jenkins and some of the pros and cons of using it.
What Is Jenkins?
Jenkins is an open source continuous integration (CI) server written in Java that can be self-hosted to automate the build cycle of any project. Jenkins provides CI services for a software project, which can be started via command line or web application server.
Continuous Integration
Before going into details about how Jenkins provides CI, I believe that it is important for you to understand what is CI. CI is a development practice in which developers integrate code into a shared repository several times a day. Tests run on a non-developer (tester) machine automatically when someone pushes new code into the shared repository.
The workflow of CI provides you fast feedback. If a change breaks a build you will know shortly after committing the code to a shared repository. The console also provides detailed log messages so you can identify what changes lead to the broken build. In addition, by using an artifact repository in the CI server you can deploy builds to other developers and testers.
Continuous Integration with Jenkins
Jenkins is heavily used in CI to allow code to build, deployed, and tested automatically. Let’s consider the situation where the complete source code of an application was built and then deployed on the test server for testing. It is an ideal way to develop software, but in practice, it is not practical. The developers will have to pause their work until they get the test results, which can take hours. The entire process is manual so there is a chance for human error(s), which can lead to time wasted.
Naturally, with the above scenario, it leads to slow software delivery and unhappy customers. This leads to a huge demand for a system to exist where developers can trigger the above process to happen automatically. This is where Jenkins comes in to fulfill the role in CI.
With Jenkins, you can hook it up to repositories such as Mercurial, SVN, Git, etc. So, all developers have to do is configure Jenkins to check the repositories periodically and when there is something new it will attempt to build, test, and deploy the new code. This help saves a massive amount of the developers’ time so they can focus on their work.
Pros of Using Jenkins
- Jenkins is open-source (free) and has a large community
- There are many plugins available that make Jenkins easier to use
- Jenkins is written in Java, which means it is portable
- Developers can spend more time elsewhere: Most of the integration and testing is managed by an automated build and testing system.
- Speeds up development: Most of the integration work is done automatically, which results in fewer integration issues. In the long run, this saves both time and money over the lifespan of the project.
- Higher quality software: Issues are detected early and resolved almost right away. This keeps the software in a state where it can be released at any time safely.
Cons of Using Jenkins
- Cost and Time: Jenkins must be run on a server (cost) and often needs the attention of a system admin (time). You can’t expect to set up Jenkins and then have it run itself. The system will require frequent updates and maintenance.
- Requires some investment to start using: Some main barriers that most teams encounter is the initial setup, procrastination, or failed previous attempts to set up Jenkins. Many teams understand that it is best practice, but will neglect it for more urgent coding work. If Jenkins was implemented in the past but was not successfully maintained then all you get is wasted effort as well.
- Tests can break: Tests can break and that requires updating. If they are not updated then those tests stop delivering value.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
Does your team use Jenkins for CI? How has having a dedicated CI server running Jenkins help you and or your team?
To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.