In this final installment of “Slaying The Hydra”, I discuss modifications that can easily be made to the suite for scalability, based on the resources available.
Additionally, I provide an overview on how we can expand and improve on the ideologies introduced in this series for a future series.
Run Time Parameters
In our example we only have one parameter browser specifying whether we want to run the test automation in a Chrome or IE browser. In enterprise test automation frameworks, the run time parameters included are often more exhaustive, allowing for more dynamic usage of the suite.
To modify the suite for additional run time parameters, we first modify the parameters of the Jenkins Pipeline job itself by selecting ‘Add Parameter‘ and then configure the meter to fit our needs.
Additionally we modify the build job portions of our pipeline to pass the parameter selected in the pipeline job to the build of the test_runner job. This is done by expanding the parameters to include whatever additional values we want to pass into the test_runner job (note: the browser value is returned via params.browser).
Lastly, within the test_runner job we modify the input parameter, in so, the value from the Jenkinsfile is passed successfully to the build of the job.
Additional Executors and Machines
The really nice thing about this suite and the related code is the ability to execute equally well with 20 tests split between 2 executors, or 2000 tests split between 20 executors.
If we want to increase the number of executors utilized we complete the following steps:
Step One: Pipeline Changes
First, we increase the parallel portion of the pipeline to equal the number of executors you have available. For every new portion, ensure the build_number and total_builds values are updated and accurate values.
In the pipeline, the parameters for the report_consolidation job in the consolidation stage will need to be modified to include the build_number parameters for each machine_consolidation job executed.
Step Two: Node Changes
If the executor is a machine not connected to Jenkins, I would reference this Linux Academy post for connecting the machine to Jenkins.
In our test_runner job we have specified @local as the tag to locate when finding nodes that can run a build of this job.
Therefore, we navigate Manage Jenkins > Manage Nodes > Corresponding Node and set the Labels value to @local.
One note, a singular machine in some cases will be able to handle multiple executions on its own. For example, if you are running remote web browsers via a cloud partner, a singular machine will be able to execute multiple instances of the framework without risk of impacting other tests because the browser is remote.
In this case we could alter the # of executors value in Manage Jenkins > Manage Nodes > Corresponding Node.
Step Three: Job Changes
In our clear_workspace job and our workspace_consolidation job within the node parameter we have to include the additional node as a default nodes option.
If this step is skipped from the clear_workspace job, you will see confusing results since the locations that consolidate testing results on the newly added node(s) would never get cleared out and retain the data from previous test executions.
If this step is skipped from workspace_consolidation job, the results from the execution jobs executed on that machine would not be included in reporting.
Additionally in the report_consolidation job, the parameters would be modified to include all parameters passed in from the pipeline representing all of the runs of the workspace_consolidation job.
This concludes the parallel test automation utilizing single threaded execution nodes. If you have questions or issues when attempting to set this up, don’t hesitate to reach out.
The logical place from here is to create an example completing the same sort of parallelization utilizing Docker. This will allow us to complete similar work, without as heavy of an overhead, and we can add some containerization experience to our belts.