How to setup a 2016 Windows Server with multiple concurrent execution workers | Agilitest blog

Some time ago, we shared with you our vision regarding the massive execution of Agilitest tests on a production environment. In this article, we will present a step-by-step method to achieve this goal. Antoine de Saint-Exupéry said: “ Any objective without a plan is just a wish”. Well, here is our plan.

Global context

The Windows server

For the purpose of this article, we installed a 2016 Windows Server. This is a common enterprise version, but the 2019 version works as well, as both share the same kernel as Windows 10.

This server is a virtualized VM with Linux KVM, and the hypervisor server itself is hosted in a datacenter. All configuration operations are done via Remote Desktop with the RDP protocol.

During the installation, we deliberately checked the “ Windows Server 2016 Standard (User Experience)” version with a graphical environment. Firstly to facilitate administration operations, but mainly because most of the ATS tests generated with Agilitest require a desktop environment.

Two user accounts were created: worker1 and worker2.

Installing Agilitest

Agilitest was installed on the server from the Administrator session in C:\Program Files (x86\Agilitest. This installation is global for all users, and everyone will find an Agilitest shortcut on their desktop.
On the other hand, the dependencies and configuration files are specific to each user concerning the two folders below:

  • C:\Users\Administrator\.actiontestscript
  • C:\Users\Administrator\.agilitest

The same folders will be created for the worker1 and worker2 users automatically, during the first Jenkins build. It is thus possible to have a particular configuration of the software for each user. For example, it is possible to modify the version of the Chrome or Firefox browser that will be used by the worker1 user by modifying the file C:\Users\worker1\.actiontestscript\.atsProperties.

You can find more information on the official actiontestscript page on GitHub.

Installation of Jenkins

Service or user command line

Here Jenkins has been installed from the .msi installer for Windows. This installer offers to set up an independent Windows service, which we did (Login type: run service as local or domain user) with the user Administrator.

It is interesting to note that the Java package jenkins.war can later be run as a service or as a command line from a user session with desktop environment.

It is also important to mention that the way Jenkins is launched will have implications on the ATS builds that are executed. In service mode, running a test (e.g. Chrome web browser channel) will not generate any visible windows on the user session, which can be closed or locked, but the ATSV screenshots will be blank. In command line mode from a user session with a desktop environment, the test will generate visible windows on the user session, and the ATSV screenshots will work.

Anyway, it is recommended to run Jenkins as a service, and to run test suites with Jenkins Agents into user sessions with desktop environments. Jenkins agent can be stated at the opening of the session with shell:startup.

A tutorial in English on allowing a user account to run an executable as a service is available here. The steps to follow are as follows: Administrative Tools > Local Security Policy > Local Policies > User Rights Assignment > Logon as a Service (NT SERVICE\ALL SERVICES). The Administrator user has been added here.


The path to the Java JDK is requested by the installer. Java 52 (Java 8) or 55 (Java 11) are recommended by default but it is possible to use Java JDK 15 by adding the argument — enable-future-java in the Jenkins.xml configuration file.

The first connection to the Jenkins web back office requires entering a password contained in a text file. We then installed the recommended plugins.

At this point, the Windows Services Manager should allow the Jenkins service to be started and stopped. The auto-start type allows the service to start as soon as the server is started, even before a user logs on.

Our Jenkins installation was configured with the following points:

  • Installation of the Locale extension to force the language “en” regardless of the language requested by the browser.
  • Installation of the following Jenkins extensions: TestNG Results Plugin & Test Results Analyzer
  • Configure the path to git.exe (see article Using a Git repository as an Agilitest project source for Jenkins builds)
  • Add the label ats-executor in the menu Manage Jenkins > Manage Nodes and Clouds > Built-In Node > Configure.

In this type of configuration, be careful to perform a Commit and then a Push of your Agilitest project so that Jenkins can execute your updates.‍

No strings attached. Only good tests.
BONUS: the tests scenarios you create during your trial period can be replayed in ATS, our Open-Source backbone, for free and forever.

Originally published on Agilitest’ blog.

--

--

--

Codeless functional testing at scale is now a reality.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Making your first API callout from Mulesoft

Manjaro: first steps

Developing An Autonomous Racing Car: Interview With Roborace’s Chief Engineer

Jenkins and its Use-cases

Developers: Come build the printing press of tomorrow today at The Dallas Morning News.

YeeCo(YEE) Weekly Update

The A-Z Guide: When Mobile App Testing Is Done Right?

Blog 14 jelly bean

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Agilitest

Agilitest

Codeless functional testing at scale is now a reality.

More from Medium

How to use a Git repository as an Agilitest project source for Jenkins builds | Agilitest blog

How to Setup and run Cypress Test cases In Azure DevOps Pipeline

Creating Powerful Tests with Postman

Test Automation with Cypress for Beginners