Appearance
UAT Environment
The User Acceptance Testing (UAT) environment is where clients and product stakeholders validate features against production-equivalent data and configuration before a production release is approved. It is the final human gate before production.
Environment Snapshot
| Property | Value |
|---|---|
| Environment name | uat |
| VNet CIDR | 10.5.0.0/16 |
| Domain | microtec-uat.com |
| Key Vault | mic-erp-uat-kv |
| ACR | micerpbeuatacr |
| Branch trigger | Manual pipeline run only |
| Approval gate | Required — Product Owner approval before deployment |
| SLA | 99% availability during business hours |
Subnets
| Subnet | CIDR | Hosts |
|---|---|---|
| Public (CAE) | 10.5.1.0/24 | Gateway, Keycloak |
| Private (CAE) | 10.5.2.0/23 | All backend microservices |
| App Service | 10.5.4.0/24 | App Service integration |
| Function Apps | 10.5.5.0/24 | Function App integration |
| Private Endpoints | 10.5.6.0/24 | PaaS private endpoints (SQL, Redis, etc.) |
Purpose
UAT serves three distinct audiences:
1. Client Acceptance
Customers validate new features in an environment that mirrors production behaviour. They use real-looking (anonymised) data, real Keycloak authentication, and the full ERP feature set. Issues found in UAT are treated as production-equivalent bugs.
2. Product Owner Sign-off
Before any release to production, the Product Owner must approve the deployment in Azure DevOps. This approval is tracked as a required check gate on the uat environment in the pipeline.
3. Regulatory and Audit Review
For Saudi E-Invoicing (Zatca) compliance, Finance and compliance staff review Zatca integration behaviour in UAT before certifying a production release. UAT uses the Zatca simulation environment, not the live compliance API.
Deployment Gate
UAT Requires Manual Approval
UAT deployments do not trigger automatically from a branch push. The deployment pipeline requires:
- Successful completion of all 16 DevSecOps stages in preprod
- Explicit manual trigger of the UAT deployment stage
- Approval in Azure DevOps by a designated Product Owner
- Sign-off recorded in the release notes ticket
Without all four steps, the deployment is blocked.
The approval is configured in Azure DevOps under Environments → uat → Approvals and checks:
Approvers: [Product Owner Group]
Timeout: 72 hours (auto-reject if not approved)
Notification: Email + Teams channel #releasesKey Infrastructure Resources
Container App Environments
| CAE | Name | Apps |
|---|---|---|
| Public | mic-erp-be-uat-cae-public | Gateway, Keycloak |
| Private | mic-erp-be-uat-cae-private | All other microservices |
Key Vault
Key Vault name: mic-erp-uat-kv
| KV Secret Name | Description |
|---|---|
ConnectionStrings--DefaultConnection | Admin DB connection string |
RedisConfiguration--Password | Redis SSL password |
Jwt--Secret | JWT signing key |
XApiKey | Internal service API key |
Zatca--SimulationApiKey | Zatca simulation environment API key |
Redis
| Property | Value |
|---|---|
| Hostname | mic-erp-be-uat-redis.uksouth.redis.azure.net |
| Port | 10000 (SSL) |
| SKU | Balanced_B0 (Azure Managed Redis) |
Domain and TLS
| Service | URL |
|---|---|
| API Gateway | https://gateway.microtec-uat.com |
| Keycloak | https://auth.microtec-uat.com |
| Business Owner Portal | https://bo.microtec-uat.com |
| ERP Frontend | https://erp.microtec-uat.com |
Data Policy
Anonymised Production Data
UAT uses anonymised snapshots of production data, refreshed before each major release cycle. The refresh process:
- Export tenant databases from production (SQL backup)
- Run the anonymisation script (
devops/scripts/Anonymize-TenantData.ps1) to scramble personal data fields - Restore anonymised databases to the UAT SQL instance
Real names, phone numbers, national IDs, and financial account numbers are replaced with synthetic data. Transaction amounts and structures are preserved for realistic testing.
Do not manually enter real customer data into UAT. UAT databases are considered non-production but are still handled under data governance policies.
Who Has Access
| Role | Access Level |
|---|---|
| Product Owners | Full ERP access (UAT-specific user accounts) |
| QA engineers | Full access for acceptance test execution |
| Client representatives | Scoped access — tenant-specific, read-only finance data |
| Developers | Read-only (no code deployment rights — pipeline only) |
| DevOps engineers | Full infrastructure access via Azure portal |
Client accounts are created in the microtec Keycloak realm on auth.microtec-uat.com under a dedicated UAT group with scoped permissions.
Release Checklist
Before requesting UAT deployment approval, the release team must complete:
- [ ] All automated tests pass in preprod
- [ ] Release notes written and linked in the deployment ticket
- [ ] Data anonymisation refresh completed (if data model changed)
- [ ] Zatca simulation tests executed (if Zatca changes included)
- [ ] Performance baseline comparison vs previous UAT release
- [ ] Rollback plan documented in the deployment ticket
Monitoring
| Tool | Details |
|---|---|
| Application Insights | mic-erp-be-uat-ai |
Log level: Information. UAT alerts are sent to the #uat-alerts Teams channel and to the QA team lead's email.
Seq Not Available in UAT
Seq structured log streaming is only available in the local dev environment. UAT sends telemetry to Application Insights.
Rollback Procedure
If a UAT deployment causes critical issues:
- Identify the last working image tag from the pipeline run history
- Update the Container App revision to the previous image tag:
bash
az containerapp update \
--name mic-accounting \
--resource-group mic-erp-be-uat-apps-private-rg \
--image "micerpbeuatacr.azurecr.io/accounting:<previous-build-id>"- Notify the Product Owner and client contact via Teams
- File a P1 bug with reproduction steps before re-deploying