OutSystems Professional DevOps Engineer study materials
OutSystems Professional DevOps Engineer study resources

OutSystems Professional DevOps Engineer: Continuous Integration and Delivery (CI/CD) Pipelines

OutSystems Professional DevOps Engineer · Work through your exam, one topic at a time.

All guide sections

Continuous Integration and Delivery (CI/CD) Pipelines

What this domain tests

The CI/CD domain tests your ability to automate promotion of OutSystems applications through LifeTime, not just press 1-Click Publish. You need to know how tagged versions, solutions, deployment plans, and the LifeTime REST API v2 fit into a repeatable pipeline.

Core rules

  • A tagged version in Development is the immutable source for a cross-environment deployment; everyday 1-Click Publish changes the Development version but does not promote it.
  • A solution is the unit that carries an application and its dependencies. LifeTime computes a deployment plan from the source and target environments; the plan validates, compiles, and deploys.
  • Automate with the LifeTime API v2 using a dedicated service account. Create a deployment to the target environment, capture the returned deployment identifier, then poll the deployment status endpoint. Deployment is asynchronous, so a pipeline must wait for a terminal state before running tests.
  • Keep stages explicit: build/tag in Development, deploy to Quality, run automated tests, then deploy the same tagged version to Production. Do not rebuild between stages.
  • Treat the deployment plan result as a gate: stop on validation errors or dependency conflicts instead of forcing a deploy.

Worked example

A nightly pipeline tags application Orders as 2025.06.1 in Development. It calls the LifeTime API to deploy that version to Quality. The first call returns a deployment identifier, but the pipeline immediately runs UI tests and fails because the deployment is still compiling. The fix is to poll status until succeeded, then run tests, then promote the same version to Production. If the plan reports a missing dependency, the pipeline should fail and alert rather than deploy.

Traps

Assuming deployment is synchronous; deploying from Development straight to Production; using a personal account; skipping plan validation; putting credentials in pipeline logs; and rebuilding a new version for Production instead of promoting the tested tagged version.