Premise
Fallout today is a CI authoring framework: describe targets in C#, it runs them. The next horizon is CD — deployment orchestration, environment promotion, release tracking, approval gates. The space owned today by TeamCity, Octopus Deploy, GitHub Environments, and the release stages of Azure DevOps Pipelines.
Placeholder RFC to collect thinking. Nothing committed; shape is TBD.
Why this could fit Fallout
- C#-native, code-first. Same wedge as Fallout-on-CI: deployments as first-class C# code — refactorable, testable, type-safe, IDE-supported. Octopus and Azure Release Pipelines lean on YAML/UI config.
- One mental model from build to deploy. A consumer's
Build.cs already knows their tools, repo structure, and packaging. Extending into Deploy.cs reuses all of it.
- Plugin SDK leverage. v12 ships extension points (hosts, middleware, lifecycle listeners, output sinks). CD-shaped points (environment providers, deployment-target providers, approval gates) compose naturally with that catalogue.
Open questions
- CI/CD boundary. Does Fallout-CD consume only Fallout-on-CI artifacts, or also artifacts from other CI systems (GH Actions, Azure Pipelines, Jenkins)?
- Environment model. Declarative (yaml / C# records) vs imperative (
Target DeployToStaging). Probably the latter given code-first ethos, but worth designing.
- State store. Where do "release N is deployed to staging" facts live? Git tags/branches? External backend (db/blob)? Pluggable provider?
- Approvals and gates. First-class framework concept, or plugin-SDK extension point?
- Packaging. Same family (
Fallout.Cd.*), separate product, or first-party plugins on the v12 SDK?
- Wedge against incumbents. Octopus and TeamCity are mature. The honest question: who switches, and why? "C#-native, single binary, code-first" is the hypothesis — needs to survive contact with real users.
How to engage
Most useful: name a deployment shape you'd want Fallout for, and show where current CD tools fall short. Concrete use cases beat abstract design preferences.
Premise
Fallout today is a CI authoring framework: describe targets in C#, it runs them. The next horizon is CD — deployment orchestration, environment promotion, release tracking, approval gates. The space owned today by TeamCity, Octopus Deploy, GitHub Environments, and the release stages of Azure DevOps Pipelines.
Placeholder RFC to collect thinking. Nothing committed; shape is TBD.
Why this could fit Fallout
Build.csalready knows their tools, repo structure, and packaging. Extending intoDeploy.csreuses all of it.Open questions
Target DeployToStaging). Probably the latter given code-first ethos, but worth designing.Fallout.Cd.*), separate product, or first-party plugins on the v12 SDK?How to engage
Most useful: name a deployment shape you'd want Fallout for, and show where current CD tools fall short. Concrete use cases beat abstract design preferences.