Reducing Software Automation Tool License Expenses by Minimizing License Requirements through CI Pipeline Development
Abstract
Currently, many IT organizations utilize licensed automation tools, but providing licenses to all QA and development personnel is impractical. Typically, licenses are allocated to designated automation engineers who create and run tests as needed. This creates a challenge in allowing any team member to execute tests as required. With most automation engineers located offshore, additional licenses would be needed for onshore test execution, which can be expensive. Furthermore, ensuring high code quality, adequate coverage, absence of code smells, and thorough security scans is crucial.
Introduction
Configuring a CI pipeline to invoke automation tests can help reduce license costs. CI tools sits in front of an automation test tools, eliminating the need for individual licenses. In this article, I demonstrate using GitHub Actions (GHA) as the CI tool. GHA is open-source but incurs costs based on runner usage. I propose an innovative solution to eliminate runner costs too. Additionally, integrating code quality tools like SonarQube and CodeQL into the pipeline ensures security scans and highlights issues before deployment.
Major advantages of implementing a CI pipeline-
1. No Automation tool user access is required for invoking tests
Automation tools that require licenses can only be used by licensed individuals. However, when integrated with a CI pipeline, any user with CI access can initiate jobs without needing a direct license. This approach optimizes the management of the license pool, reduces costs, and extends the tool’s utility for test automation. For instance, all developers with GitHub Actions (GHA) access can now invoke the automation tool without requiring individual licenses.
2. Eliminating requirement for QA resources to constantly oversee UI test execution on their desktops.
During UI test execution, some automation tools prevent testers/developers from navigating away from the UI screen, blocking them from performing other tasks on their computers. By utilizing the GitHub Actions (GHA) pipeline to invoke the automation tool, this restriction is removed, allowing developers and testers to work on other tasks while the automation runs in the background. After execution, an email with a detailed, user-friendly PDF test results report is sent.
Other Benefits of using GHA as CI/CD Tool for Automation Tests
1. GHA access free with user GitHub account
GitHub Actions is a GitHub feature that is by default enabled and hence no explicit access is required for GHA, it supports CI/CD workflows directly in your repositories.
2. Cost Savings — Eliminating AWS Infrastructure Cost
For CI/CD pipeline, we need to have a runner (virtual machine needed for running CI jobs) integrated which typically is provisioned in a cloud such as AWS incurring additional cost which grows as load increases. With this solution however, we are utilizing organization provided Win365 machines as runner and hence eliminating additional infrastructure runner cost incurred when using cloud services. All automation engineers are provided with Win365 machines for installing and executing automation scripts.
What is Win 365 machine ?
Windows 365 is a cloud-based computing solution that replicates the functionality of a desktop or laptop, seamlessly integrating your Office 365 applications and documents. With OneDrive integration, you can access your folders and files anytime. The platform also provides on-premises network connectivity from any device with an Internet connection, eliminating the need for a VPN.
Key Features
a. Act as Secondary Device
Employees rely on Windows 365 as a laboratory to test new software or scripts — without the risk of disrupting their primary device.
b. Enhanced Processing Power and keep running even if Primary Machines are disconnected.
These PCs are still up and running even if Primary device is disconnected. So if there are scheduled jobs connected to Win365 machines as runner, your code will be executed.
My idea is when we need a cloud instance but scalability is not required we should utilize VM machines if organizations have provided. To say in simple words, swap CICD pipeline runners from AWS instances to Win365 machines.
VM machines in my organization have been allocated to Automation team members for installing automation tools, which mirrors desktop and incurs fixed charges. QA resources use this cloud instance during daytime hours, leaving it free for the remaining 16 hours each business day. By leveraging these VMs as CI pipeline runners during this free time, we can significantly reduce AWS usage, eliminating the need to spin up new EC2 instances.
Below diagram depicts cost savings, here we are incurring fixed VM monthly cost $55 hence pipeline using these VMs will incur 0$ runner cost but if a new AWS instance was being used as runner we could have incurred 80$ monthly cost.
We’ve established CI pipelines for triggering automations tests, employing Win365 machines as execution platforms. Given that the operational expenses of Win365 machines are already covered, the execution of these CI pipelines does not incur any additional charges.
Additionally, we have devised an inventive solution to address load problems. We have observed sporadic AWS infrastructure failures caused by excessive load, but our workaround enables us to overcome these challenges.
Benefits achieved of swapping AWS instances with existing Win365 machines –
a. AWS cost reduction we won’t be require launching any new AWS EC2 instance resulting is cost savings.
b. 100% Utilization of Win365 machines as we are already incurring monthly charges for the Win365 machines, maximizing their usage to 100% would validate the costs.
3. Firewall Constraints and Automation tool Configurations
With GitHub being managed internally within organization network, we can avoid any firewall, Automation tool API permission issues which is a challenge with externally hosted CI/CD tools.
4. Code Quality Checks Implementation
In the CI pipeline itself we can implement CodeQL and SonarQube code quality tools avoiding any separate need of testing. CodeQL is a heavy tool in terms of time and takes lot of time for pipeline to be executed so it’s always recommended to trigger CodeQL in a separate pipeline and results can be viewed within Github itself.
Finally ,devops pipeline for deploying code and running automation tests against newly release cut branch will look like —
Hope you have enjoyed this article !!
