Jenkins is a continuous integration server. That means it provides several tools to significantly enhance code quality. I have been both a Jenkins administrator and a Jenkins user. I have also acted as both a manager and as an engineer using Jenkins. Let’s look at how Jenkins improves code quality from both the management and engineering role.
Using Jenins as an Engineer
As an engineer, I care about several things with my codebase. I care about my unit tests passing (and other commits to the code not breaking my unit tests). I want to know when my code doesn’t compile. I also want to verify it works in a separate environment (that I don’t have specific tools on my system that aren’t present in another system, preventing it from working).
Every time someone makes a commit to source control, Jenkins can automatically trigger a job to begin.
That job can do the following (along with many other things):
- Build the code
- Run unit or system tests against the code
- Package up the code for deployment purposes
- Even deploy it, if you wish
Building the code and running tests against it on every commit really helps my code quality. I can verify every time a change is made against the code, the code both compiles and passes a set of tests.
If something fails, I know between two versions of code what caused the failure. This greatly limits the scope of finding the bug, which makes me much more efficient in tracking down issues. I also probably know who to ask for help based on the finding out who made those changes (by looking at my source code repository’s history).
Over time, I will be interested in seeing how much of my code is exercised by tests. In that case, I can look at code coverage to determine how well the code is tested. Simple tools like GCOV/LCOV for C/C++ and coverage for Python show exactly which lines have been executed and which have been skipped.
Over time, I can add more and more test coverage. I may add system tests also in order to exercise code that is mocked out in my unit tests.
If I have enough confidence in my tests, I might automatically deploy my code on every commit. These means if all my tests pass, I expect my code to operationally meet all the requirements. No further manual testing is needed. This is an awesome place to be.
It all starts with automating processes on every code change. This really drives the point home. You must always keep the code building. It must always pass the tests. If it doesn’t, Jenkins will notify you via email. And it’s up to the team to immediately fix those issues before moving on to other features.
Using Jenkins as a Manager
Suppose you want to get a high-level view of your code quality. You have several different projects to manage, so you don’t have the time to devote to any one project that an engineer has. You need high-level details, and you need them quickly.
Jenkins has the ability to group projects together into one big-picture view using a plugin called “Build Monitor Plugin”. From one URL, you can view the status on multiple projects (either green for passing or red for failing… or perhaps yellow for some other warning status) all in one view. You can view screenshots of this plugin from the Build Monitor Plugin description page. This can be done in addition to receiving emails each time a project fails the build.
In addition, you can also get high-level views of test trends for each project.
For example, the above picture shows both the number of tests with each build (top graph) as well as the code coverage trend (bottom graph).
We can see that the tests have been increasing from build 10 to build 12. Increasing tests is generally a good sign. In addition, we can see that the line coverage and conditional coverage has increased in the most recent builds. This means the developers are doing a good job of continually increasing the code coverage through automated testing.
As a manager, I can assume that code quality increases as test coverage increases (assuming your team isn’t adding bogus tests, which would be a separate issue to resolve). By checking the Jenkins status page for the projects I am interested in, I can quickly determine the code coverage and build status of relevant projects.
If I see a project isn’t building or passing tests, I can make sure the appropriate people start looking into it. This all happens with every build. Emails can also ensure I don’t miss a build breakage.
Jenkins can help increase code quality both as a manager and as a developer. The ability to run some task every single time code gets committed is huge. This narrows the scope when problems creep into the code. It also keeps everybody accountable. Everyone can immediately tell the status of a project as far as how well it is tested and it’s current build status.
If you aren’t using Jenkins today to help with code quality or just simply reporting status, you are missing an opportunity to make your team/company more efficient. Start using it!