add release orchestrator docs and sprints gaps fills
This commit is contained in:
246
docs/modules/release-orchestrator/roadmap.md
Normal file
246
docs/modules/release-orchestrator/roadmap.md
Normal file
@@ -0,0 +1,246 @@
|
||||
# Implementation Roadmap
|
||||
|
||||
> Phased delivery plan for the Release Orchestrator implementation.
|
||||
|
||||
**Status:** Planned
|
||||
**Source:** [Architecture Advisory Section 14](../../../product/advisories/09-Jan-2026%20-%20Stella%20Ops%20Orchestrator%20Architecture.md)
|
||||
**Related:** [Implementation Guide](implementation-guide.md), [Test Structure](test-structure.md)
|
||||
|
||||
## 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 | Optional; for Stella core deployment (not required for targets) |
|
||||
|
||||
---
|
||||
|
||||
## 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 |
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- [Sprint Index](../../implplan/SPRINT_20260110_100_000_INDEX_release_orchestrator.md)
|
||||
- [Implementation Guide](implementation-guide.md)
|
||||
- [Test Structure](test-structure.md)
|
||||
- [Architecture Overview](architecture.md)
|
||||
Reference in New Issue
Block a user