How do you deploy Allure TestOps in your environment
Please read this section from top to down before you do anything.
All the actions are to be performed in a console application. No Web UI or Desktop applications UI is used.
To be able to deploy Allure TestOps in your testing or production environment you need the following:
Dedicated Virtual machine, or bare metal server, or Kubernetes cluster.
We strongly recommend avoiding Windows family OS.
If you have no choice, please use WSL2 with Ubuntu.
We strongly recommend avoiding the installation on a personal PC for the system is designed to process a lot of data and the resources on you local personal PC won't be enough system to operate properly.
We strongly recommend using Kubernetes deployment, or deployment on a bare metal machine using packages if your planned workload is more than 3000 test results per a test run.
We strongly recommend using docker-compose only for a deployment for trial purposes or for the cases when it is deployed for a small team and small amount of test results per a test run (less than 3000 test results).
Knowledge and skills
To perform successful deployment of Allure TestOps in your environment you'll need the following knowledge and skills:
Basic knowledge of a Linux family OS and its console commands if you plan to deploy Allure TestOps using packages.
Basic understanding and knowledge of Docker and docker compose commands if you plan to deploy Allure TestOps using docker compose.
Basic understanding of Kubernetes and kubectl commands if you plan to deploy Allure TestOps using Kubernetes.
Allure TestOps has a web-interface supporting comfortable work using most recent releases of modern browsers, such as:
Microsoft's Edge (chromium engine)
Opera (chromium engine)
The work with the other browsers should be possible in most cases but is not guaranteed.
Work with any version of Internet Explorer is not guaranteed.
Allure TestOps uses micro-services architecture approach and has following main blocks:
Gateway is the WEB-UI component of Allure TestOps.
UAA is the user management and license management component.
Report is the heart of Allure TestOps processing all the stuff related to the tests.
PostgreSQL database version no less than 14 is required for all new installations and release upgrades as of the 1st January 2023.
PostgreSQL database ver. 12 support is discontinued by the 31st of December 2022.
PostgreSQL database ver. 11 support is discontinued by the 31st of December 2021.
PostgreSQL database ver. 9 support is discontinued by the 28th of August 2021.
DB storage size requirements
Based on our experience 100 000 of test results daily will result in 300 GB of data in PostgreSQL database over a 1 year period.
This is a very (very) rough estimation and the real DB size will depend on the amount of data you are sending from your tests.
Parameters of the database
For the best performance, the database which will store Allure Testops data, need to use enterprise grade SSD for storage.
In case of usage of enterprise SSD (or similar by IOPS) as storage for your PostgreSQL database it is highly recommended to use next custom value for parameter:
random_page_cost = 1.5
The random_page_cost parameter is to be added
to main config file like postgres.conf in case of on-premise database.
to appropriate parameter group that are used for your RDS instance in case of AWS RDS usage.
For the parameter to be applied the database requires restarting.
This parameter has default value equal to 4.0 which aligned with the performance of common enterprise HDD (not SSD).
Recommendations for Allure TestOps production system deployment
All the examples you will find in the documentation pages describing the deployment options are good for the proof of concept stages, i.e. for the cases when the number of tests results you will sent to the system is not really big, and if your Allure TestOps' endpoint is exposed to your intranet only. For the deployment in the production we strongly recommend considering the following.
Network parameters - Reverse proxy parameters
client_max_body_size - parameter of the reverse proxy should be set to several hundreds of megabytes to allow transferring the test results (which are being sent in batches); this will prevent the loss of test results due to reverse proxy policies. We recommend setting this parameter at least to 300 megabytes.
proxy_read_timeout - defines the time to wait for the response from a server. Sometimes the default value of this parameter could break the test results transfer to the Allure TestOps server. We recommend to set this parameter to the value equal to 300
Network parameters - ingress / istio timeouts
Timeouts should be set at least 60 seconds to prevent sessions breaks and 50X errors.
S3 for test results storage
It's highly recommended to use S3 bucket to store test results artifacts.
Additional settings for report container should be added to use it (refer to specific deployment type).
Currently, the following options for Allure TestOps deployment are officially supported: