OutSystems Professional DevOps Engineer study plan

OutSystems Professional DevOps Engineer · Give each week a clear focus.

8 weeks · About 7 hours per week

Week 1

Continuous Integration and Delivery (CI/CD) Pipelines

Map the lifecycle of an OutSystems application from Development through Quality and Production, listing which environment-specific configurations must differ at each stage
Trace how a deployment plan is generated in LifeTime and identify which dependencies (modules, extensions, site properties) force ordering constraints
Configure a sample application's deployment plan with manual vs automatic deployment and document the effect of each choice on a release cadence
Write down the distinction between a deployment plan, a solution, and a revision, using your own application as the example

A one-page reference diagram of the Dev-to-Prod pipeline for your sample app, annotated with the configuration items that change per environment

Week 2

Build a repeatable CI workflow that validates a solution before it reaches Quality, using the available OutSystems command-line and LifeTime APIs
Automate the creation of a deployment plan via API and capture the returned plan key for downstream steps
Introduce an automated code-quality gate (e.g., forbidden patterns, unused references, or architecture dashboard thresholds) and fail the build when it is breached
Version your pipeline scripts in source control and tag a release candidate

A working pipeline script repository that takes a solution from commit to a Quality deployment plan without manual clicks

Week 3

Deploy the same release candidate to a second environment using the stored plan key and record every manual intervention required
Compare deployment outcomes when using automatic vs manual plan generation and note which is safer for hotfixes
Identify how OutSystems handles module-level changes that require a full recompile versus incremental publish
Document rollback options available after a failed deployment and test at least one

A deployment runbook covering promotion, hotfix, and rollback for your sample app, validated by an actual second-environment deployment

Week 4

Classify the environment types in a typical OutSystems landscape and justify where a pre-production or staging environment belongs
Configure environment-level settings (site properties, security settings, email, integrations) per stage and verify they are not overwritten on deploy
Explain how LifeTime synchronizes environments and what happens when a deployment targets an environment that is out of sync
Design a multi-team landscape where two development environments feed one Quality stage without conflicting

An environment topology proposal for a two-team organization, including sync strategy, configuration matrix, and conflict-resolution rules

Week 5

Enumerate the monitoring surfaces available (LifeTime dashboards, service center logs, platform database, application logs) and state what each is best at answering
Set up an alert for a failing deployment and an alert for an error-rate threshold, then trigger each deliberately
Read an error log entry and trace it back to the module, screen, or integration call that produced it
Measure the performance impact of a deployment by comparing response times before and after

A monitoring checklist that maps each common failure symptom to the specific dashboard, log, or query used to diagnose it

Week 6

Diagnose a simulated production incident using only logs and dashboards, and write the timeline of your investigation
Distinguish between platform-level failures (LifeTime, deployment service, database) and application-level failures, and describe the escalation path for each
Audit who performed which deployment and configuration change using platform audit records
Define log retention and access requirements that satisfy both troubleshooting and governance needs

A post-incident report template plus a completed example based on your simulated incident, including root cause and preventive action

Week 7

Design a role model across Development, Quality, and Production that enforces least privilege for deployment and configuration changes
Configure IT user permissions and team-level roles so that a developer cannot deploy to Production unassisted
Enforce a segregation-of-duties rule where the person who builds a release is not the person who approves it
Review how secrets and integration credentials should be stored per environment and identify where they must never live

A governance matrix mapping each role to permitted actions per environment, with the approval gates explicitly marked

Week 8

Run a full release rehearsal end to end: commit, validate, promote, monitor, and roll back, timing each stage
Verify that audit records, alerts, and logs from the rehearsal satisfy the governance matrix defined in week 7
Consolidate weak areas from prior weeks into a targeted review list and close each gap with a hands-on exercise
Write a personal operations checklist for the first 30 days in a DevOps role on this platform

A timed end-to-end rehearsal report with stage durations, gaps found, and a finalized personal operations checklist

Week 2: You can generate and store a deployment plan through automation without touching the LifeTime interface

Week 4: The same release candidate has been deployed to two environments with no manual configuration drift

Week 6: You have diagnosed a simulated incident from logs alone and produced a root-cause statement

Week 8: A full rehearsal completes within your target window, with audit and alerting evidence attached