Skip to content

Commit 9f4a45d

Browse files
Copilotchefgs
Copilot
and
chefgs
authored
Add Chennai FOSS demo-command guide under feature announcements (#64)
* Add Chennai FOSS demo command guide Agent-Logs-Url: https://github.com/cloudengine-labs/devops_os/sessions/8f04f431-5147-4f1a-b9ec-d06c9a5d66b8 Co-authored-by: chefgs <7605658+chefgs@users.noreply.github.com> * Move Chennai FOSS markdown into feature announcements Agent-Logs-Url: https://github.com/cloudengine-labs/devops_os/sessions/4d066aef-59a7-4306-a5fd-ce1c6cc68f4a Co-authored-by: chefgs <7605658+chefgs@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: chefgs <7605658+chefgs@users.noreply.github.com>
1 parent e59d0b7 commit 9f4a45d

1 file changed

Lines changed: 176 additions & 0 deletions

File tree

‎feature-announcements/chennai-foss-2026/demo-command-list.md‎

Lines changed: 176 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,176 @@
1+
# Chennai FOSS Demo Command List
2+
3+
This demo should show **Process-First DevOps automation for a Go service** with the fewest commands possible, while still telling the full story from **build → test → deploy → monitoring**.
4+
5+
## Demo objective
6+
7+
Show that DevOps-OS can act as a **self-service internal developer platform (IDP) entry point** where platform teams publish reusable templates and application teams consume them with simple CLI commands.
8+
9+
---
10+
11+
## Recommended demo sequence
12+
13+
### 1. Start with Process-First
14+
15+
```bash
16+
python -m cli.devopsos process-first --section mapping
17+
python -m cli.devopsos process-first --section best_practices
18+
```
19+
20+
**Why this comes first**
21+
- Explains that the platform starts with process, not tooling.
22+
- Gives the audience the map from SDLC stages to scaffold commands.
23+
- Frames the rest of the demo as **golden-path automation**.
24+
25+
**Talk track**
26+
- `mapping` shows which command represents each process.
27+
- `best_practices` connects build, deploy, SRE, and monitoring into one system.
28+
29+
---
30+
31+
### 2. Standardise the Go developer platform
32+
33+
```bash
34+
python -m cli.devopsos scaffold devcontainer \
35+
--languages go \
36+
--cicd-tools docker,terraform \
37+
--kubernetes-tools kubectl,helm,k9s,argocd_cli,flux
38+
```
39+
40+
**What this demonstrates**
41+
- Platform engineering baseline
42+
- Reproducible developer environment
43+
- Toolchain templatisation for Go delivery teams
44+
45+
**Why it matters**
46+
- This is the **platform foundation**.
47+
- Teams do not assemble tools manually; they inherit a standard Go DevOps workspace.
48+
49+
---
50+
51+
### 3. Add the Go test scaffold
52+
53+
```bash
54+
python -m cli.devopsos scaffold unittest --name go-demo --languages go
55+
```
56+
57+
**What this demonstrates**
58+
- Quality gates start early
59+
- Testing is part of the template, not an afterthought
60+
61+
**Why it matters**
62+
- It shows that platform teams can templatise engineering guardrails, not just infrastructure.
63+
64+
---
65+
66+
### 4. Generate the main Go CI/CD workflow
67+
68+
```bash
69+
python -m cli.devopsos scaffold gha \
70+
--name go-demo \
71+
--languages go \
72+
--type complete \
73+
--kubernetes \
74+
--k8s-method argocd
75+
```
76+
77+
**What this demonstrates**
78+
- Build, test, containerisation, and deployment pipeline generation
79+
- One-command automation for a Go service
80+
- Standard CI/CD template owned by the platform team
81+
82+
**Why this is the key demo command**
83+
- It gives the fastest visible payoff.
84+
- It proves the platform can turn process into an executable delivery template.
85+
86+
---
87+
88+
### 5. Generate GitOps deployment templates
89+
90+
```bash
91+
python -m cli.devopsos scaffold argocd \
92+
--name go-demo \
93+
--repo https://github.com/your-org/go-demo.git \
94+
--path k8s \
95+
--auto-sync
96+
```
97+
98+
**What this demonstrates**
99+
- GitOps-based deployment model
100+
- Promotion through Git rather than manual kubectl changes
101+
- Separation of application code and deployment control
102+
103+
**Why it matters**
104+
- This is where the demo shifts from CI/CD to **platform-controlled deployment automation**.
105+
106+
---
107+
108+
### 6. Generate SRE and monitoring templates
109+
110+
```bash
111+
python -m cli.devopsos scaffold sre \
112+
--name go-demo \
113+
--team platform \
114+
--slo-target 99.9
115+
```
116+
117+
**What this demonstrates**
118+
- Prometheus alerts
119+
- Grafana dashboard
120+
- SLO definition
121+
- Monitoring as a built-in part of delivery
122+
123+
**Why it matters**
124+
- It closes the loop from build to monitoring.
125+
- The audience sees that observability is also templatized and self-service.
126+
127+
---
128+
129+
## Best short-form demo flow
130+
131+
If time is limited, use this exact sequence:
132+
133+
```bash
134+
python -m cli.devopsos process-first --section mapping
135+
python -m cli.devopsos scaffold devcontainer --languages go --cicd-tools docker,terraform --kubernetes-tools kubectl,helm,k9s,argocd_cli,flux
136+
python -m cli.devopsos scaffold unittest --name go-demo --languages go
137+
python -m cli.devopsos scaffold gha --name go-demo --languages go --type complete --kubernetes --k8s-method argocd
138+
python -m cli.devopsos scaffold argocd --name go-demo --repo https://github.com/your-org/go-demo.git --path k8s --auto-sync
139+
python -m cli.devopsos scaffold sre --name go-demo --team platform --slo-target 99.9
140+
```
141+
142+
This is the most effective story because it moves in a natural order:
143+
144+
1. **Explain the process**
145+
2. **Create the standard platform workspace**
146+
3. **Add quality automation**
147+
4. **Generate CI/CD**
148+
5. **Generate GitOps deployment**
149+
6. **Generate monitoring and SRE artefacts**
150+
151+
---
152+
153+
## How to tie the commands together in the talk
154+
155+
| Demo step | Command outcome | Platform engineering meaning | Templatisation meaning | IDP meaning |
156+
|---|---|---|---|---|
157+
| Process-First | Shared delivery model | Platform defines the operating model | Standard process blueprint | Developers consume a guided workflow |
158+
| Dev Container | Standard Go workspace | Platform curates tools once | Reusable environment template | Self-service developer setup |
159+
| Unit test scaffold | Standard quality baseline | Platform encodes quality expectations | Reusable test starter template | Developers get guardrails on demand |
160+
| GitHub Actions scaffold | Standard CI/CD workflow | Platform owns golden path delivery | Reusable pipeline template | Teams generate pipelines without tickets |
161+
| ArgoCD scaffold | Standard deployment model | Platform enforces GitOps | Reusable deployment template | Teams self-serve deployments through Git |
162+
| SRE scaffold | Standard observability baseline | Platform embeds reliability practices | Reusable monitoring template | Teams self-serve alerts, dashboards, and SLOs |
163+
164+
---
165+
166+
## Core message for Chennai FOSS
167+
168+
DevOps-OS should be presented not as "another generator", but as:
169+
170+
- a **platform engineering accelerator**
171+
- a **templatisation engine for DevOps processes**
172+
- a lightweight **IDP interface** for self-service delivery
173+
174+
The strongest demo message is:
175+
176+
> **Process-First defines the golden path, DevOps-OS turns it into templates, and the CLI becomes the self-service IDP experience for Go-based delivery teams.**

0 commit comments

Comments
 (0)