A client had a bunch of Cucumber tests that ran from a Jenkins job. Running these took 90 minutes, even when spread across many nodes.
This was too long to get fast enough feedback, so it ran only a few times per day. And it wasn’t in sync with any developer check-ins either.
Here’s how this got analyzed and how run time got cut in half:
From Groups to a List
First, it happened that each test had a single node that it would run against. Each node was set to only let one test run at a time. This was to keep tests from affecting data being used by other tests.
The tests were all grouped together based on what node they ran on. This created the first problem. Some groups would complete faster than others, but then the node was sitting idle.
The first thing was to break the groups apart. All jobs were then kept in a long list, collected at startup.
Next, the Jenkins jobs got re-architected to run against any node.
By default, Jenkins picks the first available node to run against. Instead of a single node, each job was setup to check the entire list of known nodes.
The Maestro
Finally, the script mentioned earlier, that created the whole list of jobs, would pop jobs off the stack and execute them, until no more free nodes were available. Then it would wait until one was.
When a node was finished with a test, the next would start immediately–no waiting and no wasted nodes.
This cut execution time from 90 minutes down to 45 minutes.
Adding to the Pool
It then became easier to add nodes to run tests against. Even work laptops were used temporarily to run a Jenkins slave instance, and host tests. This helped the test suite to complete even faster. Execution time was as low as 30 minutes when using extra nodes in this way.
Fast feedback is crucial. Are your tests suites taking too long to execute? If so let’s talk. Schedule your free 15-minute discovery call here.
