Safeguarding Quality Using Jenkins

Once set up, Jenkins is like a butler, saving the developers from endlessly repeating manual tests.

Background: The company I work for started in 1880 in Belgium. It was the beginning of the industrial revolution and the company specialized in industrial process machinery servicing. Today we imagine, build and integrate innovative textile systems for flooring qualities, home linen, fashion fabrics, and technical textiles: from yarn to finished product.  When it comes to developing and delivering software, our suite of unit tests was only run manually when a developer was up to it. That’s a roadblock. Also just ensuring that builds succeeded for different platforms was a challenge because of the laborious setup that some platforms require.

Goals: The primary goal for this project was to safeguard the quality of releases for all future projects.

"Jenkins deals with all the repetitive things that would only distract developers from the real work."

Koen Poppe, Project Engineer / Software

Solution & Results:  We have automated tests that are run with every push in every branch. It notifies users when something is broken and lessens the burden of running tests manually, i.e., before a merge to ensure all is still fine. Also, while developing, we can focus on the tests for the classes under focus, knowing that Jenkins will run the entire suite and notify you when something in a distant dependency breaks or needs alignment.

Having Jenkins configured to run the tests and build the product for all the supported platforms makes it really convenient so developers can work on the software without the need to do these repetitive tasks manually. Once set up, Jenkins is like a butler: trustworthy and invisible up until something goes wrong.

Here are the key components of this project:

• Support for fully custom Linux scripts to automate some very custom steps in the build process.

• Support for source control systems out of the box, Mercurial in our case, but also older systems like SVN.

• Multi-branch projects: set up the build once and replicate it for every new branch in the project. I can’t imagine doing this manually. Also, shared pipeline libraries make it easier to repeat the same build steps for similar projects, reducing the setup scripts to only that specific to the project.

• Build monitor: an overview of all projects with an indication of what is working and what is not. We have a separate screen in the office that shows this permanently, making it visible to our team and colleagues from other departments so all can see how our process is going.

The results were amazing:

• Tests are run automated for all branches, ensuring regressions are detected early.

• Products are built for all configurations without the need for a developer to do the setup.

• Precious developer’s time is kept for developing, not for endlessly repeating tests manually.

• The build monitor screen is shown in the office, making it extra visible how the health of the software is.