Clarify enablement forge handoffs
This commit is contained in:
18
INTENT.md
18
INTENT.md
@@ -40,7 +40,8 @@ Railiance evolve faster without dissolving its layer boundaries.
|
||||
To become the **canonical home for developer and delivery enablement** -
|
||||
CI/CD pipelines, GitOps workflows, workload templates, SDKs, buildpacks,
|
||||
developer portal surfaces, and promotion conventions that help source repos
|
||||
move safely toward S5 application releases.
|
||||
move safely toward S5 application releases while consuming forge-provided
|
||||
runners, registries, and artifact evidence.
|
||||
|
||||
This means:
|
||||
|
||||
@@ -48,6 +49,7 @@ This means:
|
||||
* Build and deployment templates encode **Railiance platform expectations**
|
||||
* Developers get fast feedback through **standard checks and pipelines**
|
||||
* S5 can consume release artifacts through **clear handoff contracts**
|
||||
* Forge runtime and runner substrate remain owned by **railiance-forge**
|
||||
* Enablement improves delivery without taking ownership of app runtime
|
||||
operation
|
||||
|
||||
@@ -75,13 +77,20 @@ consumers do not need to rediscover platform assumptions.
|
||||
CI/CD and promotion flows should produce artifacts, metadata, and evidence that
|
||||
the application layer can deploy and verify without guessing.
|
||||
|
||||
### 5. Fast Feedback
|
||||
### 5. Clear Handoff to Forge
|
||||
|
||||
Reusable workflows should state the forge capabilities they require: repository
|
||||
events, runner labels, package credentials, registry endpoints, and artifact
|
||||
evidence. This layer defines the reusable workflow shape; `railiance-forge`
|
||||
owns the runtime and credentials behind it.
|
||||
|
||||
### 6. Fast Feedback
|
||||
|
||||
Developers should learn about broken builds, missing declarations, incompatible
|
||||
interfaces, and release-readiness gaps before those problems reach live
|
||||
application deployments.
|
||||
|
||||
### 6. Boundaries Preserve Velocity
|
||||
### 7. Boundaries Preserve Velocity
|
||||
|
||||
Enablement should make the layered architecture easier to use, not become a
|
||||
shortcut for mutating infrastructure, cluster, platform, or application
|
||||
@@ -110,6 +119,7 @@ This layer is not:
|
||||
* the Kubernetes runtime
|
||||
* the shared platform-services layer
|
||||
* the application deployment and operations layer
|
||||
* the source forge, package/container registry, or runner substrate layer
|
||||
* the source-code home for business workloads
|
||||
* a replacement for repo-owned workplans, ADRs, or implementation decisions
|
||||
|
||||
@@ -125,6 +135,8 @@ This layer is expected to evolve toward:
|
||||
* Standard **pipeline templates** for Railiance workloads
|
||||
* Reusable **build and image promotion** conventions
|
||||
* GitOps workflows with clear **review and rollback** expectations
|
||||
* Handoff contracts with `railiance-forge` for **runner labels, package
|
||||
credentials, registry endpoints, and artifact evidence**
|
||||
* Developer-facing **self-service templates** and portal entry points
|
||||
* SDKs and examples that make platform capabilities easy to consume correctly
|
||||
* Release evidence that S5 can use for **deployment readiness**
|
||||
|
||||
49
SCOPE.md
49
SCOPE.md
@@ -8,23 +8,31 @@
|
||||
|
||||
## One-liner
|
||||
|
||||
S4 Developer Enablement layer of the Railiance OAS Stack — owns CI/CD pipelines, developer portal, platform templates, SDKs, and buildpacks.
|
||||
S4 Developer Enablement layer of the Railiance OAS Stack — owns reusable CI/CD
|
||||
templates, developer portal paths, platform templates, SDKs, and buildpacks;
|
||||
uses forge capabilities without owning forge runtime or runner substrate.
|
||||
|
||||
---
|
||||
|
||||
## Core Idea
|
||||
|
||||
Railiance is structured as five independent repos per OAS Stack layer. This repo is S4 — the tools that allow the system to evolve. S4 depends on the platform (S3) being operational before any tooling can use platform services, and in turn S5 (applications) uses S4's CI/CD pipelines and deployment templates.
|
||||
Railiance is structured as independent repos per OAS Stack layer. This repo is
|
||||
S4: the reusable tools and paved paths that allow the system to evolve. S4
|
||||
depends on the platform (S3) being operational before tooling can use platform
|
||||
services. S5 applications consume S4 templates and conventions, while
|
||||
`railiance-forge` provides source hosting, registries, and runner substrate.
|
||||
|
||||
---
|
||||
|
||||
## In Scope
|
||||
|
||||
- CI/CD pipelines and automation tooling
|
||||
- Reusable CI/CD workflow templates and automation patterns
|
||||
- Developer portal (self-service deployment interface)
|
||||
- Platform deployment templates for workloads
|
||||
- SDKs and libraries for platform consumers
|
||||
- Buildpacks and image builders
|
||||
- Handoff contracts to `railiance-forge` for runner labels, artifact evidence,
|
||||
and registry consumption
|
||||
|
||||
---
|
||||
|
||||
@@ -33,7 +41,10 @@ Railiance is structured as five independent repos per OAS Stack layer. This repo
|
||||
- OS-level concerns → railiance-infra (S1)
|
||||
- Kubernetes runtime → railiance-cluster (S2)
|
||||
- Platform services → railiance-platform (S3)
|
||||
- Source forge runtime, container/package registries, runner deployment,
|
||||
runner labels, and runner credentials → railiance-forge
|
||||
- Application deployments → railiance-apps (S5)
|
||||
- App-specific workflows, release charts, and source code → app/source repos
|
||||
- No re-configuration of lower layers from this repo
|
||||
|
||||
---
|
||||
@@ -42,6 +53,8 @@ Railiance is structured as five independent repos per OAS Stack layer. This repo
|
||||
|
||||
- Setting up CI/CD for the Railiance stack
|
||||
- Creating or modifying developer tools and deployment templates
|
||||
- Defining reusable workflow templates that run on forge-provided runners
|
||||
- Defining promotion conventions and evidence formats consumed by S5
|
||||
- S3 is operational and tooling layer can now be built
|
||||
|
||||
---
|
||||
@@ -50,35 +63,51 @@ Railiance is structured as five independent repos per OAS Stack layer. This repo
|
||||
|
||||
- S3 (platform services) is not yet operational (pre-condition not met)
|
||||
- Infrastructure, cluster, or platform work needed (wrong layer)
|
||||
- The work is Gitea/Forgejo runtime, registry endpoint, package retention,
|
||||
runner deployment, or runner secret access (use `railiance-forge`)
|
||||
- The work is a concrete app release or app-specific runbook (use
|
||||
`railiance-apps` or the source app repo)
|
||||
|
||||
---
|
||||
|
||||
## Current State
|
||||
|
||||
- Status: emerging (ArgoCD deployed; no S4 workplans yet)
|
||||
- Implementation: ArgoCD is deployed in the `argocd` namespace on COULOMBCORE — installed as a cluster addon (managed from S2 for now); no S4-owned workplans yet
|
||||
- Implementation: ArgoCD is deployed in the `argocd` namespace on COULOMBCORE
|
||||
as a cluster addon managed from S2 for now; no S4-owned workplans yet
|
||||
- Stability: n/a for S4-owned content; ArgoCD itself is operational
|
||||
- Usage: ArgoCD available for GitOps deployments; formal S4 tooling work begins after S3 baseline
|
||||
- Usage: ArgoCD available for GitOps deployments; formal S4 tooling work begins
|
||||
after S3 baseline and should consume runner/registry capabilities from
|
||||
`railiance-forge`
|
||||
|
||||
---
|
||||
|
||||
## How It Fits
|
||||
|
||||
- Upstream dependencies: railiance-platform (S3) must be operational
|
||||
- Downstream consumers: railiance-apps (S5) uses CI/CD and templates from this layer
|
||||
- Often used with: railiance-platform (S3), railiance-apps (S5)
|
||||
- Adjacent forge provider: railiance-forge owns source hosting, registries, and
|
||||
runner substrate used by S4 workflows
|
||||
- Downstream consumers: railiance-apps (S5) uses CI/CD and templates from this
|
||||
layer
|
||||
- Often used with: railiance-platform (S3), railiance-forge, railiance-apps (S5)
|
||||
|
||||
---
|
||||
|
||||
## Terminology
|
||||
|
||||
- Preferred terms: OAS Stack Level S4, developer enablement, boundary rule
|
||||
- Preferred terms: OAS Stack Level S4, developer enablement, paved path,
|
||||
workflow template, promotion convention, boundary rule
|
||||
- Distinguish "workflow template" from "runner substrate": templates live here;
|
||||
runner deployment, labels, credentials, and health live in
|
||||
`railiance-forge`.
|
||||
|
||||
---
|
||||
|
||||
## Related / Overlapping
|
||||
|
||||
- `railiance-platform` (S3) — pre-condition; provides services that S4 tooling depends on
|
||||
- `railiance-forge` — provides source forge runtime, artifact registries, and
|
||||
runner substrate consumed by S4 workflows
|
||||
- `railiance-apps` (S5) — consumer of S4 CI/CD and templates
|
||||
|
||||
---
|
||||
@@ -89,13 +118,13 @@ Railiance is structured as five independent repos per OAS Stack layer. This repo
|
||||
type: infrastructure
|
||||
title: CI/CD pipeline automation
|
||||
description: Automated build, test, and deployment pipelines for Railiance workloads — planned for when railiance-platform (S3) is operational.
|
||||
keywords: [ci, cd, pipeline, automation, build, deploy, gitops]
|
||||
keywords: [ci, cd, pipeline, automation, template, build, deploy, gitops]
|
||||
```
|
||||
|
||||
```capability
|
||||
type: documentation
|
||||
title: Platform deployment templates and SDKs
|
||||
description: Standardised deployment templates, Helm charts, and SDKs enabling consistent application deployments across the Railiance stack.
|
||||
description: Standardised deployment templates, Helm chart patterns, SDKs, and promotion conventions enabling consistent application deployments across the Railiance stack while consuming forge-owned runners and registries.
|
||||
keywords: [template, sdk, helm, deployment, developer, buildpack]
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user