807b17d04b
How The Platform Works: 16 → 10 slides - Merged Problem + North Star + What It Is/Isn't → 1 slide (4 frictions → North Star → 3 success criteria → 2 anti-goals) - Merged Policy & Security + Secure by Default → 'Security by Construction' - Merged Immutable Audit + Human-in-the-Loop → 'Accountability & Audit' - Folded Observability, Platform-Managed Environments, Portability into existing slides as bullets (Roadmap, Contract-Driven) - Added 'The Vision Realized' closing slide - Removed '5-line YAML' claim (credibility — complex stacks are more) The Developer Experience: 15 → 10 slides - Merged What Dev Does + Contract + No Platform Code → 'The Contract — The Entire Consumer Surface' - Merged Instant Feedback + Deploy Outputs → 'The Developer Feedback Loop' - Merged Safe Promotion Path + Rising Bar → 1 slide with side-by-side approaches + threshold table - Cut Citizen Developer Experience as standalone (mentioned on slide 2 and slide 10 Outcomes) - Kept Versioned Releases, Friendly Onboarding, Safe Decommission as standalone (per user request) - Removed '5-line YAML' claim Source markdown files unchanged (remain complete reference with speaker notes for all original slides). ---ci--- phase: 49 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci---
226 lines
9.7 KiB
Markdown
226 lines
9.7 KiB
Markdown
---
|
|
marp: true
|
|
theme: default
|
|
paginate: true
|
|
size: 16x9
|
|
header: "The Developer Experience"
|
|
footer: "Internal"
|
|
style: |
|
|
section {
|
|
font-family: "Akkurat Pro", "Helvetica Neue", "Arial", sans-serif;
|
|
font-size: 22px;
|
|
color: #1B1B1B;
|
|
}
|
|
h1 { color: #D6002A; font-size: 34px; margin-bottom: 0.3em; }
|
|
h2 { color: #D6002A; font-size: 26px; margin-bottom: 0.2em; }
|
|
section.title { background: #1B1B1B; color: #fff; border-top: 8px solid #D6002A; }
|
|
section.title h1 { color: #fff; }
|
|
table { font-size: 18px; width: 100%; }
|
|
th { background: #F0F0F0; }
|
|
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; }
|
|
.badge {
|
|
display: inline-block; padding: 2px 8px; border-radius: 4px;
|
|
font-size: 14px; font-weight: 600;
|
|
}
|
|
.testing { background: #DBEAFE; color: #1E3A5F; }
|
|
.planned { background: #fef3c7; color: #78350f; }
|
|
.agentic { background: #EDE9FE; color: #4C1D95; }
|
|
---
|
|
|
|
<!-- _class: title -->
|
|
<!-- _paginate: false -->
|
|
|
|
# The Developer Experience
|
|
|
|
### Agentic Cloud Delivery Platform
|
|
|
|
<style>
|
|
section.title h1 { font-size: 44px; margin-bottom: 0.1em; }
|
|
section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top: 0; }
|
|
</style>
|
|
|
|
---
|
|
|
|
# Two Consumer Surfaces, One Platform
|
|
|
|
The platform serves **two kinds of consumer** — both converge on the **same contract, the same policy envelope, and the same evidence stream.**
|
|
|
|

|
|
|
|
- **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.
|
|
|
|
---
|
|
|
|
# The Contract — The Entire Consumer Surface
|
|
|
|
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;" />
|
|
|
|
- **1. App code** — the consumer's service, at the top level of the repo
|
|
- **2. A contract** — a single YAML file: module, environment, inputs
|
|
|
|
```yaml
|
|
uses: acdl/pipelines/deploy.yaml@v1.6
|
|
module: microservice
|
|
environment: dev
|
|
inputs:
|
|
image: my-registry/my-microservice:latest
|
|
port: 8080
|
|
```
|
|
|
|
- **3. A one-line CI definition** — a thin `uses:` wrapper pointing at a versioned platform workflow
|
|
- The developer does **not**: write infrastructure modules, clone the platform repo, hold cloud credentials, or maintain a state backend
|
|
|
|
---
|
|
|
|
# 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>
|
|
|
|
- **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 in encrypted Parameter Store** — KMS-encrypted, namespaced, **no raw secrets in logs**
|
|
- **Errors become GitHub issues, automatically** — a failed deploy opens an issue on the platform repo
|
|
|
|
---
|
|
|
|
# Versioned, Predictable Releases
|
|
|
|
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
|
|
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags
|
|
|
|
---
|
|
|
|
# Friendly Onboarding
|
|
|
|
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:
|
|
|
|
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>
|
|
|
|
---
|
|
|
|
# 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.
|
|
|
|
<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.
|
|
|
|
```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 }
|
|
```
|
|
|
|
</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.
|
|
|
|
```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 }
|
|
```
|
|
|
|
</td>
|
|
</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>
|
|
|
|
```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; the CR must be `approved` and match the consumer repo
|
|
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.
|
|
|
|
---
|
|
|
|
# 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>
|
|
|
|
- **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>
|
|
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in <span class="badge planned">Planned</span>
|
|
|
|
---
|
|
|
|
<!-- _class: title -->
|
|
<!-- _paginate: false -->
|
|
|
|
# The Desired Outcomes
|
|
|
|
- **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.
|
|
- **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> |