docs(P51): full presentation rework — scope, story arc, visuals, appendix
Major rework of both presentation decks based on leadership feedback. Addresses: story arc, concept clarity, scope clarification, more visuals, appendix for detail-heavy slides, and a complete Road to the North Star. 6 new mermaid diagrams: - platform-works-03-scope-boundary (Upstream → Contract → ACDL → AWS) - developer-experience-01b-scope-boundary (both consumer paths + scope) - platform-works-04-confidence-signal (6 inputs → score → gate → decision) - platform-works-05-attestation-flow (deploy → gate → approver → evidence) - developer-experience-04-promotion-journey (dev → qa → prod → dr) - road-to-north-star (v1.0 demo → v1.9 → v1.10 → v2.0 → North Star) Both Marp decks restructured to 10 main + 6 appendix slides: PW deck (17 slides): 1. Title 2. The Problem & The North Star (anti-goals moved to slide 3) 3. Where ACDL Sits in Your World (NEW — scope boundary, infra only) 4. The Contract-Driven Model (image: removed, infra inputs instead) 5. The End-to-End Flow 6. Zero-Trust by Default 7. Safety is Computed (NEW confidence signal diagram) 8. Security by Construction 9. Accountability & Audit (NEW attestation flow diagram, QA clarification, badge reclassification: dev=Testing, qa/prod/dr=Planned) 10. Testing vs. Planned (summary, full inventory in appendix) 11. The Vision Realized + Appendix: TOC, Platform-Managed Environments, Observability, Road to North Star, Full Inventory, Glossary DX deck (16 slides): 1. Title 2. Where ACDL Sits in Your World (REPLACES Two Consumer Surfaces — scope boundary with both consumer paths) 3. The Contract — The Entire Consumer Surface (image: removed) 4. The Developer Feedback Loop 5. Versioned, Predictable Releases 6. Friendly Onboarding 7. Safe Promotion Path (NEW promotion journey diagram, rising bar annotated: dev=Testing, qa/prod/dr=Planned) 8. Safe Decommission 9. Self-Service Module Catalog 10. The Desired Outcomes + Appendix: TOC, Citizen Developer Experience, No Platform Code, Local Reproducibility, Road to North Star, Glossary Story arc: every slide has an italic 'Story beat' line connecting it to the narrative progression. Scope clarification: ACDL is infrastructure only. Upstream is anything (IDE, agentic SDLC, citizen dev vibe coding). ACDL provisions and governs AWS resources; application deployment is upstream. Contract examples now show infrastructure inputs (cpu, memory, desired_count, port) not image:. QA attestation reclassification: 'Design tested' → 'Planned'. QA attests to infrastructure readiness (contract + Terraform plan + evidence), not application code. Dev is autonomous (Testing); qa/prod/dr are Planned. Road to the North Star: phased timeline (v1.0 → v1.9 → v1.10 → v2.0 → North Star), annotated 'proposed phasing, not formally planned.' Also: scripts/sync_to_gl.sh added (GitLab mirror sync utility). ---ci--- phase: 51 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci---
This commit is contained in:
Jon Chery
@@ -115,9 +115,9 @@ Distill the source of truth (Step 1) into presenter-ready cues, indexed by
|
||||
the Marp deck (Step 2) slide structure:
|
||||
|
||||
- **One section per Marp slide** — `## Slide N — Title`, matching the Marp
|
||||
deck's 10-slide structure exactly. The Marp deck provides the indexing and
|
||||
context (what the audience sees); the source markdown provides the content
|
||||
(the speaker notes, the detail, the nuance).
|
||||
deck's 10 main + 6 appendix slide structure exactly. The Marp deck
|
||||
provides the indexing and context (what the audience sees); the source
|
||||
markdown provides the content (the speaker notes, the detail, the nuance).
|
||||
- **3-6 talking point bullets per slide** — punchy, actionable cues distilled
|
||||
from the source markdown's speaker notes. NOT the speaker notes verbatim
|
||||
(those are too long and too contextual). These are prompts: "Land this
|
||||
@@ -145,31 +145,57 @@ and re-distill.
|
||||
docs/presentations/
|
||||
├── README.md ← this file
|
||||
├── how-the-platform-works.md ← Step 1: full source of truth
|
||||
├── how-the-platform-works-marp.md ← Step 2: Marp deck (10 slides)
|
||||
├── how-the-platform-works-marp.md ← Step 2: Marp deck (10 main + 6 appendix)
|
||||
├── how-the-platform-works.html ← Step 3: rendered HTML (committed)
|
||||
├── how-the-platform-works-talking-points.md ← Step 4: presenter cues (10 sections)
|
||||
├── how-the-platform-works-talking-points.md ← Step 4: presenter cues (16 sections)
|
||||
├── the-developer-experience.md ← Step 1: full source of truth
|
||||
├── the-developer-experience-marp.md ← Step 2: Marp deck (10 slides)
|
||||
├── the-developer-experience-marp.md ← Step 2: Marp deck (10 main + 6 appendix)
|
||||
├── the-developer-experience.html ← Step 3: rendered HTML (committed)
|
||||
├── the-developer-experience-talking-points.md ← Step 4: presenter cues (10 sections)
|
||||
├── the-developer-experience-talking-points.md ← Step 4: presenter cues (16 sections)
|
||||
└── assets/
|
||||
├── puppeteer-config.json ← no-sandbox config for mmdc
|
||||
├── mmd/ ← mermaid source files (Step 2 input)
|
||||
│ ├── platform-works-01-contract-driven.mmd
|
||||
│ ├── platform-works-02-end-to-end-flow.mmd
|
||||
│ ├── developer-experience-01-two-surfaces.mmd
|
||||
│ ├── platform-works-03-scope-boundary.mmd
|
||||
│ ├── platform-works-04-confidence-signal.mmd
|
||||
│ ├── platform-works-05-attestation-flow.mmd
|
||||
│ ├── developer-experience-01b-scope-boundary.mmd
|
||||
│ ├── developer-experience-02-what-dev-does.mmd
|
||||
│ └── developer-experience-03-no-cloning.mmd
|
||||
│ ├── developer-experience-03-no-cloning.mmd
|
||||
│ ├── developer-experience-04-promotion-journey.mmd
|
||||
│ └── road-to-north-star.mmd
|
||||
└── png/ ← rendered PNGs (embedded in Marp)
|
||||
├── platform-works-01-contract-driven.png
|
||||
├── platform-works-02-end-to-end-flow.png
|
||||
├── developer-experience-01-two-surfaces.png
|
||||
├── platform-works-03-scope-boundary.png
|
||||
├── platform-works-04-confidence-signal.png
|
||||
├── platform-works-05-attestation-flow.png
|
||||
├── developer-experience-01b-scope-boundary.png
|
||||
├── developer-experience-02-what-dev-does.png
|
||||
└── developer-experience-03-no-cloning.png
|
||||
├── developer-experience-03-no-cloning.png
|
||||
├── developer-experience-04-promotion-journey.png
|
||||
└── road-to-north-star.png
|
||||
```
|
||||
|
||||
## Conventions
|
||||
|
||||
### Appendix structure
|
||||
|
||||
Each Marp deck has **10 main slides + 6 appendix slides** (16 total). The
|
||||
main 10 are the presentation; the appendix is for deep dives and Q&A backup.
|
||||
|
||||
- **Main slides** (1-10): the story arc, high-impact, minimal text,
|
||||
visual-heavy. These are what the audience sees during the talk.
|
||||
- **Appendix slides** (A1-A5 + TOC): detail-heavy slides moved out of the
|
||||
main 10 to preserve the narrative flow. The appendix starts with a TOC
|
||||
slide listing the contents, followed by detail slides and a glossary.
|
||||
- **The Road to the North Star** is a required appendix slide in both decks
|
||||
— a phased timeline from v1.0 demo to the North Star, annotated as
|
||||
"proposed phasing, not formally planned."
|
||||
- **The Glossary** is a required appendix slide in both decks — defines
|
||||
acronyms (OIDC, ABAC, CMK, CMDB, RPO, HITL, VCS, NFR) for the audience.
|
||||
|
||||
### Maturity framing
|
||||
|
||||
Every capability claim in a deck is tagged with one of three badges:
|
||||
@@ -296,7 +322,7 @@ attachments to the Gitea release.
|
||||
|
||||
## Current decks
|
||||
|
||||
| Deck | Source of truth (Step 1) | Marp deck (Step 2) | Rendered HTML (Step 3) | Talking points (Step 4) | Audience |
|
||||
|---|---|---|---|---|---|
|
||||
| How the Platform Works | `how-the-platform-works.md` | `how-the-platform-works-marp.md` | `how-the-platform-works.html` | `how-the-platform-works-talking-points.md` | CTO, Head of Cloud, Head of Infra, Head of DevOps |
|
||||
| The Developer Experience | `the-developer-experience.md` | `the-developer-experience-marp.md` | `the-developer-experience.html` | `the-developer-experience-talking-points.md` | CTO, Head of Cloud, Head of Infra, Head of DevOps |
|
||||
| Deck | Source of truth (Step 1) | Marp deck (Step 2) | Rendered HTML (Step 3) | Talking points (Step 4) | Slides | Audience |
|
||||
|---|---|---|---|---|---|---|
|
||||
| How the Platform Works | `how-the-platform-works.md` | `how-the-platform-works-marp.md` | `how-the-platform-works.html` | `how-the-platform-works-talking-points.md` | 10 main + 6 appendix | CTO, Head of Cloud, Head of Infra, Head of DevOps |
|
||||
| The Developer Experience | `the-developer-experience.md` | `the-developer-experience-marp.md` | `the-developer-experience.html` | `the-developer-experience-talking-points.md` | 10 main + 6 appendix | CTO, Head of Cloud, Head of Infra, Head of DevOps |
|
||||
@@ -1,7 +0,0 @@
|
||||
flowchart LR
|
||||
A["Technical developer"] --> C["Contract YAML"]
|
||||
B["Citizen developer<br/>(non-technical)"] --> D["Declares intent<br/>in natural language"]
|
||||
D --> E["Agent produces<br/>the contract"]
|
||||
C --> F["Same platform:<br/>resolve → check → plan →<br/>policy → confidence → apply"]
|
||||
E --> F
|
||||
F --> G["Same safety guarantees,<br/>same audit trail"]
|
||||
@@ -0,0 +1,21 @@
|
||||
flowchart LR
|
||||
subgraph UP ["Upstream — anything"]
|
||||
direction TB
|
||||
A["Technical dev\n(app code + contract)"]
|
||||
B["Citizen dev\n(intent → AI agent\n→ contract)"]
|
||||
end
|
||||
subgraph ACDL ["ACDL — infrastructure only"]
|
||||
C["Same contract\nSame pipeline\nSame safety"]
|
||||
D["Provision\nAWS resources"]
|
||||
E["Evidence\nhash-chained"]
|
||||
end
|
||||
subgraph DOWN ["Downstream"]
|
||||
F["AWS resources\nrunning"]
|
||||
G["Consumer pipeline\ndeploys image"]
|
||||
end
|
||||
A --> C
|
||||
B --> C
|
||||
C --> D
|
||||
C --> E
|
||||
D --> F
|
||||
F --> G
|
||||
@@ -0,0 +1,8 @@
|
||||
flowchart LR
|
||||
A["dev\n≥ 0.50\nautonomous"] -->|promotion| B["qa\n≥ 0.75\nQA attests"]
|
||||
B -->|promotion| C["prod\n≥ 0.90\nSRE attests"]
|
||||
C -->|promotion| D["dr\n≥ 0.95\nSRE + DR drill"]
|
||||
A -.->|"Testing\n(pilot-ready)"| A
|
||||
B -.->|"Planned"| B
|
||||
C -.->|"Planned"| C
|
||||
D -.->|"Planned"| D
|
||||
@@ -0,0 +1,25 @@
|
||||
flowchart LR
|
||||
subgraph UP ["Upstream — anything"]
|
||||
direction TB
|
||||
A["IDE / IDE + AI\n(dev writes contract)"]
|
||||
B["Agentic SDLC\n(agent writes contract)"]
|
||||
C["Citizen dev\n(vibe codes → AI agent\n→ contract)"]
|
||||
end
|
||||
subgraph ACDL ["ACDL — infrastructure only"]
|
||||
D["Contract\nvalidated"]
|
||||
E["Resolve → Plan\nSecurity + Policy checks\nConfidence signal"]
|
||||
F["Provision\nAWS resources"]
|
||||
G["Evidence\nhash-chained"]
|
||||
end
|
||||
subgraph DOWN ["Downstream"]
|
||||
H["AWS resources\nrunning"]
|
||||
I["Consumer pipeline\ndeploys image"]
|
||||
end
|
||||
A --> D
|
||||
B --> D
|
||||
C --> D
|
||||
D --> E
|
||||
E --> F
|
||||
E --> G
|
||||
F --> H
|
||||
H --> I
|
||||
@@ -0,0 +1,15 @@
|
||||
flowchart LR
|
||||
subgraph IN ["6 weighted inputs"]
|
||||
direction TB
|
||||
A["Policy\nconformance"]
|
||||
B["Validation"]
|
||||
C["Freshness"]
|
||||
D["Source\nprovenance"]
|
||||
E["History"]
|
||||
F["NFRs"]
|
||||
end
|
||||
IN --> G["Weighted sum\n→ Confidence score"]
|
||||
G --> H{"Threshold\ngate"}
|
||||
H -->|Meets threshold| I["Proceed"]
|
||||
H -->|Below threshold| J["Halt +\nexplainable reason"]
|
||||
H -->|Critical finding| J
|
||||
@@ -0,0 +1,13 @@
|
||||
flowchart LR
|
||||
A["Deployment arrives\nat env gate"] --> B["Confidence signal\ncomputed"]
|
||||
B --> C{"Meets\nthreshold?"}
|
||||
C -->|No / Critical| D["Halt —\nexplainable reason"]
|
||||
C -->|Yes| E{"Human attestation\nrequired?"}
|
||||
E -->|No — dev| F["Autonomous\nproceed"]
|
||||
E -->|Yes — qa/prod/dr| G["Approver reviews:\ncontract + plan + evidence"]
|
||||
G --> H{"Approver\ndecides"}
|
||||
H -->|Approve| I["Attestation recorded\n(identity + state)"]
|
||||
H -->|Reject| J["Halt — rejection\nextends audit chain"]
|
||||
I --> K["Deployment\nproceeds"]
|
||||
F --> K
|
||||
K --> L["Evidence written\nRPO=0"]
|
||||
@@ -0,0 +1,11 @@
|
||||
flowchart LR
|
||||
A["v1.0\nDEMO\ncomplete"] --> B["v1.1–v1.8\nPLATFORM BUILD\ncomplete"]
|
||||
B --> C["v1.9\nPRESENTATIONS + PATCHES\ncomplete"]
|
||||
C --> D["v1.10\nNEXT\nHITL wiring\nall-runner OIDC\nregulatory ledger"]
|
||||
D --> E["v2.0\nFUTURE\ncompliance milestone\nself-service\ndynamic modules\nengine adapters"]
|
||||
E --> F["North Star\nREALIZED\nfull autonomy (lower)\nattested (higher)\ncitizen dev live\nevidence regulatory-grade"]
|
||||
A -.->|"stub-driven proof"| A
|
||||
B -.->|"IR + OIDC + ABAC +\nmodule catalog +\nencryption + decommission"| B
|
||||
C -.->|"10-slide decks +\ntalking points +\nS&P theme"| C
|
||||
D -.->|"proposed phasing\nnot formally planned"| D
|
||||
E -.->|"proposed phasing\nnot formally planned"| E
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 38 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
@@ -18,7 +18,8 @@ style: |
|
||||
table { font-size: 18px; width: 100%; }
|
||||
th { background: #F0F0F0; }
|
||||
blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 20px; }
|
||||
img { display: block; margin: 0 auto; max-height: 320px; }
|
||||
img { display: block; margin: 0 auto; max-height: 300px; }
|
||||
em.story { color: #6B7280; font-size: 16px; font-style: italic; }
|
||||
.badge {
|
||||
display: inline-block; padding: 2px 8px; border-radius: 4px;
|
||||
font-size: 14px; font-weight: 600;
|
||||
@@ -44,6 +45,8 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top
|
||||
|
||||
# The Problem & The North Star
|
||||
|
||||
<em class="story">Story beat: Here's the problem we're solving and where we're going.</em>
|
||||
|
||||
Four frictions slow every team:
|
||||
|
||||
- **Cognitive load** — authoring infrastructure correctly; the long tail of services inconsistent in security and observability
|
||||
@@ -56,6 +59,17 @@ Four frictions slow every team:
|
||||
- A merged change progresses **without a platform engineer joining a thread or approving a ticket**
|
||||
- A **non-technical consumer** ships by declaring intent — no workflow, no config file, no infrastructure module
|
||||
- Every production change is **traceable to a human attestation and an immutable evidence stream**
|
||||
|
||||
---
|
||||
|
||||
# Where ACDL Sits in Your World
|
||||
|
||||
<em class="story">Story beat: Now that we know the problem, here's where ACDL fits — and where it doesn't.</em>
|
||||
|
||||
|
||||
|
||||
- **Upstream is anything** — your IDE, an agentic SDLC, or a citizen developer vibe coding on a laptop. ACDL doesn't care how the contract was produced.
|
||||
- **ACDL is infrastructure only** — it provisions and governs AWS resources. It does not build, test, or deploy your application code. That's upstream.
|
||||
- **Not a general-purpose AI** — autonomy is narrow, scoped to delivery, bounded by strict policy
|
||||
- **Not a permissive delivery highway** — no escape hatches to bypass the confidence framework
|
||||
|
||||
@@ -63,19 +77,23 @@ Four frictions slow every team:
|
||||
|
||||
# The Contract-Driven Model
|
||||
|
||||
A single YAML contract is all a consumer writes — **module, environment, inputs**. The platform owns everything else.
|
||||
<em class="story">Story beat: The contract is the boundary between upstream and ACDL. It's all a consumer writes.</em>
|
||||
|
||||
A single YAML contract — **module, environment, inputs**. The platform owns everything else.
|
||||
|
||||
|
||||
|
||||
- **Which module** — a catalog of pre-built, security-reviewed building blocks
|
||||
- **Which environment** — the platform raises the safety bar automatically as sensitivity rises
|
||||
- **Which inputs** — the handful of values that vary per deployment
|
||||
- The consumer provides **no AWS account, no VPC, no state backend, no runner key** — the platform owns the blast radius
|
||||
- **Which inputs** — infrastructure values that vary per deployment (cpu, memory, port, desired_count)
|
||||
- The consumer provides **no AWS account, no VPC, no state backend** — the platform owns the blast radius
|
||||
|
||||
---
|
||||
|
||||
# The End-to-End Flow
|
||||
|
||||
<em class="story">Story beat: Once the contract is written, here's what the platform does with it — every time.</em>
|
||||
|
||||
Every deployment runs the same stages, in the same order, with the same checks — no team-specific pipelines, no tribal runbooks.
|
||||
|
||||
|
||||
@@ -87,6 +105,8 @@ Every deployment runs the same stages, in the same order, with the same checks
|
||||
|
||||
# Zero-Trust by Default
|
||||
|
||||
<em class="story">Story beat: Before any infrastructure is created, here's how access is scoped.</em>
|
||||
|
||||
Consumer repositories hold **no long-lived cloud credentials.** Ever.
|
||||
|
||||
- **Authentication — OIDC federation.** Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. <span class="badge testing">Testing (GitHub Actions)</span> <span class="badge planned">Planned: all runners</span>
|
||||
@@ -100,25 +120,29 @@ Consumer repositories hold **no long-lived cloud credentials.** Ever.
|
||||
|
||||
# Safety is Computed, Not Assumed
|
||||
|
||||
Every delivery action produces a **measurable, explainable confidence signal** — the platform's certified answer to *"is this safe to proceed?"* <span class="badge agentic">Agentic</span>
|
||||
<em class="story">Story beat: Now let's look at how the platform decides whether a deployment is safe.</em>
|
||||
|
||||
- **Six weighted inputs:** policy conformance, validation, freshness, source provenance, history, NFRs
|
||||
Every delivery action produces a **measurable, explainable confidence signal** — a weighted sum of observable facts, not a black box. <span class="badge agentic">Agentic</span>
|
||||
|
||||
|
||||
|
||||
- **Six weighted inputs** — manually tuned, auditable. If a consumer asks "why 0.62?", the platform answers with a per-input breakdown
|
||||
- **Per-environment thresholds** that rise with sensitivity:
|
||||
|
||||
| Environment | Threshold | Attester |
|
||||
|---|---|---|
|
||||
| dev | ≥ 0.50 | No one — autonomous |
|
||||
| qa | ≥ 0.75 | QA |
|
||||
| prod | ≥ 0.90 | SRE |
|
||||
| dr | ≥ 0.95 | SRE + DR drill |
|
||||
| dev | ≥ 0.50 | No one — autonomous <span class="badge testing">Testing</span> |
|
||||
| qa | ≥ 0.75 | QA <span class="badge planned">Planned</span> |
|
||||
| prod | ≥ 0.90 | SRE <span class="badge planned">Planned</span> |
|
||||
|
||||
- **A single critical finding hard-blocks the deployment** — critical findings are not averaged away
|
||||
- **When the platform halts, it gives a measured reason** — never an opaque debugging exercise
|
||||
- **A single critical finding hard-blocks** — critical findings are not averaged away
|
||||
|
||||
---
|
||||
|
||||
# Security by Construction
|
||||
|
||||
<em class="story">Story beat: Beyond the confidence signal, security defaults are on by construction — not by opt-in.</em>
|
||||
|
||||
Security defaults that **do not require a team to opt in.** Checks run on **every** deployment, normalized to a single schema. <span class="badge testing">Testing</span>
|
||||
|
||||
- **Policy checks** (Checkov, Wiz, Kyverno) — secrets in plaintext, public ingress, IAM wildcards, **required tagging standards** — all run *before* infra is created
|
||||
@@ -130,13 +154,15 @@ Security defaults that **do not require a team to opt in.** Checks run on **ever
|
||||
|
||||
# Accountability & Audit
|
||||
|
||||
Autonomy and accountability are **not in tension** — they apply at different environments.
|
||||
<em class="story">Story beat: Computed safety handles the gate. But humans still matter — here's how accountability works.</em>
|
||||
|
||||
- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate. Queue-based handoffs are eliminated. <span class="badge agentic">Agentic</span>
|
||||
- **qa, prod, dr require deliberate human attestation** — policy-mandated acts of accountability, not rubber stamps
|
||||
- **Separation of duties is enforced** — the QA approver **cannot** be the prod approver. The platform **blocks on a match.** <span class="badge testing">Design tested</span> <span class="badge planned">Wiring: planned</span>
|
||||
- **Every deployment writes a hash-chained evidence event** — tampering breaks the chain. **RPO = 0** — the evidence write is synchronous <span class="badge testing">Testing</span>
|
||||
- **Every production change is traceable to a human attestation** — the only durable record outside the VCS's audit log
|
||||
|
||||
|
||||
- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate. <span class="badge testing">Testing</span> <span class="badge agentic">Agentic</span>
|
||||
- **qa, prod, dr require human attestation** — the approver reviews the contract, the planned Terraform changes, and the accumulated evidence <span class="badge planned">Planned</span>
|
||||
- **QA attests to infrastructure readiness, not application code** — the contract, the plan, and the evidence. Application code review is upstream
|
||||
- **Separation of duties** — the QA approver **cannot** be the prod approver. The platform **blocks on a match.** <span class="badge planned">Planned</span>
|
||||
- **Every deployment writes a hash-chained evidence event** — tampering breaks the chain. **RPO = 0** <span class="badge testing">Testing</span>
|
||||
|
||||
---
|
||||
|
||||
@@ -145,9 +171,112 @@ Autonomy and accountability are **not in tension** — they apply at different e
|
||||
|
||||
# Testing vs. Planned
|
||||
|
||||
<em class="story">Story beat: Let's be honest about what works today and what's on the roadmap.</em>
|
||||
|
||||
<style>
|
||||
section { font-size: 16px; }
|
||||
td { font-size: 15px; vertical-align: top; }
|
||||
section { font-size: 20px; }
|
||||
</style>
|
||||
|
||||
**11 capabilities testing today** (dev pilot-ready):
|
||||
|
||||
- Contract-driven deploys · Module catalog · Zero-trust OIDC + ABAC
|
||||
- Security + policy checks before infra creation · Confidence signal gating
|
||||
- Hash-chained evidence outbox (RPO = 0) · Encryption by default + per-stack CMKs
|
||||
- Deletion protection + safe decommission · Uptime monitoring
|
||||
- Platform-managed environments · Engine-agnostic core + VCS-agnostic ingestion
|
||||
|
||||
**9 planned** (production path):
|
||||
|
||||
- HITL wiring for qa/prod/dr · All-runner OIDC · Full regulatory ledger
|
||||
- Compliance milestone (GDPR, SOX, SOC2, DORA) · Environment self-service
|
||||
- Dynamic module creation <span class="badge agentic">Agentic</span> · Pattern recognition <span class="badge agentic">Agentic</span>
|
||||
- Additional engine adapters · Deeper observability bootstrap
|
||||
|
||||
*Full inventory + phased roadmap in the appendix.*
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# The Vision Realized
|
||||
|
||||
<em class="story">Story beat: Here's what success looks like when the North Star is reached.</em>
|
||||
|
||||
- **Velocity without sacrificing safety.** Speed is in the ergonomics (a simple contract, a one-line `uses:`); safety is in the gates the consumer cannot bypass.
|
||||
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation.
|
||||
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event.
|
||||
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
|
||||
- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it.
|
||||
- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer. <span class="badge agentic">Agentic</span>
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Appendix
|
||||
|
||||
<em class="story">For deep dives — these slides cover details omitted from the main 10.</em>
|
||||
|
||||
**Contents:**
|
||||
|
||||
1. Platform-Managed Environments (detail)
|
||||
2. Observability Built In (detail)
|
||||
3. The Road to the North Star (phased roadmap)
|
||||
4. Testing vs. Planned (full inventory)
|
||||
5. Glossary
|
||||
|
||||
---
|
||||
|
||||
# A1 — Platform-Managed Environments
|
||||
|
||||
A consumer provides **no AWS account, no VPC, no subnet, no state backend, no runner key.** The platform owns the blast radius.
|
||||
|
||||
A named environment is a platform-owned bundle of:
|
||||
|
||||
- An AWS account (or a scoped partition of one)
|
||||
- A network (VPC + subnets)
|
||||
- A state backend (S3 + DynamoDB for state + locking)
|
||||
- An IAM role surfaced via ABAC, scoped to the consumer's identity and resource tags
|
||||
|
||||
The consumer selects an environment **by name** in their contract. The platform resolves the name to the underlying resources at run time. **The consumer never sees raw credentials.**
|
||||
|
||||
**Friendly onboarding:** the first run detects no environment and emits a guided prompt (not an opaque failure). <span class="badge testing">Testing</span> <span class="badge planned">Self-service: planned</span>
|
||||
|
||||
---
|
||||
|
||||
# A2 — Observability Built In
|
||||
|
||||
Monitoring is **a platform default, not a per-team project.** <span class="badge testing">Testing</span>
|
||||
|
||||
- **Uptime monitoring deployed automatically with every stack** — a dedicated monitoring instance is provisioned after any module deploy, in a separate state, with a feature flag to disable
|
||||
- **Monitored endpoints passed from the deployment's own outputs** — no manual endpoint registration
|
||||
- **Alert channels:** Microsoft Teams webhook, email, SMS, and GitHub issues
|
||||
- **The uptime URL is published to the developer** via a PR comment — they don't hunt for it
|
||||
- **Roadmap:** deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields <span class="badge planned">Planned</span>
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# A3 — The Road to the North Star
|
||||
|
||||
*Proposed phasing — not formally planned.*
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# A4 — Testing vs. Planned (Full Inventory)
|
||||
|
||||
<style>
|
||||
section { font-size: 15px; }
|
||||
td { font-size: 14px; vertical-align: top; }
|
||||
ul { margin: 0; padding-left: 1.2em; }
|
||||
li { margin-bottom: 2px; }
|
||||
</style>
|
||||
@@ -156,7 +285,7 @@ li { margin-bottom: 2px; }
|
||||
<tr>
|
||||
<td style="width: 52%; border: none; padding-right: 12px;">
|
||||
|
||||
**Testing** (works internally, not yet released to consumers)
|
||||
**Testing** (works internally, dev pilot-ready)
|
||||
|
||||
- Contract-driven deploys with a versioned reusable workflow
|
||||
- Module catalog (primitives + modules) with validated examples
|
||||
@@ -191,14 +320,16 @@ li { margin-bottom: 2px; }
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
# A5 — Glossary
|
||||
|
||||
# The Vision Realized
|
||||
|
||||
- **Velocity without sacrificing safety.** Speed is in the ergonomics (a simple contract, a one-line `uses:`); safety is in the gates the consumer cannot bypass.
|
||||
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
|
||||
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event.
|
||||
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
|
||||
- **Infrastructure as a utility, not a craft.** The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it.
|
||||
- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer — expanding who can ship safely without lowering the bar. <span class="badge agentic">Agentic</span>
|
||||
| Term | Meaning |
|
||||
|---|---|
|
||||
| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
|
||||
| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
|
||||
| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
|
||||
| **CMDB** | Configuration Management Database — validates change requests for decommission |
|
||||
| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
|
||||
| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
|
||||
| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
|
||||
| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
|
||||
| **IR** | Intermediate Representation — the engine-agnostic stack definition between contract and Terraform |
|
||||
File diff suppressed because one or more lines are too long
@@ -20,7 +20,8 @@ style: |
|
||||
blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 20px; }
|
||||
pre { font-size: 14px; line-height: 1.3; }
|
||||
code { font-size: 14px; }
|
||||
img { display: block; margin: 0 auto; max-height: 300px; }
|
||||
img { display: block; margin: 0 auto; max-height: 280px; }
|
||||
em.story { color: #6B7280; font-size: 16px; font-style: italic; }
|
||||
.badge {
|
||||
display: inline-block; padding: 2px 8px; border-radius: 4px;
|
||||
font-size: 14px; font-weight: 600;
|
||||
@@ -44,24 +45,26 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top
|
||||
|
||||
---
|
||||
|
||||
# Two Consumer Surfaces, One Platform
|
||||
# Where ACDL Sits in Your World
|
||||
|
||||
The platform serves **two kinds of consumer** — both converge on the **same contract, the same policy envelope, and the same evidence stream.**
|
||||
<em class="story">Story beat: Here's who uses the platform and where the boundary is.</em>
|
||||
|
||||
|
||||
|
||||
|
||||
- **Technical developer** — owns app code + a contract + a thin CI definition
|
||||
- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope <span class="badge agentic">Agentic</span>
|
||||
|
||||
The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.
|
||||
- **Upstream is anything** — your IDE, an agentic SDLC, or vibe coding on a laptop. ACDL doesn't care how the contract was produced
|
||||
- **ACDL is infrastructure only** — it provisions and governs AWS resources. Application deployment is upstream
|
||||
|
||||
---
|
||||
|
||||
# The Contract — The Entire Consumer Surface
|
||||
|
||||
<em class="story">Story beat: Now let's look at what a consumer actually writes — it's tiny.</em>
|
||||
|
||||
Three things. That is the entire consumer-side surface.
|
||||
|
||||
<img src="assets/png/developer-experience-02-what-dev-does.png" style="float: right; width: 40%; margin-left: 20px; margin-bottom: 10px;" />
|
||||
<img src="assets/png/developer-experience-02-what-dev-does.png" style="float: right; width: 38%; margin-left: 20px; margin-bottom: 10px;" />
|
||||
|
||||
- **1. App code** — the consumer's service, at the top level of the repo
|
||||
- **2. A contract** — a single YAML file: module, environment, inputs
|
||||
@@ -71,7 +74,9 @@ uses: acdl/pipelines/deploy.yaml@v1.6
|
||||
module: microservice
|
||||
environment: dev
|
||||
inputs:
|
||||
image: my-registry/my-microservice:latest
|
||||
cpu: 256
|
||||
memory: 512
|
||||
desired_count: 2
|
||||
port: 8080
|
||||
```
|
||||
|
||||
@@ -82,7 +87,9 @@ inputs:
|
||||
|
||||
# The Developer Feedback Loop
|
||||
|
||||
Developers see **what the platform is doing**, in real time, in their own run logs. <span class="badge testing">Testing</span>
|
||||
<em class="story">Story beat: Once you push, here's what you see — in real time, in your own logs.</em>
|
||||
|
||||
Developers see **what the platform is doing**, in real time. <span class="badge testing">Testing</span>
|
||||
|
||||
- **Streamed output by default** — the infrastructure plan, policy-check results, and each check record flow to stdout
|
||||
- **PR comments after every successful pipeline stage** — a developer always knows where they stand without refreshing a dashboard
|
||||
@@ -95,6 +102,8 @@ Developers see **what the platform is doing**, in real time, in their own run lo
|
||||
|
||||
# Versioned, Predictable Releases
|
||||
|
||||
<em class="story">Story beat: You control when you absorb platform improvements — no surprise upgrades.</em>
|
||||
|
||||
Consumers control **when** they absorb platform improvements. <span class="badge testing">Testing</span>
|
||||
|
||||
- **Floating MAJOR + MINOR tags** (e.g. `@v1.6`) — a consumer automatically receives patch updates within the line
|
||||
@@ -107,6 +116,8 @@ Consumers control **when** they absorb platform improvements. <span class="badge
|
||||
|
||||
# Friendly Onboarding
|
||||
|
||||
<em class="story">Story beat: First impressions matter — the platform fails gracefully, not opaquely.</em>
|
||||
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully. <span class="badge testing">Testing</span>
|
||||
|
||||
When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely:
|
||||
@@ -124,13 +135,17 @@ The pipeline then **exits without attempting a deployment** — no partial state
|
||||
|
||||
# Safe Promotion Path
|
||||
|
||||
The contract is environment-agnostic by design. Promotion is **a workflow choice, not a contract edit** — the platform raises the bar automatically.
|
||||
<em class="story">Story beat: Promotion is a workflow choice, not a contract edit — and the bar rises automatically.</em>
|
||||
|
||||
The contract is environment-agnostic. The platform raises the bar automatically.
|
||||
|
||||
|
||||
|
||||
<table style="width: 100%; border: none;">
|
||||
<tr>
|
||||
<td style="width: 50%; vertical-align: top; border: none; padding-right: 12px;">
|
||||
|
||||
**Approach A — One contract, one job per environment.** The environment is passed by each job and interpolated at runtime.
|
||||
**Approach A — One contract, one job per environment.** Environment passed by each job.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -146,7 +161,7 @@ jobs:
|
||||
</td>
|
||||
<td style="width: 50%; vertical-align: top; border: none; padding-left: 12px;">
|
||||
|
||||
**Approach B — Environment-specific contracts.** When inputs genuinely differ, each job points at its own contract file.
|
||||
**Approach B — Environment-specific contracts.** When inputs differ per environment.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -163,25 +178,20 @@ jobs:
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
| Environment | What the platform adds |
|
||||
|---|---|
|
||||
| dev | Confidence ≥ 0.50, fully autonomous <span class="badge agentic">Agentic</span> |
|
||||
| qa | QA human attestation + confidence ≥ 0.75 |
|
||||
| prod | SRE human attestation + confidence ≥ 0.90 |
|
||||
|
||||
<style>
|
||||
section { font-size: 16px; }
|
||||
pre { font-size: 10px; line-height: 1.2; }
|
||||
code { font-size: 10px; }
|
||||
td { font-size: 14px; }
|
||||
table { font-size: 14px; }
|
||||
</style>
|
||||
|
||||
---
|
||||
|
||||
# Safe Decommission
|
||||
|
||||
Tearing down a stack is **as deliberate as deploying one** — and just as gated. <span class="badge testing">Testing</span>
|
||||
<em class="story">Story beat: Tearing down is as deliberate as deploying — and just as gated.</em>
|
||||
|
||||
Tearing down a stack is **as deliberate as deploying one.** <span class="badge testing">Testing</span>
|
||||
|
||||
```yaml
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.8
|
||||
@@ -202,12 +212,14 @@ The per-stack encryption key enters a **grace window** (default 30 days) so encr
|
||||
|
||||
# Self-Service Module Catalog
|
||||
|
||||
Developers pick from **pre-built, security-reviewed building blocks** — they don't author infrastructure from scratch. <span class="badge testing">Testing</span>
|
||||
<em class="story">Story beat: You don't author infrastructure — you pick from pre-built, security-reviewed building blocks.</em>
|
||||
|
||||
Developers pick from **pre-built, security-reviewed building blocks.** <span class="badge testing">Testing</span>
|
||||
|
||||
- **Primitives** — single-purpose resources (S3, VPC, ECS, IAM, load balancer, container registry, CloudFront, WAF, RDS), each with documented inputs/outputs, usage, compliance extension points, and versioning
|
||||
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry)
|
||||
- **Validated examples per module** — `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently
|
||||
- **Auto-promotion of patterns** — a thin-composition layer is auto-promoted to the catalog after 3 observed usages <span class="badge planned">Planned</span> <span class="badge agentic">Agentic</span>
|
||||
- **Auto-promotion of patterns** — auto-promoted to the catalog after 3 observed usages <span class="badge planned">Planned</span> <span class="badge agentic">Agentic</span>
|
||||
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in <span class="badge planned">Planned</span>
|
||||
|
||||
---
|
||||
@@ -217,10 +229,97 @@ Developers pick from **pre-built, security-reviewed building blocks** — they d
|
||||
|
||||
# The Desired Outcomes
|
||||
|
||||
<em class="story">Story beat: Here's what this delivers to the organization.</em>
|
||||
|
||||
- **Velocity without sacrificing safety.** Speed is in the ergonomics (a simple contract, a one-line `uses:`); safety is in the gates the consumer cannot bypass.
|
||||
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
|
||||
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation.
|
||||
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event.
|
||||
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
|
||||
- **The bottleneck moves off the platform team's ticket queue.** A merged change progresses through lower environments without a platform engineer joining a thread.
|
||||
- **Infrastructure as a utility, not a craft.** The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
|
||||
- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer — expanding who can ship safely without lowering the bar. <span class="badge agentic">Agentic</span>
|
||||
- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
|
||||
- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer. <span class="badge agentic">Agentic</span>
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Appendix
|
||||
|
||||
<em class="story">For deep dives — these slides cover details omitted from the main 10.</em>
|
||||
|
||||
**Contents:**
|
||||
|
||||
1. The Citizen Developer Experience (full)
|
||||
2. No Platform Code, No Cloning (detail)
|
||||
3. Local Reproducibility (detail)
|
||||
4. The Road to the North Star (phased roadmap)
|
||||
5. Glossary
|
||||
|
||||
---
|
||||
|
||||
# A1 — The Citizen Developer Experience
|
||||
|
||||
A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module.
|
||||
|
||||
- The consumer opens an issue describing what they need (e.g. "a web API for the pricing service")
|
||||
- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog**
|
||||
- The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion
|
||||
|
||||
**Guardrails that make this safe:**
|
||||
|
||||
- Skills are **versioned, signed, and reviewed for sensitive data before release** (Infra & Ops owns the review)
|
||||
- Agents are **stateless** — all state lives in the platform; the platform trusts and **always verifies**
|
||||
- The agent's trace and submission confidence are captured in the contract for review
|
||||
|
||||
<span class="badge planned">Skill catalog + real agent runtime: planned</span> <span class="badge agentic">Agentic</span>
|
||||
|
||||
---
|
||||
|
||||
# A2 — No Platform Code, No Cloning
|
||||
|
||||
Consumers `uses:` a **versioned** central workflow. The platform fetches itself at run time. The consumer **never touches platform internals.**
|
||||
|
||||
|
||||
|
||||
- The consumer's CI definition is a thin wrapper — one `uses:` line
|
||||
- The runner checks out the consumer repo, then checks out the platform repo into the workspace
|
||||
- The platform installs its own runtime dependencies — the consumer installs nothing
|
||||
- When the platform ships a fix, every consumer on a floating tag gets it on their next run
|
||||
|
||||
---
|
||||
|
||||
# A3 — Local Reproducibility
|
||||
|
||||
The entire CI pipeline runs **from the shell**, not just in CI. <span class="badge testing">Testing</span>
|
||||
|
||||
- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence
|
||||
- `scripts/run_platform.sh --check-only` runs the platform **offline** — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing
|
||||
- `--plan-only` runs through the infrastructure plan without applying
|
||||
- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# A4 — The Road to the North Star
|
||||
|
||||
*Proposed phasing — not formally planned.*
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# A5 — Glossary
|
||||
|
||||
| Term | Meaning |
|
||||
|---|---|
|
||||
| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
|
||||
| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
|
||||
| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
|
||||
| **CMDB** | Configuration Management Database — validates change requests for decommission |
|
||||
| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
|
||||
| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
|
||||
| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
|
||||
| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
|
||||
@@ -1,6 +1,6 @@
|
||||
# The Developer Experience — Talking Points
|
||||
|
||||
> **Companion to:** `the-developer-experience-marp.md` (10 slides)
|
||||
> **Companion to:** `the-developer-experience-marp.md` (10 main + 6 appendix = 16 slides)
|
||||
> **Content source:** `the-developer-experience.md` (full source of truth with speaker notes)
|
||||
> **Purpose:** Presenter-ready cues — 3-6 talking points per slide + the one key takeaway the audience should remember.
|
||||
> **Audience:** Senior Leadership — CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
@@ -17,15 +17,16 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — Two Consumer Surfaces, One Platform
|
||||
## Slide 2 — Where ACDL Sits in Your World
|
||||
|
||||
**Talking points:**
|
||||
- This is the thesis of the deck — the two surfaces are *parallel*, not a progression. A citizen developer doesn't "graduate" to the developer surface
|
||||
- Both produce a contract; both get the same treatment. The platform is opinionated in what it accepts, regardless of who is declaring
|
||||
- The leadership takeaway: we expand who can ship safely without lowering the bar. There is no "citizen developer mode" with weaker checks
|
||||
- The citizen developer surface is agentic — an AI agent produces a contract that passes the same safety envelope as a senior engineer's. Be honest: the skill catalog and real agent runtime are planned
|
||||
- This is the scope-boundary slide — here's who uses the platform, and here's where ACDL's responsibility starts and stops
|
||||
- Two consumer paths converge on the same contract: **technical** developer writes the contract directly; **citizen** developer declares intent and an AI agent produces a contract that passes the same safety envelope
|
||||
- Upstream is anything — your IDE, an agentic SDLC, or vibe coding on a laptop. ACDL doesn't care how the contract was produced
|
||||
- ACDL is infrastructure only — it provisions and governs AWS resources. Application deployment is upstream of the contract
|
||||
- The two surfaces are *parallel*, not a progression. A citizen developer doesn't "graduate" to the developer surface. There is no "citizen developer mode" with weaker checks
|
||||
|
||||
**Key takeaway:** Two consumer surfaces, one safety envelope. No weaker mode for non-technical users.
|
||||
**Key takeaway:** Two consumer paths, one safety envelope. ACDL is infra only — anything upstream is fair game.
|
||||
|
||||
---
|
||||
|
||||
@@ -34,9 +35,9 @@
|
||||
**Talking points:**
|
||||
- Hold this slide — the audience should sit with how small the consumer surface is. Three things: app code, a contract, a one-line CI definition
|
||||
- The contract is a single YAML file: module, environment, inputs. That's the entire consumer-facing interface to production
|
||||
- The contract example now shows **infrastructure inputs** (cpu, memory, desired_count, port) — not an `image:` field. The consumer declares capacity and shape; the platform resolves the rest
|
||||
- Walk the "does not" list quickly — no infrastructure modules, no platform repo cloning, no cloud credentials, no state backends. Every item is a category of toil the platform removes
|
||||
- For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue
|
||||
- The consumer never touches platform internals — the platform fetches itself at run time. When the platform ships a fix, every consumer on a floating tag gets it on their next run
|
||||
|
||||
**Key takeaway:** Three things. That's the entire consumer-side surface. Everything else is the platform's job.
|
||||
|
||||
@@ -46,9 +47,9 @@
|
||||
|
||||
**Talking points:**
|
||||
- This directly answers "but developers hate platforms that hide what they're doing" — the platform is opinionated about *what* runs, not *opaque* about *that* it runs
|
||||
- Streamed output by default — the plan, policy results, and each check record flow to stdout. A `--quiet` mode exists for log-only contexts
|
||||
- Streamed output by default — the plan, policy results, and each check record flow to stdout
|
||||
- PR comments after every successful pipeline stage — a developer always knows where they stand without refreshing a dashboard
|
||||
- Connection strings posted as PR comments — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store, never to logs
|
||||
- Connection strings posted as PR comments — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store (KMS-encrypted, namespaced), never to logs
|
||||
- The "errors become GitHub issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line
|
||||
- Clear, explainable halt reasons — a policy violation, an insufficient confidence signal, or a missing attestation. Never an opaque debugging exercise
|
||||
|
||||
@@ -76,7 +77,6 @@
|
||||
- First impressions of a platform are made when it fails for the first time. The platform fails gracefully with a guided prompt, not an opaque error
|
||||
- The prompt tells the consumer: what's missing, what the platform will provision, the expected turnaround, and how to request an environment
|
||||
- The pipeline exits without attempting a deployment — no partial state, no confusing errors
|
||||
- Both onboarding paths end in a sandbox dev submission that must pass the confidence gate before the consumer is promoted
|
||||
- Be honest: the citizen developer onboarding path is planned, not yet shipped
|
||||
|
||||
**Key takeaway:** The platform fails gracefully. First impressions drive adoption — platforms that fail opaquely get routed around.
|
||||
@@ -87,11 +87,11 @@
|
||||
|
||||
**Talking points:**
|
||||
- Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract
|
||||
- The new promotion journey diagram shows the rising bar: dev (autonomous) → qa (QA attests) → prod (SRE attests) → dr (SRE attests + DR drill)
|
||||
- Approach A (one contract, environment passed by the job) keeps the single source of truth — the contract never changes
|
||||
- Approach B (environment-specific contracts) lets teams whose inputs genuinely vary keep that variation explicit and reviewable
|
||||
- The platform raises the bar automatically: dev ≥ 0.50 (autonomous) → qa ≥ 0.75 (QA attests) → prod ≥ 0.90 (SRE attests). The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar
|
||||
- Separation of duties is enforced — the QA approver cannot be the prod approver. Be honest: design is tested, wiring for qa/prod/dr is planned
|
||||
- No staging environment — the design deliberately removes the "staging is basically prod but not really" anti-pattern
|
||||
- The rising bar is annotated with maturity: **dev = Testing** (works internally, pilot-ready); **qa/prod/dr = Planned** (on the roadmap). Be honest about that split
|
||||
- Separation of duties is enforced — the QA approver cannot be the prod approver. No staging environment — the design deliberately removes the "staging is basically prod but not really" anti-pattern
|
||||
|
||||
**Key takeaway:** Change the environment field, not the contract. The platform raises the bar automatically. The consumer can't bypass the gates.
|
||||
|
||||
@@ -105,7 +105,6 @@
|
||||
- Two SRE human-attestation gates: one to disable deletion protection, a second to zero counts and destroy
|
||||
- The per-stack encryption key enters a 30-day grace window so encrypted data remains recoverable — the key is permanently deleted only after the window expires
|
||||
- For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible
|
||||
- Uptime monitoring is not automatically destroyed — it can be left running to watch decommissioned endpoints go dark
|
||||
|
||||
**Key takeaway:** Tearing down is as gated as deploying. Two SRE approvals, CMDB-validated change request, 30-day key grace window.
|
||||
|
||||
@@ -136,4 +135,81 @@
|
||||
- Infrastructure as a utility, not a craft — teams consume, they don't maintain. The platform compounds value over time by learning from recurring patterns
|
||||
- The path to the citizen developer — the same safety envelope that serves a senior engineer will serve a non-technical consumer. Expanding who can ship safely without lowering the bar
|
||||
|
||||
**Key takeaway:** Velocity without sacrificing safety. Security and auditability as byproducts. The bottleneck moves off the platform team's queue.
|
||||
**Key takeaway:** Velocity without sacrificing safety. Security and auditability as byproducts. The bottleneck moves off the platform team's queue.
|
||||
|
||||
---
|
||||
|
||||
## Appendix — Contents
|
||||
|
||||
**Talking points:**
|
||||
- These are backup slides for Q&A — don't walk through them in the main talk unless time permits
|
||||
- Use A1 when asked about the citizen developer detail; A2 for the no-cloning mechanism; A3 for local reproducibility; A4 for the roadmap; A5 for term definitions
|
||||
|
||||
**Key takeaway:** The appendix is the deep-dive drawer. Pull a slide when the audience asks for the detail behind a main-slide claim.
|
||||
|
||||
---
|
||||
|
||||
## A1 — The Citizen Developer Experience
|
||||
|
||||
**Talking points:**
|
||||
- The framing is **vibe coding on a laptop** — the consumer describes what they want in plain language; an AI agent turns that into a contract the platform treats identically to a senior engineer's
|
||||
- The consumer opens an issue (e.g. "a web API for the pricing service"); an AI agent maps the intent to a contract referencing a module from the reviewed skill catalog
|
||||
- The contract enters the same pipeline and must clear the same confidence gate — no weaker mode
|
||||
- Guardrails: skills are versioned, signed, and reviewed for sensitive data before release (Infra & Ops owns the review); agents are stateless — all state lives in the platform; the platform trusts and always verifies
|
||||
- The agent's trace and submission confidence are captured in the contract (`profile: agentic`), so a reviewer can see how the contract was produced
|
||||
- Be honest about maturity: the mechanism is designed and stub-proven; the full skill catalog and real agent runtime are planned
|
||||
|
||||
**Key takeaway:** Vibe coding on a laptop — but every submission passes the same safety envelope. The agent produces the contract; the platform verifies it.
|
||||
|
||||
---
|
||||
|
||||
## A2 — No Platform Code, No Cloning
|
||||
|
||||
**Talking points:**
|
||||
- The consumer's CI definition is a thin wrapper — one `uses:` line pointing at a versioned tag. That's the only coupling
|
||||
- The runner checks out the consumer repo, then checks out the platform repo into the workspace. The platform installs its own runtime dependencies — the consumer installs nothing
|
||||
- The consumer never clones the platform repo, never invokes platform scripts locally (optional `--check-only` validation is available but not required)
|
||||
- When the platform ships a fix, every consumer on a floating MAJOR.MINOR tag gets it on their next run — no per-repo upgrade project
|
||||
- For the Head of Cloud: there is no "platform code in every consumer repo" problem. The version-pinned `uses:` line is the only coupling, and it updates itself within the line
|
||||
|
||||
**Key takeaway:** One `uses:` line is the only coupling. The platform fetches itself at run time. No per-repo upgrade projects.
|
||||
|
||||
---
|
||||
|
||||
## A3 — Local Reproducibility
|
||||
|
||||
**Talking points:**
|
||||
- The entire CI pipeline runs from the shell, not just in CI — no "works on my machine, fails in CI" gap
|
||||
- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence
|
||||
- `scripts/run_platform.sh --check-only` runs the platform offline — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing
|
||||
- `--plan-only` runs through the infrastructure plan without applying
|
||||
- The CI and deploy pipelines are defined by declarative contracts (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement
|
||||
|
||||
**Key takeaway:** Validate offline, plan offline, push when confident. The same declarative contract drives local tooling and CI.
|
||||
|
||||
---
|
||||
|
||||
## A4 — The Road to the North Star
|
||||
|
||||
**Talking points:**
|
||||
- Call this out explicitly: **proposed phasing, not formally planned** — don't let the audience read it as a commitment
|
||||
- Phase 1 is what's tested today — core platform (contract, catalog, evidence)
|
||||
- Phase 2 is the next milestone — safe promotion wiring for qa/prod/dr
|
||||
- Phase 3 introduces the agentic surface — skill catalog + agents
|
||||
- Phase 4 is the north star — citizen developer GA on the same safety envelope
|
||||
- Use this slide only when an audience member asks "how do you get from here to there"
|
||||
|
||||
**Key takeaway:** A proposed path from the tested core to the citizen developer north star — proposed phasing, not formally planned.
|
||||
|
||||
---
|
||||
|
||||
## A5 — Glossary
|
||||
|
||||
**Talking points:**
|
||||
- Keep this slide in your back pocket for the audience member who asks "what does ABAC actually mean?" — don't read it aloud
|
||||
- OIDC = short-lived federation tokens, no long-lived credentials; ABAC = access scoped by resource tags + repo identity, not roles
|
||||
- CMK = per-stack encryption key, 90-day rotation; CMDB = validates change requests for decommission
|
||||
- RPO = 0 means evidence written synchronously, no data loss; HITL = deliberate human attestation for qa/prod/dr
|
||||
- VCS = the git hosting platform (GitHub, Gitea, GitLab); NFR = encryption, tagging, observability standards
|
||||
|
||||
**Key takeaway:** The deck uses real security and ops vocabulary. The glossary is the cheat sheet for the audience member who wants the definitions.
|
||||
File diff suppressed because one or more lines are too long
@@ -2,45 +2,67 @@
|
||||
|
||||
> **Subtitle:** Agentic Cloud Delivery Platform
|
||||
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
> **Length:** ~15 minutes · 13 slides
|
||||
> **Length:** ~15 minutes · 10 main + 6 appendix = 16 slides
|
||||
> **Purpose:** Sell the developer experience and the citizen developer experience to tech leadership — velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.
|
||||
> **Maturity framing:** "Testing" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
|
||||
> **Maturity framing:** "Testing" = works internally, dev pilot-ready. "Planned" = on the roadmap. "Agentic" = involves AI agents or autonomous decision-making.
|
||||
|
||||
---
|
||||
|
||||
## Slide 1 — Two Consumer Surfaces, One Platform
|
||||
## Slide 1 — Title
|
||||
|
||||
The platform serves **two kinds of consumer** through two coordinated interfaces — but both converge on the **same contract, the same policy envelope, and the same evidence stream.**
|
||||
The consumer surface is intentionally tiny. The platform's surface is large and opinionated.
|
||||
|
||||
> **Speaker notes:** Brief introduction — this deck covers *who uses the platform and how fast/safe they ship*, not the internal mechanics (that's the companion deck). Set the frame: velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — Where ACDL Sits in Your World
|
||||
|
||||
Story beat: Here's who uses the platform and where the boundary is.
|
||||
|
||||
The platform serves **two kinds of consumer** through two coordinated paths — but both converge on the **same contract, the same policy envelope, and the same evidence stream.**
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["Technical developer"] --> C["Contract YAML"]
|
||||
B["Citizen developer<br/>(non-technical)"] --> D["Declares intent in<br/>natural language"]
|
||||
D --> E["Agent produces<br/>the contract"]
|
||||
C --> F["Same platform:<br/>resolve → check → plan → policy<br/>→ confidence → evidence → apply"]
|
||||
E --> F
|
||||
F --> G["Same safety guarantees,<br/>same audit trail"]
|
||||
U1["Anything upstream<br/>(IDE / agentic SDLC / vibe coding)"] --> T["Technical developer<br/>writes app + contract"]
|
||||
U1 --> C["Citizen developer<br/>declares intent"]
|
||||
T --> K["Contract YAML"]
|
||||
C --> AI["An AI agent maps intent<br/>to a reviewed-skill contract"]
|
||||
AI --> K
|
||||
K --> ACDL["ACDL — infrastructure only<br/>resolve → check → plan → policy<br/>→ confidence → evidence → apply"]
|
||||
ACDL --> AWS["AWS resources provisioned + governed"]
|
||||
```
|
||||
|
||||
- **Technical developer** — owns app code + a contract + a thin CI definition. Uses the full module catalog and inputs.
|
||||
- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope as a senior engineer's.
|
||||
- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope as a senior engineer's. <span class="badge agentic">Agentic</span>
|
||||
- **Upstream is anything** — your IDE, an agentic SDLC, or vibe coding on a laptop. ACDL doesn't care how the contract was produced.
|
||||
- **ACDL is infrastructure only** — it provisions and governs AWS resources. Application deployment is upstream.
|
||||
|
||||
The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.
|
||||
|
||||
> **Speaker notes:** This is the thesis of the deck. The two surfaces are *parallel*, not a progression — a citizen developer doesn't "graduate" to the developer surface. Both produce a contract; both get the same treatment. The leadership takeaway: we expand who can ship safely without lowering the bar.
|
||||
> **Speaker notes:** This is the thesis of the deck. The two surfaces are *parallel*, not a progression — a citizen developer doesn't "graduate" to the developer surface. Both produce a contract; both get the same treatment. The scope boundary matters: anything upstream of the contract is out of ACDL's concern — ACDL is the infrastructure layer that takes a contract and governs the AWS resources. The leadership takeaway: we expand who can ship safely without lowering the bar.
|
||||
|
||||
---
|
||||
|
||||
## Slide 2 — What a Developer Actually Does
|
||||
## Slide 3 — The Contract — The Entire Consumer Surface
|
||||
|
||||
Story beat: Now let's look at what a consumer actually writes — it's tiny.
|
||||
|
||||
Three things. That is the entire consumer-side surface.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. App code<br/>(top level of the repo)"] --> D["Push to main"]
|
||||
B["2. Contract<br/>(.acdl/contract.yaml)"] --> D
|
||||
C["3. CI definition<br/>(.github/workflows/deploy.yml<br/>— one 'uses:' line)"] --> D
|
||||
D --> E["Platform does the rest"]
|
||||
1. **App code** — the consumer's service, at the top level of the repo
|
||||
2. **A contract** — a single YAML file: module, environment, inputs
|
||||
3. **A one-line CI definition** — a thin `uses:` wrapper pointing at a versioned platform workflow
|
||||
|
||||
```yaml
|
||||
uses: acdl/pipelines/deploy.yaml@v1.6
|
||||
module: microservice
|
||||
environment: dev
|
||||
inputs:
|
||||
cpu: 256
|
||||
memory: 512
|
||||
desired_count: 2
|
||||
port: 8080
|
||||
```
|
||||
|
||||
The developer does **not**:
|
||||
@@ -51,16 +73,196 @@ The developer does **not**:
|
||||
- Hold cloud credentials.
|
||||
- Maintain a state backend, a VPC, or a runner.
|
||||
|
||||
> **Speaker notes:** Hold this slide. The audience should sit with how small the consumer surface is. Every item in the "does not" list is a category of toil the platform removes. For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue.
|
||||
> **Speaker notes:** Hold this slide. The audience should sit with how small the consumer surface is. Every item in the "does not" list is a category of toil the platform removes. The contract is the API — deliberately tiny so that it can be reviewed, validated, and audited. For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue.
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — The Citizen Developer Experience
|
||||
## Slide 4 — The Developer Feedback Loop
|
||||
|
||||
A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module.
|
||||
Story beat: Once you push, here's what you see — in real time, in your own logs.
|
||||
|
||||
Developers see **what the platform is doing**, in real time. <span class="badge testing">Testing</span>
|
||||
|
||||
- **Streamed output by default** — the infrastructure plan, policy-check results, and each check record flow to stdout.
|
||||
- **PR comments after every successful pipeline stage** — a developer always knows where they stand without refreshing a dashboard.
|
||||
- **Clear, explainable halt reasons** — a policy violation, an insufficient confidence signal, or a missing attestation. **Never an opaque debugging exercise.**
|
||||
- **Connection strings posted as PR comments** — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store (KMS-encrypted, namespaced), never to logs.
|
||||
- **Errors become GitHub issues, automatically** — a failed deploy opens an issue on the platform repo. The consumer's only grant is the onboarding-granted Lambda-invoke permission — no separate `issues: write` scope on the consumer side.
|
||||
|
||||
> **Speaker notes:** This directly answers "but developers hate platforms that hide what they're doing." The platform is opinionated about *what* runs, not *opaque* about *that* it runs. The PR-comment-after-each-stage pattern is a small thing that compounds into trust. The "errors become issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line. The Head of DevOps should hear: the platform closes the feedback loop, it doesn't just push a green/red status.
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — Versioned, Predictable Releases
|
||||
|
||||
Story beat: You control when you absorb platform improvements — no surprise upgrades.
|
||||
|
||||
Consumers control **when** they absorb platform improvements. <span class="badge testing">Testing</span>
|
||||
|
||||
- **Floating MAJOR + MINOR tags** (e.g. `@v1.6`) — a consumer automatically receives patch updates within the line.
|
||||
- **Semantic versioning with a clear contract:** interface → MAJOR, behavior → MINOR, lifecycle → PATCH.
|
||||
- **A consumer can pin to an exact version** for maximum stability, or float on MAJOR only (`@v1`) to absorb new features on their own cadence.
|
||||
- **Unversioned references (`@main`, bare) are discouraged** — the versioned tag is the only immutability lever a consumer has.
|
||||
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags.
|
||||
|
||||
> **Speaker notes:** This is the "no surprise upgrades" story. Leadership hears two things: (1) consumers aren't forced to chase the platform, (2) the platform isn't forced to support N forks of every workflow. The versioning discipline is what makes both true.
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — Friendly Onboarding
|
||||
|
||||
Story beat: First impressions matter — the platform fails gracefully, not opaquely.
|
||||
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully. <span class="badge testing">Testing</span>
|
||||
|
||||
When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely. The prompt tells the consumer:
|
||||
|
||||
1. That no environment is bound to their repo yet.
|
||||
2. What the platform will provision on their behalf (account, network, state, role).
|
||||
3. The expected turnaround for the platform team to grant the environment.
|
||||
4. How to request an environment.
|
||||
|
||||
The pipeline then **exits without attempting a deployment** — no partial state, no confusing errors.
|
||||
|
||||
<span class="badge planned">Citizen developer onboarding path: planned</span>
|
||||
|
||||
> **Speaker notes:** This looks like a small thing; it's actually a cultural one. The platform's posture is "help me get started," not "you should have known." For the Head of DevOps: this is what drives adoption. Platforms that fail opaquely on first run get routed around.
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — Safe Promotion Path
|
||||
|
||||
Story beat: Promotion is a workflow choice, not a contract edit — and the bar rises automatically.
|
||||
|
||||
The contract is environment-agnostic. The platform raises the bar automatically.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
DEV["dev<br/>autonomous"] -->|raise the bar| QA["qa<br/>QA attests"]
|
||||
QA -->|raise the bar| PROD["prod<br/>SRE attests"]
|
||||
PROD -->|raise the bar| DR["dr<br/>SRE attests + DR drill"]
|
||||
```
|
||||
|
||||
**Approach A — One contract, one job per environment.** A single contract is referenced by multiple jobs; the environment is passed by each job and interpolated at runtime. The contract itself never changes.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
dev:
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with: { contract: .acdl/contract.yaml, environment: dev }
|
||||
qa:
|
||||
needs: dev
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with: { contract: .acdl/contract.yaml, environment: qa }
|
||||
```
|
||||
|
||||
**Approach B — Environment-specific contracts.** When inputs genuinely differ per environment, each job points at its own contract file. The pipeline, policy, and confidence model stay identical.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
dev:
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with: { contract: .acdl/contract-dev.yaml }
|
||||
qa:
|
||||
needs: dev
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with: { contract: .acdl/contract-qa.yaml }
|
||||
```
|
||||
|
||||
Whichever approach a team picks, the platform applies the same rising bar:
|
||||
|
||||
| Environment | What the platform adds | Maturity |
|
||||
|---|---|---|
|
||||
| dev | Confidence ≥ 0.50, fully autonomous | <span class="badge testing">Testing</span> |
|
||||
| qa | QA human attestation + confidence ≥ 0.75 | <span class="badge planned">Planned</span> |
|
||||
| prod | SRE human attestation + confidence ≥ 0.90 | <span class="badge planned">Planned</span> |
|
||||
| dr | SRE human attestation + confidence ≥ 0.95 + a disaster-recovery drill reference | <span class="badge planned">Planned</span> |
|
||||
|
||||
- **No staging environment** — the design deliberately removes the "staging is basically prod but not really" anti-pattern. Dev is the only autonomous environment.
|
||||
- **Separation of duties is enforced** — the QA approver cannot be the prod approver.
|
||||
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit.
|
||||
|
||||
> **Speaker notes:** Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract. Approach A keeps the single source of truth; Approach B lets teams whose inputs genuinely vary keep that variation explicit and reviewable. For leadership: the DX win is that the contract stays stable across environments; the safety win is that the platform raises the threshold and attestation bar automatically based on the target environment the job declares. The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar. Be honest about maturity: dev is tested and pilot-ready; qa/prod/dr wiring is planned.
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — Safe Decommission
|
||||
|
||||
Story beat: Tearing down is as deliberate as deploying — and just as gated.
|
||||
|
||||
Tearing down a stack is **as deliberate as deploying one.** <span class="badge testing">Testing</span>
|
||||
|
||||
```yaml
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.8
|
||||
with:
|
||||
contract: .acdl/contract.yaml
|
||||
mode: decommission
|
||||
changeRequestId: "CHG0678912"
|
||||
```
|
||||
|
||||
A 2-step pipeline with **two SRE human-attestation gates**:
|
||||
|
||||
1. **Validate the change request** — the platform queries the CMDB and asserts the CR is `approved` and matches the consumer repo. No CR, no decommission.
|
||||
2. **Disable deletion protection** → **SRE approves** → **Zero all counts + destroy** → **a second SRE approves.**
|
||||
|
||||
The per-stack encryption key enters a **grace window** (default 30 days) so encrypted data remains recoverable. The key is permanently deleted only after the window expires.
|
||||
|
||||
> **Speaker notes:** The counter-argument to "deletion protection makes cleanup impossible" is this slide. Decommission is a first-class, gated, two-approval flow — not a lock with no key, and not an ungated `terraform destroy`. For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible.
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Self-Service Module Catalog
|
||||
|
||||
Story beat: You don't author infrastructure — you pick from pre-built, security-reviewed building blocks.
|
||||
|
||||
Developers pick from **pre-built, security-reviewed building blocks.** <span class="badge testing">Testing</span>
|
||||
|
||||
- **Primitives** — single-purpose resources (S3, VPC, ECS, IAM, load balancer, container registry, CloudFront, WAF, RDS). Each has documented inputs/outputs, usage, compliance extension points, and versioning.
|
||||
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry).
|
||||
- **Validated examples per module** — `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently.
|
||||
- **Auto-promotion of patterns** — auto-promoted to the catalog after 3 observed usages. <span class="badge planned">Planned</span> <span class="badge agentic">Agentic</span>
|
||||
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in. <span class="badge planned">Planned</span>
|
||||
|
||||
> **Speaker notes:** The catalog is what makes "declare intent" practical — you can only declare a module that exists. For leadership: the catalog is the leverage. One well-reviewed module serves every consumer; a fix to the module serves every consumer on the next run. This is the compounding asset.
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — The Desired Outcomes
|
||||
|
||||
Story beat: Here's what this delivers to the organization.
|
||||
|
||||
- **Velocity without sacrificing safety.** Speed is in the ergonomics (a simple contract, a one-line `uses:`); safety is in the gates the consumer cannot bypass.
|
||||
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
|
||||
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event — captured during the deploy, not reconstructed for the audit.
|
||||
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources. One consumer can never affect another.
|
||||
- **The bottleneck moves off the platform team's ticket queue.** A merged change progresses through lower environments without a platform engineer joining a thread. The platform team invests in the platform, not in per-deployment hand-holding.
|
||||
- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
|
||||
- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer. <span class="badge agentic">Agentic</span>
|
||||
|
||||
> **Speaker notes:** Close on the strategic frame. The platform is not "a CI/CD tool" — it is the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require. Invite questions; the companion deck ("How the Platform Works") covers the internal mechanics in more depth.
|
||||
|
||||
---
|
||||
|
||||
## Appendix — Contents
|
||||
|
||||
For deep dives — these slides cover details omitted from the main 10.
|
||||
|
||||
1. **A1 — The Citizen Developer Experience** (full)
|
||||
2. **A2 — No Platform Code, No Cloning** (detail)
|
||||
3. **A3 — Local Reproducibility** (detail)
|
||||
4. **A4 — The Road to the North Star** (phased roadmap)
|
||||
5. **A5 — Glossary**
|
||||
|
||||
> **Speaker notes:** These are backup slides for Q&A. Use them when the audience asks for the detail behind a main-slide claim. Don't walk through them in the main talk unless time permits.
|
||||
|
||||
---
|
||||
|
||||
## A1 — The Citizen Developer Experience
|
||||
|
||||
A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module. Think of this as **vibe coding on a laptop** — the consumer describes what they want; an AI agent turns that into a contract that the platform treats identically to a senior engineer's.
|
||||
|
||||
- The consumer opens an issue describing what they need (e.g. "a web API for the pricing service").
|
||||
- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog.**
|
||||
- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog.** <span class="badge agentic">Agentic</span>
|
||||
- The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion.
|
||||
|
||||
**Guardrails that make this safe:**
|
||||
@@ -68,54 +270,15 @@ A non-technical consumer ships a production deployment **by declaring intent**
|
||||
- Skills are **versioned, signed, and reviewed for sensitive data before release** (Infra & Ops owns the review — it is the mandatory release gate).
|
||||
- Agents are **stateless** — all state lives in the platform. The platform does not run the skill blindly; it trusts and **always verifies** on the platform side.
|
||||
- The agent's trace and submission confidence are captured in the contract (`profile: agentic`), so a reviewer can see *how* the contract was produced.
|
||||
- **Initial skill catalog:** web API, worker, scheduled job, static asset, basic observability bootstrap. *(Catalog is planned; the agentic surface is on the roadmap.)*
|
||||
- **Initial skill catalog:** web API, worker, scheduled job, static asset, basic observability bootstrap.
|
||||
|
||||
> **Speaker notes:** Be honest about maturity: the *mechanism* (agent → contract → same pipeline) is designed and the stub was proven in the v1.0 demo; the full skill catalog and real agent runtime are planned. But the design point matters to leadership now: we are building for a world where more of the org can ship safely, not where more of the org has to become a platform engineer.
|
||||
<span class="badge planned">Skill catalog + real agent runtime: planned</span> <span class="badge agentic">Agentic</span>
|
||||
|
||||
> **Speaker notes:** Be honest about maturity: the *mechanism* (agent → contract → same pipeline) is designed and the stub was proven in the v1.0 demo; the full skill catalog and real agent runtime are planned. The "vibe coding on a laptop" framing is intentional — it meets the citizen developer where they already are, but every submission still passes the same safety envelope. The design point matters to leadership now: we are building for a world where more of the org can ship safely, not where more of the org has to become a platform engineer.
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — The Contract
|
||||
|
||||
A 5-line YAML file. This is the entire consumer-facing interface to production.
|
||||
|
||||
```yaml
|
||||
# .acdl/contract.yaml — a static site
|
||||
uses: acdl/pipelines/deploy.yaml@v1.6
|
||||
module: static-assets
|
||||
environment: dev
|
||||
inputs:
|
||||
bucket_name: my-static-site-assets
|
||||
region: us-east-1
|
||||
```
|
||||
|
||||
```yaml
|
||||
# .acdl/contract.yaml — a microservice
|
||||
uses: acdl/pipelines/deploy.yaml@v1.6
|
||||
module: microservice
|
||||
environment: dev
|
||||
inputs:
|
||||
image: my-registry/my-microservice:latest
|
||||
port: 8080
|
||||
env:
|
||||
LOG_LEVEL: info
|
||||
```
|
||||
|
||||
Four fields:
|
||||
|
||||
| Field | Meaning |
|
||||
|---|---|
|
||||
| `uses` | The central pipeline, pinned to a versioned tag |
|
||||
| `module` | A name from the module catalog |
|
||||
| `environment` | `dev`, `qa`, `prod`, or `dr` |
|
||||
| `inputs` | The handful of values that vary per deployment |
|
||||
|
||||
An invalid contract (missing field, unknown module, wrong type) **fails fast at validation** with a clear error — not an opaque failure three stages in.
|
||||
|
||||
> **Speaker notes:** The contract is the API. It is deliberately tiny so that it can be reviewed, validated, and audited. For leadership: this is what makes "declare intent" concrete — it's a one-screen file, not a 300-line Terraform root module.
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — No Platform Code, No Cloning
|
||||
## A2 — No Platform Code, No Cloning
|
||||
|
||||
Consumers `uses:` a **versioned** central workflow. The platform fetches itself at run time. The consumer **never touches platform internals.**
|
||||
|
||||
@@ -132,186 +295,51 @@ flowchart LR
|
||||
- The runner checks out the consumer repo, then checks out the platform repo into the workspace.
|
||||
- The platform installs its own runtime dependencies. The consumer installs nothing.
|
||||
- The consumer **never clones the platform repo, never invokes platform scripts locally** (optional `--check-only` validation is available but not required for the happy path).
|
||||
- When the platform ships a fix, every consumer on a floating MAJOR.MINOR tag gets it on their next run — no per-repo upgrade project.
|
||||
|
||||
> **Speaker notes:** The Head of Cloud cares about this: there is no "platform code in every consumer repo" problem. When the platform ships a fix, every consumer on a floating MAJOR.MINOR tag gets it on their next run — no per-repo upgrade project.
|
||||
> **Speaker notes:** The Head of Cloud cares about this: there is no "platform code in every consumer repo" problem. The version-pinned `uses:` line is the *only* coupling, and it's a coupling that updates itself within the line.
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — Versioned, Predictable Releases
|
||||
## A3 — Local Reproducibility
|
||||
|
||||
Consumers control **when** they absorb platform improvements.
|
||||
The entire CI pipeline runs **from the shell**, not just in CI. <span class="badge testing">Testing</span>
|
||||
|
||||
- **Floating MAJOR + MINOR tags** (e.g. `@v1.6`) — a consumer on `@v1.6` automatically receives patch updates within the 1.6 line.
|
||||
- **Semantic versioning with a clear contract:** interface changes → MAJOR, behavior changes → MINOR, lifecycle fixes → PATCH.
|
||||
- **A consumer can pin to an exact version** for maximum stability, or float on MAJOR only (`@v1`) to absorb new features on their own cadence.
|
||||
- **Unversioned references (`@main`, bare) are discouraged** — the versioned tag is the only immutability lever a consumer has.
|
||||
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags. *(Testing.)*
|
||||
- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence.
|
||||
- `scripts/run_platform.sh --check-only` runs the platform **offline** — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing.
|
||||
- `--plan-only` runs through the infrastructure plan without applying.
|
||||
- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement.
|
||||
|
||||
> **Speaker notes:** This is the "no surprise upgrades" story. Leadership hears two things: (1) consumers aren't forced to chase the platform, (2) the platform isn't forced to support N forks of every workflow. The versioning discipline is what makes both true.
|
||||
> **Speaker notes:** This is the "no surprises before you push" story. A consumer can validate their contract offline, run the plan offline, and only push when they're confident. The same declarative contract drives both the local tooling and CI — there's no "works on my machine, fails in CI" gap.
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — Instant Feedback
|
||||
## A4 — The Road to the North Star
|
||||
|
||||
Developers see **what the platform is doing**, in real time, in their own run logs.
|
||||
*Proposed phasing — not formally planned.*
|
||||
|
||||
- **Streamed output by default** — the infrastructure plan, policy-check results, and each `PolicyCheckResult` record (severity, rule ID, pass/fail) flow to stdout. *(Testing.)*
|
||||
- **PR comments after every successful pipeline stage** — a developer always knows where they stand without refreshing a dashboard. *(Testing.)*
|
||||
- **Clear, explainable halt reasons** — a policy violation, an insufficient confidence signal, or a missing attestation. **Never an opaque, manual-debugging exercise.**
|
||||
- **A `--quiet` mode** suppresses streaming for log-only contexts.
|
||||
|
||||
> **Speaker notes:** This directly answers "but developers hate platforms that hide what they're doing." The platform is opinionated about *what* runs, not *opaque* about *that* it runs. The PR-comment-after-each-stage pattern is a small thing that compounds into trust.
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — Deploy Outputs That Just Work
|
||||
|
||||
After a successful deploy, the developer gets their connection information **without hunting for it** — and without secrets leaking into logs.
|
||||
|
||||
- **Human-readable connection strings** posted as a structured GitHub PR comment / job summary. *(Testing.)*
|
||||
- **Runtime-injectable values** written to encrypted Parameter Store (`SecureString`, KMS-encrypted, namespaced `/acdl/{env}/{contractId}/{output_name}`). *(Testing.)*
|
||||
- **No raw secrets in logs** — the platform enforces this by construction.
|
||||
- **Errors become GitHub issues, automatically** — a failed deploy reports through the platform Lambda, which opens (or comments on) an issue on the platform repo. The consumer's only grant is the onboarding-granted Lambda-invoke permission — no separate `issues: write` scope on the consumer side. *(Testing.)*
|
||||
|
||||
> **Speaker notes:** The "errors become issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line. The Head of DevOps should hear: the platform closes the feedback loop, it doesn't just push a green/red status.
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Friendly Onboarding
|
||||
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
|
||||
|
||||
- When a consumer pipeline runs for the first time and **no environment is bound**, the platform detects this and emits a **user-friendly onboarding prompt** instead of failing opaquely. *(Testing.)*
|
||||
- The prompt tells the consumer:
|
||||
1. That no environment is bound to their repo yet.
|
||||
2. What the platform will provision on their behalf (account, network, state, role).
|
||||
3. The expected turnaround for the platform team to grant the environment.
|
||||
4. How to request an environment.
|
||||
- The pipeline then **exits without attempting a deployment** — no partial state, no confusing errors.
|
||||
- **Both onboarding paths end in a sandbox dev submission that must pass the confidence gate** before the consumer is promoted. *(Developer path shipped; citizen developer path planned.)*
|
||||
|
||||
> **Speaker notes:** This looks like a small thing; it's actually a cultural one. The platform's posture is "help me get started," not "you should have known." For the Head of DevOps: this is what drives adoption. Platforms that fail opaquely on first run get routed around.
|
||||
|
||||
---
|
||||
|
||||
## Slide 11 — Safe Promotion Path
|
||||
|
||||
The contract is environment-agnostic by design. Promotion is **a workflow choice, not a contract edit** — the same contract carries cleanly from dev to qa to prod. The platform raises the bar automatically as the target environment becomes more sensitive.
|
||||
|
||||
**Approach A — One contract, one job per environment.** A single contract is referenced by multiple jobs in the CI workflow; the environment is passed by each job and interpolated at runtime. The contract itself never changes.
|
||||
|
||||
```yaml
|
||||
# .github/workflows/deploy.yml — one job per environment, one shared contract
|
||||
jobs:
|
||||
dev:
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with:
|
||||
contract: .acdl/contract.yaml
|
||||
environment: dev
|
||||
qa:
|
||||
needs: dev
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with:
|
||||
contract: .acdl/contract.yaml
|
||||
environment: qa
|
||||
prod:
|
||||
needs: qa
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with:
|
||||
contract: .acdl/contract.yaml
|
||||
environment: prod
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P1["Phase 1<br/>Core platform<br/>(contract, catalog, evidence)"] --> P2["Phase 2<br/>Safe promotion<br/>qa/prod/dr wiring"]
|
||||
P2 --> P3["Phase 3<br/>Agentic surface<br/>(skill catalog + agents)"]
|
||||
P3 --> P4["Phase 4<br/>North star<br/>citizen developer GA"]
|
||||
```
|
||||
|
||||
**Approach B — One job per environment, environment-specific contracts.** When inputs genuinely differ per environment (different capacity, different config), each job points at its own contract file. The pipeline, policy, and confidence model stay identical.
|
||||
> **Speaker notes:** This is a proposed phasing, not a formally committed plan — call that out explicitly. Phase 1 is what's tested today. Phase 2 is the next milestone (qa/prod/dr wiring). Phase 3 introduces the agentic surface. Phase 4 is the north star: citizen developer GA on the same safety envelope. Use this only when an audience member asks "how do you get from here to there."
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
dev:
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with:
|
||||
contract: .acdl/contract-dev.yaml
|
||||
qa:
|
||||
needs: dev
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with:
|
||||
contract: .acdl/contract-qa.yaml
|
||||
prod:
|
||||
needs: qa
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.6
|
||||
with:
|
||||
contract: .acdl/contract-prod.yaml
|
||||
```
|
||||
---
|
||||
|
||||
Whichever approach a team picks, the platform applies the same rising bar:
|
||||
## A5 — Glossary
|
||||
|
||||
| Environment | What the platform adds |
|
||||
| Term | Meaning |
|
||||
|---|---|
|
||||
| dev | Confidence ≥ 0.50, fully autonomous |
|
||||
| qa | QA human attestation + confidence ≥ 0.75 |
|
||||
| prod | SRE human attestation + confidence ≥ 0.90 |
|
||||
| dr | SRE human attestation + confidence ≥ 0.95 + a disaster-recovery drill reference |
|
||||
| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
|
||||
| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
|
||||
| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
|
||||
| **CMDB** | Configuration Management Database — validates change requests for decommission |
|
||||
| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
|
||||
| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
|
||||
| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
|
||||
| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
|
||||
|
||||
- **No staging environment** — the design deliberately removes the "staging is basically prod but not really" anti-pattern. Dev is the only autonomous environment.
|
||||
- **Separation of duties is enforced** — the QA approver cannot be the prod approver. *(Design tested; wiring for qa/prod/dr is planned.)*
|
||||
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit.
|
||||
|
||||
> **Speaker notes:** Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract. Approach A (one contract, environment passed by the job) keeps the single source of truth; Approach B (environment-specific contracts) lets teams whose inputs genuinely vary keep that variation explicit and reviewable. For leadership: the DX win is that the contract stays stable across environments; the safety win is that the platform raises the threshold and attestation bar automatically based on the target environment the job declares. The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar.
|
||||
|
||||
---
|
||||
|
||||
## Slide 12 — Safe Decommission
|
||||
|
||||
Tearing down a stack is **as deliberate as deploying one** — and just as gated.
|
||||
|
||||
```yaml
|
||||
# Consumer's deploy workflow call
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.8
|
||||
with:
|
||||
contract: .acdl/contract.yaml
|
||||
mode: decommission
|
||||
changeRequestId: "CHG0678912"
|
||||
```
|
||||
|
||||
A 2-step pipeline with **two SRE human-attestation gates** *(available today)*:
|
||||
|
||||
1. **Validate the change request** — the platform queries the CMDB and asserts the CR is `approved` and matches the consumer repo. No CR, no decommission.
|
||||
2. **Disable deletion protection** (resolve with `deletion_protection: false`, plan + apply) → **SRE approves.**
|
||||
3. **Zero all counts + destroy** (the platform zeroes every scalable count, plan + apply) → **a second SRE approves.**
|
||||
4. **Confirmation** — the platform confirms the stack is destroyed.
|
||||
|
||||
**After decommission:**
|
||||
|
||||
- The per-stack encryption key enters a **grace window** (default 30 days) so encrypted data remains recoverable. The key is permanently deleted only after the window expires.
|
||||
- Uptime monitoring is **not** automatically destroyed — it can be left running to watch the decommissioned endpoints go dark, or destroyed separately.
|
||||
|
||||
> **Speaker notes:** The counter-argument to "deletion protection makes cleanup impossible" is this slide. Decommission is a first-class, gated, two-approval flow — not a lock with no key, and not an ungated `terraform destroy`. For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible.
|
||||
|
||||
---
|
||||
|
||||
## Slide 13 — Self-Service Module Catalog
|
||||
|
||||
Developers pick from **pre-built, security-reviewed building blocks** — they don't author infrastructure from scratch.
|
||||
|
||||
- **Primitives** — single-purpose resources (S3, VPC, ECS cluster, ECS service, IAM role, load balancer, container registry, CloudFront, WAF, RDS). Each has documented inputs, outputs, usage, compliance extension points, and versioning. *(Testing.)*
|
||||
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry). *(Testing.)*
|
||||
- **Validated examples per module** — every module ships `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently. *(Testing.)*
|
||||
- **Auto-promotion of patterns** — a thin-composition layer is auto-promoted to the catalog after 3 observed usages. *(Mechanism planned.)*
|
||||
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in. *(Compliance milestone is planned.)*
|
||||
|
||||
> **Speaker notes:** The catalog is what makes "declare intent" practical — you can only declare a module that exists. For leadership: the catalog is the leverage. One well-reviewed module serves every consumer; a fix to the module serves every consumer on the next run. This is the compounding asset.
|
||||
|
||||
---
|
||||
|
||||
## Slide 14 — The Outcome for Leadership
|
||||
|
||||
What this platform delivers to the organization:
|
||||
|
||||
- **Velocity without sacrificing safety.** The speed is in the ergonomics (a 5-line contract, a one-line `uses:`); the safety is in the gates the consumer cannot bypass.
|
||||
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
|
||||
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event — captured during the deploy, not reconstructed for the audit.
|
||||
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources. One consumer can never affect another.
|
||||
- **The bottleneck moves off the platform team's ticket queue.** A merged change progresses through lower environments without a platform engineer joining a thread. The platform team invests in the platform, not in per-deployment hand-holding.
|
||||
- **Infrastructure as a utility, not a craft.** The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
|
||||
- **A path to the citizen developer.** The same safety envelope that serves a senior engineer is the one that will serve a non-technical consumer — expanding who can ship safely without lowering the bar.
|
||||
|
||||
> **Speaker notes:** Close on the strategic frame. The platform is not "a CI/CD tool" — it is the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require. Invite questions; the companion deck ("How the Platform Works") covers the internal mechanics in more depth.
|
||||
> **Speaker notes:** Keep this slide in your back pocket for the audience member who asks "what does ABAC actually mean?" Don't read it aloud.
|
||||
Executable
+173
@@ -0,0 +1,173 @@
|
||||
#!/usr/bin/env bash
|
||||
# scripts/sync_to_gl.sh - copy ~/acdl contents to ~/gl/acdl and push.
|
||||
#
|
||||
# Copies the ACDL source tree into the GitLab mirror at ~/gl/acdl.
|
||||
# Hidden files/dirs are NOT copied EXCEPT for .github (so GitLab CI
|
||||
# workflows stay current) and .gitignore. The terraform/ tree is
|
||||
# omitted entirely, and .gitignore patterns are honored. The
|
||||
# destination's existing .git directory is preserved untouched.
|
||||
#
|
||||
# After syncing, commits any changes on the current branch with a
|
||||
# timestamped message and pushes it to its upstream (origin/main).
|
||||
#
|
||||
# Run manually:
|
||||
# bash scripts/sync_to_gl.sh # sync + commit + push
|
||||
# bash scripts/sync_to_gl.sh -v # verbose (list copied files)
|
||||
# bash scripts/sync_to_gl.sh --no-push # sync + commit only, no push
|
||||
# bash scripts/sync_to_gl.sh --dry-run # show what would happen
|
||||
# SRC=~/acdl DST=~/gl/acdl bash scripts/sync_to_gl.sh
|
||||
set -euo pipefail
|
||||
|
||||
SRC="${SRC:-$HOME/acdl}"
|
||||
DST="${DST:-$HOME/gl/acdl}"
|
||||
VERBOSE=0
|
||||
NO_PUSH=0
|
||||
DRY_RUN=0
|
||||
|
||||
for arg in "$@"; do
|
||||
case "$arg" in
|
||||
-v|--verbose) VERBOSE=1 ;;
|
||||
--no-push) NO_PUSH=1 ;;
|
||||
--dry-run) DRY_RUN=1 ;;
|
||||
-h|--help)
|
||||
sed -n '2,21p' "$0"
|
||||
exit 0
|
||||
;;
|
||||
*) echo "FAIL: unknown argument: $arg" >&2; exit 1 ;;
|
||||
esac
|
||||
done
|
||||
|
||||
fail() { echo "FAIL: $*" >&2; exit 1; }
|
||||
run() {
|
||||
if [ "$DRY_RUN" = "1" ]; then
|
||||
echo " [dry-run] $*"
|
||||
else
|
||||
"$@"
|
||||
fi
|
||||
}
|
||||
|
||||
[ -d "$SRC" ] || fail "source not found: $SRC"
|
||||
[ -d "$DST" ] || fail "destination not found: $DST (create it first)"
|
||||
[ -d "$DST/.git" ] || fail "destination has no .git: $DST/.git (restore it first)"
|
||||
|
||||
echo "=== sync_to_gl ==="
|
||||
echo "source: $SRC"
|
||||
echo "destination: $DST"
|
||||
[ "$NO_PUSH" = "1" ] && echo "mode: sync + commit (no push)"
|
||||
[ "$DRY_RUN" = "1" ] && echo "mode: dry-run (no changes made)"
|
||||
echo ""
|
||||
|
||||
# Sanity: refuse if DST is not inside ~/gl or is the same as SRC.
|
||||
case "$DST" in
|
||||
"$HOME"/gl/*) : ;;
|
||||
*) fail "destination must live under ~/gl (got $DST)" ;;
|
||||
esac
|
||||
[ "$SRC" != "$DST" ] || fail "source and destination are identical"
|
||||
|
||||
# --- sync (rsync) -----------------------------------------------------------
|
||||
|
||||
# Build rsync exclude list: every hidden entry in SRC except .github
|
||||
# and .gitignore.
|
||||
EXCLUDES=()
|
||||
for hidden in "$SRC"/.*; do
|
||||
name="$(basename "$hidden")"
|
||||
case "$name" in
|
||||
.|...) continue ;;
|
||||
.github|.gitignore) continue ;; # keep
|
||||
esac
|
||||
EXCLUDES+=("--exclude=/$name")
|
||||
done
|
||||
|
||||
# Never touch the destination's .git. "protect" makes rsync skip it
|
||||
# entirely (neither transfer nor delete) even under --delete; this is
|
||||
# stronger than --exclude, which --delete-excluded would wipe out.
|
||||
# Drop it from the transfer set too.
|
||||
EXCLUDES+=("--exclude=/.git")
|
||||
|
||||
# Omit the terraform/ tree entirely.
|
||||
EXCLUDES+=("--exclude=/terraform")
|
||||
|
||||
# rsync filters: protect .git, then honor per-directory .gitignore
|
||||
# via dir-merge (:-) semantics so patterns anchor like git does.
|
||||
FILTERS=(
|
||||
"--filter=P .git"
|
||||
"--filter=:- .gitignore"
|
||||
)
|
||||
|
||||
# Use --delete (prune extras in the synced tree) but NOT --delete-excluded:
|
||||
# that would wipe destination paths covered by our --exclude rules, which
|
||||
# is exactly what must NOT happen for .git.
|
||||
RSYNC_ARGS=(-a --delete)
|
||||
[ "$VERBOSE" = "1" ] && RSYNC_ARGS+=(-v)
|
||||
|
||||
echo "rsync excludes: ${EXCLUDES[*]}"
|
||||
echo "rsync filters: ${FILTERS[*]}"
|
||||
echo ""
|
||||
|
||||
if [ "$DRY_RUN" = "1" ]; then
|
||||
echo "[dry-run] rsync would run:"
|
||||
printf ' %q ' rsync "${RSYNC_ARGS[@]}" "${FILTERS[@]}" "${EXCLUDES[@]}" "$SRC/" "$DST/"; echo
|
||||
else
|
||||
rsync "${RSYNC_ARGS[@]}" "${FILTERS[@]}" "${EXCLUDES[@]}" "$SRC/" "$DST/"
|
||||
echo "rsync: OK"
|
||||
fi
|
||||
|
||||
echo ""
|
||||
|
||||
# --- git commit + push ------------------------------------------------------
|
||||
|
||||
cd "$DST"
|
||||
|
||||
# Refuse to run inside a merge/rebase/conflict state.
|
||||
git rev-parse --is-inside-work-tree >/dev/null
|
||||
git_dir_state() {
|
||||
local f
|
||||
for f in MERGE_HEAD CHERRY_PICK_HEAD REVERT_HEAD BISECT_LOG; do
|
||||
[ -e ".git/$f" ] && return 1
|
||||
done
|
||||
[ -d ".git/rebase-merge" -o -d ".git/rebase-apply" ] && return 1
|
||||
return 0
|
||||
}
|
||||
git_dir_state || fail "destination .git is mid-operation (merge/rebase/etc); resolve it then re-run"
|
||||
|
||||
branch="$(git symbolic-ref --quiet --short HEAD 2>/dev/null || true)"
|
||||
[ -n "$branch" ] || fail "HEAD is detached; checkout a branch first (got $(git rev-parse --short HEAD))"
|
||||
|
||||
# Stage everything in the working tree (including deletions).
|
||||
run git add -A
|
||||
|
||||
# Commit only if there is something staged.
|
||||
if git diff --cached --quiet; then
|
||||
echo "git: no changes to commit on branch '$branch'"
|
||||
else
|
||||
ts="$(date -u +%Y-%m-%d\ %H:%M\ UTC)"
|
||||
msg="chore: sync from source mirror $ts"
|
||||
echo "git: committing on branch '$branch'"
|
||||
[ "$VERBOSE" = "1" ] && git diff --cached --stat
|
||||
run git commit -m "$msg"
|
||||
fi
|
||||
|
||||
# Push (current branch to its upstream) unless suppressed.
|
||||
if [ "$NO_PUSH" = "1" ]; then
|
||||
echo "git: --no-push set, skipping push"
|
||||
PUSHED=0
|
||||
else
|
||||
upstream="$(git rev-parse --abbrev-ref --symbolic-full-name '@{u}' 2>/dev/null || true)"
|
||||
if [ -z "$upstream" ]; then
|
||||
fail "no upstream configured for branch '$branch'; set one with: git -C $DST branch --set-upstream-to=origin/$branch $branch"
|
||||
fi
|
||||
if [ "$DRY_RUN" = "1" ]; then
|
||||
echo " [dry-run] git push to $upstream"
|
||||
else
|
||||
echo "git: pushing '$branch' to $upstream"
|
||||
git push
|
||||
echo "git: push OK"
|
||||
fi
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "=== sync_to_gl OK ==="
|
||||
echo "copied $SRC -> $DST"
|
||||
[ "$DRY_RUN" = "1" ] && echo "(dry-run: nothing actually written or pushed)"
|
||||
[ "$NO_PUSH" = "1" ] && echo "(no-push: changes committed but not pushed)"
|
||||
exit 0
|
||||
Reference in New Issue
Block a user