Define with Test Platform team about the usage of Release Environment in QA's workflow
We use Release Environment for validating stable branches, and with this use case, Test Platform is our direct customer - they need to know the status of the pipeline and take action accordingly.
According to the epic, the Release Environment aims to provide:
- Bring more confidence about our releasing process, that the backports were tested against a running environment that is as close to production as possible, thus deliver more stable patch releases to the customers.
- A long-lived environment for each minor version inside the maintenance policy, that we can deploy a new backport to immediately once it is available.
- Ability to spin up any out of support GitLab minor versions in case of out of policy backport requests.
- Provide GitLab environments where teams can access and debug issues, without manually set up on local machine, thus lower the lead time of backport requests.
From what we know, Test Platform uses channels like "#qa-production" and "qa-staging" to know about the result of QA pipelines. Delivery and QA need to agree on:
- What does Test Platform expect from Release Environment in validating new commits in stable branches? (I think it is the same as on
.com
, just that now Test Platform doesn't need to run the tests locally but has it automatically) - How to notify Test Platform about the result of release environment pipelines (e.g. which Slack channel to use)
- How to implement the notification?
Exit Criteria
-
Contact, discuss and agree with Test Platform about the above questions -
Create issues accordingly
Out of Scope
- Actual implementation of notification channels. It should be done by #19999.
Edited by Dat Tang