Premise
Fallout today is a CI authoring framework: describe targets in C#, it runs them. The natural next horizon is CD — deployment orchestration, environment promotion, release tracking, approval gates. The space currently owned by TeamCity, Octopus Deploy, GitHub Environments, and the release stages of Azure DevOps Pipelines.
This is a placeholder RFC to start collecting thinking. Nothing committed; shape is genuinely 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 heavily on YAML/UI configuration.
- One mental model from build to deploy. A consumer's
Build.cs already knows their tools, repo structure, and packaging conventions. Extending into Deploy.cs reuses everything.
- Plugin SDK leverage. v12 ships extension points (hosts, middleware, lifecycle listeners, output sinks). CD-shaped extension points (environment providers, deployment-target providers, approval gates) compose naturally with that catalogue.
Open questions
- CI/CD boundary. Does Fallout-CD consume artifacts produced by Fallout-on-CI exclusively, or also artifacts produced by other CI systems (GH Actions, Azure Pipelines, Jenkins)?
- Environment model. Declarative (yaml / C# records) vs imperative (
Target DeployToStaging). Probably the latter given the 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 concept in the framework, or extension point on the plugin SDK?
- Packaging story. Same package family (
Fallout.Cd.*), separate product, or first-party plugins shipped on the v12 SDK?
- Wedge against incumbents. Octopus and TeamCity are mature and battle-tested. 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 comments: name a deployment shape you'd want to use Fallout for, and show where current CD tools fall short for that shape. Concrete use cases beat abstract design preferences.
Premise
Fallout today is a CI authoring framework: describe targets in C#, it runs them. The natural next horizon is CD — deployment orchestration, environment promotion, release tracking, approval gates. The space currently owned by TeamCity, Octopus Deploy, GitHub Environments, and the release stages of Azure DevOps Pipelines.
This is a placeholder RFC to start collecting thinking. Nothing committed; shape is genuinely TBD.
Why this could fit Fallout
Build.csalready knows their tools, repo structure, and packaging conventions. Extending intoDeploy.csreuses everything.Open questions
Target DeployToStaging). Probably the latter given the code-first ethos, but worth designing.Fallout.Cd.*), separate product, or first-party plugins shipped on the v12 SDK?How to engage
Most useful comments: name a deployment shape you'd want to use Fallout for, and show where current CD tools fall short for that shape. Concrete use cases beat abstract design preferences.