Deployment and Release Management
Domain 3 focuses on LifeTime deployment mechanics and release discipline: plans, solutions, tags, validation, database synchronization, and rollback expectations. Expect scenario questions about promoting a change safely.
Core rules
- A deployment plan is built in LifeTime from a source environment to a target. It lists modules or applications; validation checks dependencies, compile errors, and target readiness before deployment.
- Solutions bundle applications for coordinated release. Deploy the solution when applications must move together; deploying individual modules can leave the target inconsistent.
- Deployment applies schema changes automatically to the target database, but data migration is not automatic. Use migration scripts or data-fix logic when existing rows need transformation.
- Tags are environment-specific markers of a deployed version. Deploying a tag promotes that exact version; it does not merge newer changes.
- Rollback is a redeploy of a previous tag, not a database undo. Schema additions and migrated data may remain, so design changes to be backward-compatible during the release window.
Worked example
A release adds a DiscountCode attribute to an Order entity and changes a Core action signature. QA is validated and tagged 2025.03. Prod deployment succeeds, but checkout errors appear. The team redeploys the prior tag 2025.02. Reasoning: the redeploy restores the old module code, but the DiscountCode column remains in the database; the old code ignores it, so service resumes. Any rows written with the new column must be handled separately. This is why backward-compatible schema changes matter.
Traps
- Assuming rollback removes schema changes or restores deleted data.
- Deploying a single module when a solution dependency changed.
- Skipping validation because it worked in Dev.
- Tagging after a failed production deployment.
- Forgetting that tags are per environment, not global branches.