Implementation Roadmap
Phased delivery plan for the Release Orchestrator implementation.
Status note (2026-07-03): this document is the original aspirational delivery plan (phases, team sizing, week-by-week schedule); it does not describe the as-built implementation or its current state. Several “planned” items have long since shipped (e.g. SSH/WinRM agentless transports, Phase 7). See promotion-runtime-gap-closure-plan.md for as-built status.
Status: Historical plan (superseded by as-built status — see note above) Source: Architecture Advisory Section 14 (archived) Related: Implementation Guide, Test Structure
Overview
The Release Orchestrator is delivered in 8 phases over 34 weeks, progressively building from foundational infrastructure to full plugin ecosystem support.
Phased Delivery Plan
Phase 1: Foundation (Weeks 1-4)
Goal: Core infrastructure and basic release management
| Week | Deliverables |
|---|---|
| Week 1 | Database schema migration; INTHUB integration-manager; connection-profiles |
| Week 2 | ENVMGR environment-manager; target-registry (basic) |
| Week 3 | RELMAN component-registry; version-manager; release-manager |
| Week 4 | Basic release CRUD APIs; CLI commands; integration tests |
Exit Criteria:
- Can create environments with config
- Can register components with image repos
- Can create releases with pinned digests
- Can list/search releases
Certified Path: Manual release creation; no deployment yet
Phase 2: Workflow Engine (Weeks 5-8)
Goal: Workflow execution capability
| Week | Deliverables |
|---|---|
| Week 5 | WORKFL step-registry; built-in step types (approval, policy-gate, notify) |
| Week 6 | WORKFL workflow-designer; workflow template CRUD |
| Week 7 | WORKFL workflow-engine; DAG execution; state machine |
| Week 8 | Step executor; retry logic; timeout handling; workflow run APIs |
Exit Criteria:
- Can create workflow templates via API
- Can execute workflows with approval steps
- Workflow state machine handles all transitions
- Step retries work correctly
Certified Path: Approval-only workflows; no deployment execution yet
Phase 3: Promotion & Decision (Weeks 9-12)
Goal: Promotion workflow with security gates
| Week | Deliverables |
|---|---|
| Week 9 | PROMOT promotion-manager; approval-gateway |
| Week 10 | PROMOT decision-engine; security gate integration with SCANENG |
| Week 11 | Gate registry; freeze window gate; SoD enforcement |
| Week 12 | Promotion APIs; “Why blocked?” endpoint; decision record |
Exit Criteria:
- Can request promotion
- Security gates evaluate scan verdicts
- Approval workflow enforces SoD
- Decision record captures gate results
Certified Path: Promotions with security + approval gates; no deployment yet
Phase 4: Deployment Execution (Weeks 13-18)
Goal: Deploy to Docker/Compose targets
| Week | Deliverables |
|---|---|
| Week 13 | AGENTS agent-core; agent registration; heartbeat |
| Week 14 | AGENTS agent-docker; Docker host deployment |
| Week 15 | AGENTS agent-compose; Compose deployment |
| Week 16 | DEPLOY deploy-orchestrator; artifact-generator |
| Week 17 | DEPLOY rollback-manager; version sticker writing |
| Week 18 | RELEVI evidence-collector; evidence-signer; audit-exporter |
Exit Criteria:
- Agents can register and receive tasks
- Docker deployment works with digest verification
- Compose deployment writes lock files
- Rollback restores previous version
- Evidence packets generated for deployments
Certified Path: Full promotion -> deployment flow for Docker/Compose
Phase 5: UI & Polish (Weeks 19-22)
Goal: Web console for release orchestration
| Week | Deliverables |
|---|---|
| Week 19 | Dashboard components; metrics widgets |
| Week 20 | Environment overview; release detail screens |
| Week 21 | Workflow editor (graph); run visualization |
| Week 22 | Promotion UI; approval queue; “Why blocked?” modal |
Exit Criteria:
- Dashboard shows operational metrics
- Can manage environments/releases via UI
- Can create/edit workflows in graph editor
- Can approve promotions via UI
Certified Path: Complete v1 user experience
Phase 6: Progressive Delivery (Weeks 23-26)
Goal: A/B releases and canary deployments
| Week | Deliverables |
|---|---|
| Week 23 | PROGDL ab-manager; target-group A/B |
| Week 24 | PROGDL canary-controller; stage execution |
| Week 25 | PROGDL traffic-router; Nginx plugin |
| Week 26 | Canary UI; traffic visualization; health monitoring |
Exit Criteria:
- Can create A/B release with variations
- Canary controller advances stages based on health
- Traffic router shifts weights
- Rollback on health failure works
Certified Path: Target-group A/B; Nginx router-based A/B
Phase 7: Extended Targets (Weeks 27-30)
Goal: ECS and Nomad support; SSH/WinRM agentless
| Week | Deliverables |
|---|---|
| Week 27 | AGENTS agent-ssh; SSH remote executor |
| Week 28 | AGENTS agent-winrm; WinRM remote executor |
| Week 29 | AGENTS agent-ecs; ECS deployment |
| Week 30 | AGENTS agent-nomad; Nomad deployment |
Exit Criteria:
- SSH deployment works with script execution
- WinRM deployment works with PowerShell
- ECS task definition updates work
- Nomad job submissions work
Certified Path: All target types operational
Phase 8: Plugin Ecosystem (Weeks 31-34)
Goal: Full plugin system; external integrations
| Week | Deliverables |
|---|---|
| Week 31 | PLUGIN plugin-registry; plugin-loader |
| Week 32 | PLUGIN plugin-sandbox; plugin-sdk |
| Week 33 | GitHub plugin; GitLab plugin |
| Week 34 | Jenkins plugin; Vault plugin |
Exit Criteria:
- Can install and configure plugins
- Plugins can contribute step types
- Plugins can contribute integrations
- Plugin sandbox enforces limits
Certified Path: GitHub + Harbor + Docker/Compose + Vault
Resource Requirements
Team Structure
| Role | Count | Responsibilities |
|---|---|---|
| Tech Lead | 1 | Architecture decisions; code review; unblocking |
| Backend Engineers | 4 | Module development; API implementation |
| Frontend Engineers | 2 | Web console; dashboard; workflow editor |
| DevOps Engineer | 1 | CI/CD; infrastructure; agent deployment |
| QA Engineer | 1 | Test automation; integration testing |
| Technical Writer | 0.5 | Documentation; API docs; user guides |
Infrastructure Requirements
| Component | Specification |
|---|---|
| PostgreSQL | Primary database; 16+ recommended; read replicas for scale |
| Redis | Job queues; caching; session storage |
| Object Storage | S3-compatible; evidence packets; large artifacts |
| Container Runtime | Docker; for plugin sandboxes |
| Kubernetes | Unsupported for Stella Ops deployment; use external tooling if a customer target is Kubernetes |
Risk Mitigation
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Agent security complexity | High | High | Early security review; penetration testing; mTLS implementation in Phase 4 |
| Workflow state machine edge cases | Medium | High | Comprehensive state transition tests; chaos testing |
| Plugin sandbox escapes | Low | Critical | Security audit; capability restrictions; resource limits |
| Database migration issues | Medium | Medium | Staged rollout; rollback scripts; data validation |
| UI performance with large workflows | Medium | Medium | Virtual rendering; lazy loading; performance testing |
| Integration compatibility | High | Medium | Abstract connector interface; extensive integration tests |
Success Metrics
| Phase | Key Metrics |
|---|---|
| Phase 1 | Release creation time < 5s; API latency p99 < 200ms |
| Phase 2 | Workflow execution reliability > 99.9% |
| Phase 3 | Gate evaluation time < 500ms; SoD enforcement 100% |
| Phase 4 | Deployment success rate > 99%; rollback time < 60s |
| Phase 5 | UI initial load < 2s; real-time update latency < 1s |
| Phase 6 | Canary rollback trigger time < 30s |
| Phase 7 | All target type coverage with unified API |
| Phase 8 | Plugin sandbox isolation verified by security audit |