Environment Management and Deployment
What this domain tests
Environment management covers how OutSystems separates Development, Quality, and Production, how LifeTime orchestrates cross-environment deployment, and how dependencies, configuration, and database changes behave when an application moves.
Core rules
- Each environment has its own Platform Server, platform database, and Deployment Controller. LifeTime is the cross-environment management console; Service Center administers one environment.
- Cross-environment deployment starts from a tagged version and produces a deployment plan. The plan lists modules, dependencies, compile steps, and database upgrades. OutSystems applies schema changes automatically, but it does not copy business data between environments.
- Dependencies must already exist in the target environment or be included in the solution. A missing extension, module, or producer blocks the plan.
- Promote the same tagged version through the chain; do not republish in Development and expect Quality to update.
- Check impact and timing: database upgrades can require downtime, so schedule production deployments in a window and confirm the plan's warnings.
Worked example
You tag a solution containing Orders and OrdersAPI for Production. The plan fails because OrdersAPI references an extension that exists in Quality but not Production. The correct fix is to deploy the extension, or a solution containing it, to Production first, then re-run the plan for the same tagged version. Do not delete the reference or publish from Service Studio in Production, because that bypasses LifeTime governance and leaves the environments inconsistent.
Traps
Thinking 1-Click Publish promotes to other environments; forgetting that data is not migrated; ignoring dependency order; deploying during peak hours without checking database upgrade impact; assuming a failed plan can be forced safely; and editing Production directly in Service Studio.