Allure TestOps installation

How do you deploy Allure TestOps in your environment

Please read this section from top to down.

First of all, a little bit of architecture, then we’ll try to understand the HW requirements and finally - how do we install Allure TestOps

Architecture

Allure uses microservices architecture approach and has following main blocks:

  1. Gateway.
    • Gateway is the WEB-UI component of Allure TestOps.
  2. UAA.
    • UAA is the user management component of Allure TestOps.
  3. Report.
    • Report is the report controller of Allure TestOps.

There are also auxiliary blocks - Consul for non-Kubernetes installations, RabbitMQ. and MinIO

You can see here , how it all is tied together.

Allure TestOps HW requirements

Apple M1 CPU aren’t supported as these are laptop grade CPUs.

Allure TestOps minimal HW/VM parameters

Allure TestOps will definitely work with following HW/VM configuration:

CPU RAM Storage size Storage type
2vCPU 4GB 10 GB and more SSD

Recommended HW or virtual environment:

CPU RAM Storage size Storage type
4vCPU 8GB 50 GB and more SSD

DB storage size requirements

Based on our experience 100 000 of test runs daily will result in 300 GB of data in PostgreSQL database over a 1 year period.

Before you start - Recommendations for Allure TestOps production system

All the examples you will find in the 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. For the deployment in the production we strongly recommend the following:

Reverse proxy parameters

  • client_max_body_size parameter of the reverse proxy should be set to several hundreds of megabytes to allow transferring big attachments and prevent the loss of test results. We recommend to set it at least to 256 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 = 300

Database requirements

DB outside of docker container

In production the database should be pulled from a container and run separately as running in a container severely degrades the performance of the database with big amount of tests.

Postgres database version requirements

Postgres database version no less than 12 requires for all new installations.

Lowest supported version of Postgres database is the 11th, we’ll discontinue its support by the end of 2021.

Postgres database ver. 9 support is discontinued by the 28th of August 2021.

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).

Number of report containers

For big amount of test results for faster processing it’s recommended to scale up the number of report service instances which will also prevent the loss of the test results.

docker-compose scale report=N

where N is the target number of container with type report

Deployment types

Currently, the following options for Allure TestOps deployment are supported:

Option
docker-compose
Kubernetes
Packages

Integrations with the infrastructure

Integration Configured in Link
LDAP/AD for access management in uaa service Link
OpenId/OAuth2 for Kubernetes in gateway Consult with support first
S3 for docker-compose in report service Link
S3 for Kubernetes in report service Link
External DB for docker-compose in uaa and report Link
External DB for Kubernetes in uaa and report Link