Allure TestOps deployment

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.

Prerequisites

Environment

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.
  • Basic understanding and knowledge of Docker and docker-compose commands.
  • Basic understanding of Kubernetes and kubectl commands.

Browsers compatibility

Allure TestOps has a web-interface supporting comfortable work using most recent releases of modern browsers, such as:

  • Google’s Chrome
  • Microsoft’s Edge (chromium engine)
  • Apple’s Safari
  • Mozilla’s FireFox
  • Opera (chromium engine)

The work with the other browsers should be possible but is not guaranteed, so it’s better if you use a browser from the list above.

Work with any version of Internet Explorer is not guaranteed.

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 processing all the stuff related to the tests.

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

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.

Minimum HW or virtual environment resources requirements:

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

However, the requirements above aren’t final; production system could require resources adjustment based on the workload profile.

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.

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 the following.

Users management settings

Before the production deployment of Allure TestOps, it is highly recommended to review the way the users are registered in the system, and use the following configuration parameters of UAA service to manage the system’s behaviour.

ALLURE_REGISTRATION_ENABLED: true/false
ALLURE_REGISTRATION_AUTOAPPROVE: true/false
ALLURE_REGISTRATION_DEFAULT_ROLE: ROLE_AUDITOR

ALLURE_REGISTRATION_ENABLED

Configuration parameter ALLURE_REGISTRATION_ENABLED allows enabling/disabling the registration of new users via web UI. It is mandatory to set this parameter to false if your Allure TestOps endpoint is exposed to the internet.

ALLURE_REGISTRATION_AUTOAPPROVE

Configuration parameter ALLURE_REGISTRATION_AUTOAPPROVE is used to manage the automatic approval of new users, i.e. the system’s administrator is to review the eligibility of a new user to access Allure TestOps. If there is no explicit approval received from the administrator (there is a checkbox in the u), the registered user won’t be able to access the system.

ALLURE_REGISTRATION_DEFAULT_ROLE

Configuration parameter ALLURE_REGISTRATION_DEFAULT_ROLE will assign the provided role to all newly registered users. We recommend ROLE_AUDITOR for this role has the minimal permission set and this role does not consume any license.

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 = 300

ingress / istio timeouts

Timeouts should be set at least to 60 seconds to prevent sessions breaks and 50X errors.

Database requirements

DB outside of docker container

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

Postgres database version requirements

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.

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

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
External Identity providers in gateway Link
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
SMTP server for UAA for passwords reset in uaa Link