A QA environment that is also the UAT stage
Northwind Logistics runs OutSystems 11 with a LifeTime controller and three environments: Development (DEV), Quality (QA), and Production (PROD). The company has 48 developers across nine teams. Business analysts and 30 UAT testers use QA for acceptance testing from Monday to Wednesday each week. Teams deploy to QA whenever a user story is ready, sometimes 15 times a day. The single QA front-end server has 8 vCPU and 16 GB RAM; PROD has two front-ends and a dedicated database. Last month, UAT was blocked four times by half-finished deployments, and one release reached PROD with a regression that QA had not tested because testers were validating a different build. LifeTime has no separate pre-production environment. The CTO will approve at most one new environment. Describe what you would change and why.
1. Recommend an environment model and promotion path. Justify each environment's purpose and who owns it.
Read the worked answer
Add a single PREPROD environment and split responsibilities by risk rather than by team. DEV stays a shared integration space where teams deploy continuously. QA becomes the automated regression and integration-test stage, owned by engineering, with a fixed promotion gate: only a release candidate built from a tagged commit may enter. PREPROD becomes the UAT and release-rehearsal environment, owned by the release manager and used by business testers. PROD remains change-controlled. The key reasoning is that QA currently has two incompatible jobs: rapid integration and controlled acceptance testing. A new environment only helps if promotion rules change; otherwise testers will still see half-finished builds. Define a weekly release candidate, freeze QA for that candidate on Thursday, promote the same tagged solution to PREPROD for UAT, then to PROD after sign-off. Keep environment differences in configuration parameters, not in code. Document owners, entry and exit criteria, and a calendar visible to all nine teams.
2. How would you handle an urgent production hotfix that cannot wait for the weekly UAT window?
Read the worked answer
Use an emergency change path, but do not skip verification. Create a hotfix branch from the PROD tag, fix, and deploy to QA for an automated smoke test plus a focused regression script agreed with the business. Promote the same tagged solution to PREPROD, run the critical order path and a database compatibility check, then deploy to PROD in a pre-agreed emergency window. Require a named approver, a risk statement, a rollback plan comprising the previous tag and a database snapshot, and a monitoring watch for at least one hour. Notify the service desk and business owner before deployment. If the fix touches the schema, apply the expand/contract pattern so the old version still works during the window. Run a post-implementation review within 48 hours and feed any missed test into the regression suite. The reasoning: the risk of an untested hotfix is usually higher than a short delay, so a real but compressed verification path preserves safety without waiting for the weekly UAT cycle.
3. What operational controls would you put in place to stop untested builds reaching PROD?
Read the worked answer
Make the tagged release the only deployable unit. In LifeTime, restrict deploy permissions by team and environment, require an approved deployment plan, and lock QA during UAT so only the release candidate can be promoted. Add automated smoke tests that run on every QA deployment and block promotion on failure. Introduce a release checklist: impact analysis reviewed, database changes rehearsed on a production-sized copy, rollback plan attached, and UAT sign-off recorded against the tag. Use LifeTime's deployment approval and audit trail as evidence, and publish a change calendar with a freeze window before PROD releases. Measure two things: the percentage of PROD deployments that came from a UAT-signed tag, and escaped defects per release. Review monthly with the CTO. The reasoning is that environment topology alone does not prevent untested builds; the control point is the promotion gate and the evidence attached to it.