release orchestrator pivot, architecture and planning

This commit is contained in:
2026-01-10 22:37:22 +02:00
parent c84f421e2f
commit d509c44411
130 changed files with 70292 additions and 721 deletions

View File

@@ -1,34 +1,112 @@
# Roadmap
This repository is the source of truth for StellaOps direction. The roadmap is expressed as stable, evidence-based capability milestones (not calendar promises) so it stays correct during long audits and offline operation.
This repository is the source of truth for Stella Ops Suite direction. The roadmap is expressed as stable, evidence-based capability milestones (not calendar promises) so it stays correct during long audits and offline operation.
## How to read this
- **Now / Next / Later** are priority bands, not dates.
- A capability is "done" when the required evidence exists and is reproducible (see `docs/product/roadmap/maturity-model.md`).
## Strategic Direction
## Now (Foundation)
- Deterministic scan pipeline: image -> SBOMs (SPDX 3.0.1 + CycloneDX 1.7) with stable identifiers and replayable outputs.
- Advisory ingestion with offline-friendly mirrors, normalization, and deterministic merges.
- VEX-first triage: OpenVEX ingestion/consensus with explainable, stable verdicts.
- Policy gates: deterministic policy evaluation (OPA/Rego where applicable) with audit-friendly decision traces.
- Offline Kit workflows (bundle -> import -> verify) with signed artifacts and deterministic indexes.
**Stella Ops Suite** is evolving from a vulnerability scanning platform into a **centralized, auditable release control plane** for non-Kubernetes container estates. The existing scanning capabilities become security gates within release orchestration.
## Next (Hardening)
- Multi-tenant isolation (tenancy boundaries + RLS where applicable) and an audit trail built for replay.
- Signing and provenance hardening: DSSE/in-toto everywhere; configurable crypto profiles (FIPS/GOST/SM) where enabled.
- Determinism gates and replay tests in CI to prevent output drift across time and environments.
- **Release orchestration** — UI-driven promotion (Dev → Stage → Prod), approvals, policy gates, rollbacks
- **Security decisioning as a gate** — Scan on build, evaluate on release, re-evaluate on CVE updates
- **OCI-digest-first releases** — Immutable digest-based release identity
- **Non-Kubernetes specialization** — Docker hosts, Compose, ECS, Nomad as first-class targets
## Later (Ecosystem)
- Wider connector/plugin ecosystem, operator tooling, and SDKs.
- Expanded graph/reachability capabilities and export/pack formats for regulated environments.
## How to Read This
## Detailed breakdown
- `docs/product/roadmap/README.md`
- `docs/product/roadmap/maturity-model.md`
- **Operational** = capabilities that are implemented and working
- **Now / Next / Later** = priority bands for new development (not calendar dates)
- A capability is "done" when the required evidence exists and is reproducible (see `docs/product/roadmap/maturity-model.md`)
## Related high-level docs
- `docs/VISION.md`
- `docs/FEATURE_MATRIX.md`
- `docs/ARCHITECTURE_OVERVIEW.md`
- `docs/OFFLINE_KIT.md`
- `docs/key-features.md`
---
## Operational (Existing Capabilities)
These capabilities are implemented and serve as the foundation for security gates:
- **Deterministic scan pipeline** — Image → SBOMs (SPDX 3.0.1 + CycloneDX 1.7) with stable identifiers and replayable outputs
- **Advisory ingestion** — Offline-friendly mirrors, normalization, deterministic merges (Concelier)
- **VEX-first triage** — OpenVEX ingestion/consensus with explainable, stable verdicts (VEX Lens)
- **Policy gates** — Deterministic policy evaluation (OPA/Rego) with audit-friendly decision traces
- **Offline Kit workflows** — Bundle → import → verify with signed artifacts and deterministic indexes
- **Signing and provenance** — DSSE/in-toto attestations; configurable crypto profiles (FIPS/eIDAS/GOST/SM)
- **Determinism guarantees** — Replay tests in CI; frozen feeds; stable ordering
---
## Now (Release Orchestration Foundation)
Priority: Building the core release orchestration infrastructure.
### Phase 1: Foundation
- **Environment management** — Environment CRUD, freeze windows, approval policies
- **Integration hub** — Connection profiles, basic connectors (GitHub, Harbor)
- **Release bundles** — Component registry, release creation, tag → digest resolution
- **Database schemas** — Core release, environment, target tables
### Phase 2: Workflow Engine
- **DAG execution** — Directed acyclic graph workflow processing
- **Step registry** — Built-in steps (script, approval, deploy, gate)
- **Workflow templates** — Reusable workflow definitions
- **Script execution** — C# compiled scripts + sandboxed bash
---
## Next (Promotion & Deployment)
Priority: Enabling end-to-end release flow.
### Phase 3: Promotion & Decision
- **Approval gateway** — Approval collection, separation of duties
- **Security gates** — Integration with scan verdicts for gate evaluation
- **Decision engine** — Gate aggregation, decision record generation
- **Evidence packets** — Sealed, signed evidence bundles
### Phase 4: Deployment Execution
- **Agent framework** — Core agent infrastructure, heartbeat, capability advertisement
- **Docker/Compose agents** — Agent-based deployment to Docker and Compose targets
- **Artifact generation** — `compose.stella.lock.yml`, deployment scripts
- **Rollback support** — Previous version restoration
- **Version stickers** — On-target deployment records for drift detection
### Phase 5: UI & Polish
- **Release dashboard** — Release list, status, promotion history
- **Promotion UI** — Request, approve, track promotions
- **Environment management UI** — Environment configuration, freeze windows
---
## Later (Advanced Capabilities)
Priority: Expanding target support and delivery strategies.
### Phase 6: Progressive Delivery
- **A/B releases** — Traffic splitting between versions
- **Canary deployments** — Gradual rollout with health checks
- **Traffic routing plugins** — Nginx, HAProxy, Traefik, AWS ALB integration
### Phase 7: Extended Targets
- **ECS agent** — AWS ECS service deployment
- **Nomad agent** — HashiCorp Nomad job deployment
- **SSH/WinRM agentless** — Remote execution without installed agent
### Phase 8: Plugin Ecosystem
- **Full plugin system** — Three-surface plugin model (manifest, connector, step provider)
- **Plugin SDK** — Development kit for custom integrations
- **Additional connectors** — Expanded SCM, CI, registry, vault support
---
## Detailed Breakdown
- `docs/product/roadmap/README.md` — Detailed roadmap documentation
- `docs/product/roadmap/maturity-model.md` — Capability maturity definitions
- `docs/modules/release-orchestrator/architecture.md` — Release orchestrator architecture
## Related Documents
- [Product Vision](product/VISION.md)
- [Architecture Overview](ARCHITECTURE_OVERVIEW.md)
- [Feature Matrix](FEATURE_MATRIX.md)
- [Key Features](key-features.md)
- [Offline Kit](OFFLINE_KIT.md)
- [Release Orchestrator Specification](product/advisories/09-Jan-2026%20-%20Stella%20Ops%20Orchestrator%20Architecture.md)