The document describes the problem of needing to run test suites across multiple servers and the limitations of existing solutions. It introduces the Jenkins Multi-Configuration (Matrix) approach as a better solution. The Matrix allows test suites and servers to be defined as "axes" to automatically run all combinations in parallel, avoiding the need to manually maintain duplicate jobs as servers are added. This improves efficiency by completing all runs much faster when using multiple build agents with parallel executors.

1. Jenkins Multi-Configurations (Matrix)
I will start with describing the problem before going into the solution.
Let's say that you have a set of test suites that need to be ran over
multiple servers, each suite is a csv file including all tests (or keywords
in term of KDT - Keyword Driven Testing).
An easy solution can be by having one csv (with same format for all
servers) and one job for each server that is passing the server ip as
parameter to the test suite. The problem with this approach that when
come the time and your boss ask you to add more 10 servers since the
sales guys are doing a great job and more customers are keep coming
in... well, businesses is good but you have to keep maintaining and
duplicating your jobs all the time and adding new ones with the new
server IPs as parameter.
On top of that, instead of having one mail that aggregate all results and
send one mail you'll get tone of mails with the reports of all of these jobs
e.g.
Other approach is duplicating the same tests in one suite for multi-
systems and having the server ip as parameter passing it to the code. The
problem with this approach is that you still need to maintain the code by
keep adding more lines for each system what make them very long and

2. complicated, beside that all of these steps will need to be ran one after
other instead of running them in parallel. Still a bad solution.
e.g.
Well, you think that you have a good solution and go on with creating
Multi-Job for each system that contains the same jobs this time (no need
to duplicate) and pass the server IP within the multi-job itself. It sounds
better but still need to duplicate the multi-job for each new system
comes in.
So how to get rid of this overhead with keep maintaining jobs and code?
How to do it dynamically?
Here comes the solution of Multi-Configuration (or known by the name
Matrix). What you need to do is to provide your dimensions as axises, in
our example the csv will be one axis the server will be the other one.
That will create a Matrix that will seem like this:

3. We have in this matrix 21 different options (3x7). Assuming we have
one Jenkins slave that we can run on it 3 executors (to be ran in parallel)
dedicated for this job then each time 3 different jobs will be ran, and
assuming that we need 3 minutes to complete each 3 jobs then whole
jobs will be finished after 7 minutes.
But if we have 2 slaves (nodes) with same number of executers then the
whole job will ran in 3 minutes approximately.
And if we 3 slaves then the whole job will take about 1 minute only!
For technical details about how to achieve this please take a look at these
plugins:
https://wiki.jenkins-ci.org/display/JENKINS/Matrix+Project+Plugin
https://wiki.jenkins-
ci.org/display/JENKINS/Matrix+Combinations+Plugin