3.1 Control Plane vs Agent Execution Plane
3.2 Project Scope Model
3.3 Data Flow: Source -> Release -> Pipeline -> Logs/Artifacts
3.4 Runtime Configuration Layers (global / project / environment)
3.5 Pipeline Execution Semantics
3.6 Release Governance Path
3.7 Rollback Architecture (Policy-driven)
3.8 Security and Trust Boundaries
3.9 State and Persistence Model
3.10 Scalability Model
3.11 Failure Modes and Recovery Patterns
3.12 Why This Architecture Works in Practice
20.4 Rollback Execution Playbook
Orbnetes deployment and release orchestration documentation for operators and platform teams.
Objective
Recover from failed deployment using configured rollback policy with full traceability.
Prerequisites
- rollback policy enabled on release,
- check target configured (
all_pipelineor critical job), - rollback mode selected (last successful / selected release / selected version),
- known-good rollback target exists.
Steps
- Detect release failure (status or check target failure).
- Verify rollback policy conditions were met.
- Wait configured rollback delay window.
- Confirm rollback release is created and linked to failed release.
- Monitor rollback pipeline execution live.
- Validate post-rollback environment state.
- Document incident and closure notes in release discussion/logs.
Success Criteria
- rollback release completes successfully,
- environment returns to stable known-good version,
- source failed release and rollback release linkage is visible,
- audit trail includes trigger and execution events.
Common Pitfalls
- rollback target points to invalid/missing artifact,
- policy triggers from non-authoritative job signal,
- recursive rollback behavior not constrained by team policy.