The QA Environment for the Authentication and Authorization service provides the same set of features as the production services. It is a pre-release version of our service, where the latest features will be included so that they can be tested and validated before a final release.
This can be useful for different purposes:
- For test and development: you can create test applications and resources without polluting the production portals, while having all the latest features already available.
- For a safer integration: before we make any new release, we will apply all the new changes in the QA environment. If you have a copy of your service pointing to QA, we will be able to notice if any change causes problems.
This change control process will sound familiar to those who know about the QA Process for Agile Infrastructure (AI) at CERN (Puppet). If your service is configured with Puppet, you will probably have a QA environment already. We highly recommend configuring all of your QA instances with the QA SSO, Portals and APIs.
Accounts and synchronization
QA uses different databases and it is not synchronized with production, so some information could not match. This is especially true for:
- Multifactor credentials.
- External users.
- Account linking.
- GRAPPA master groups and memberships.
- Applications and roles.
CERN accounts and their passwords work identically in QA and production. You can add a new entry to your Authenticator App for QA or use the same security key when registering multifactor credentials.
Where are the QA servers?
You can find the links in the list of service instances.
About Config Release Management (CRM)
Even if our QA process has similarities with the AI one, we won't create a CRM ticket in JIRA unless it involves a shared Puppet module (some modules like
cernsso_apache are maintained by our team). If you want to follow up our QA and release announcements, please join our Mattermost channel.