Skip to content

Commit 99d9d5a

Browse files
MariusStorhaugMariusStorhaug
committed
docs: Add comprehensive guides on Continuous X practices, Development practices, and DevOps principles
1 parent 440b091 commit 99d9d5a

3 files changed

Lines changed: 401 additions & 0 deletions

File tree

‎src/docs/Ways-of-Working/continuous-x-and-continuous-ai.md‎

Lines changed: 156 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,156 @@
1+
# Continuous X Practices, Continuous AI, and the Microsoft DevOps Dojo
2+
3+
## 1. The "Continuous X" Practices
4+
5+
### Microsoft DevOps Dojo's eight pillars (White Belt)
6+
7+
The cleanest authoritative taxonomy. From [DevOps Dojo White Belt Foundation](https://learn.microsoft.com/en-us/training/paths/devops-dojo-white-belt-foundation/):
8+
9+
| # | Practice | What it covers |
10+
|---|----------|----------------|
11+
| 1 | Continuous Planning | Lean product, hypothesis-driven dev, backlog management, OKRs |
12+
| 2 | Continuous Integration | Trunk-based dev, automated build & test on every commit |
13+
| 3 | Continuous Delivery | Every commit potentially releasable; automated pipeline to prod |
14+
| 4 | Continuous Quality | Test pyramid, shift-left testing, code review, static analysis |
15+
| 5 | Continuous Security | Shift-left security, SAST/DAST/SCA, secrets, supply chain |
16+
| 6 | Continuous Operations | SRE, observability, SLOs, incident response, on-call |
17+
| 7 | Continuous Collaboration | ChatOps, docs-as-code, transparent comms, shared ownership |
18+
| 8 | Continuous Improvement | Kaizen, retros, blameless postmortems, value-stream mapping |
19+
20+
### Full inventory with provenance
21+
22+
| Practice | Origin / canonical source |
23+
|----------|--------------------------|
24+
| **Continuous Integration** | Coined in Grady Booch's 1991 method; popularised by XP and [Martin Fowler's 2006 article](https://martinfowler.com/articles/continuousIntegration.html). |
25+
| **Continuous Delivery** | Jez Humble & David Farley, [*Continuous Delivery*](https://continuousdelivery.com/), 2010. |
26+
| **Continuous Deployment** | Every passing build deploys to prod with no human gate (vs. CD which only makes it *deployable*). |
27+
| **Continuous Testing** | Test throughout the pipeline plus in production (synthetic, canary analysis). |
28+
| **Continuous Verification** | Netflix's term for chaos-engineering-style continuous resilience validation. Rosenthal & Jones, [*Chaos Engineering*](https://www.oreilly.com/library/view/chaos-engineering/9781492043850/), O'Reilly. |
29+
| **Continuous Monitoring → Continuous Observability** | Shift from dashboards of knowns to ad-hoc querying of unknowns. [Honeycomb's Observability Manifesto](https://www.honeycomb.io/blog/observability-a-manifesto). |
30+
| **Continuous Feedback** | Right-to-left flow from prod → dev. DevOps Second Way (*Phoenix Project*). |
31+
| **Continuous Improvement** | Toyota *kaizen*; Deming PDCA cycle. |
32+
| **Continuous Learning** | DevOps Third Way (Kim, *Phoenix Project*). |
33+
| **Continuous Security / DevSecOps** | OWASP; [DoD Enterprise DevSecOps Reference Design](https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf). |
34+
| **Continuous Compliance** | Compliance-as-code: Chef InSpec, OPA, AWS Config. |
35+
| **Continuous Configuration Automation (CCA)** | Gartner term covering Ansible/Puppet/Chef/Salt. |
36+
| **Continuous Inspection** | SonarSource's term for always-on code-quality scanning. [docs.sonarsource.com](https://docs.sonarsource.com/). |
37+
| **Continuous Profiling** | Always-on production profiling. Pyroscope/Grafana, Polar Signals, Google-Wide Profiling paper (2010). |
38+
| **Continuous Documentation / docs-as-code** | Write the Docs community; treat docs like code. |
39+
| **Continuous Experimentation** | A/B testing, hypothesis-driven dev. Kohavi et al., [*Trustworthy Online Controlled Experiments*](https://experimentguide.com/), 2020. |
40+
| **Continuous Discovery** | Teresa Torres, [*Continuous Discovery Habits*](https://www.producttalk.org/continuous-discovery-habits/), 2021. |
41+
| **Continuous Architecture** | Erder & Pureur, *Continuous Architecture in Practice*, 2021. |
42+
| **Continuous Refactoring** | XP practice; Fowler's [*Refactoring*](https://martinfowler.com/books/refactoring.html). |
43+
| **Continuous Reliability** | Vendor-popularised (Catchpoint, Gremlin); convergence of SRE + chaos + observability. |
44+
| **Continuous Code Review** | Modern PR workflows + always-on reviewers. |
45+
| **Continuous Training (CT)** in MLOps | Google's [MLOps Levels 1–2](https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning) — automatic retraining on fresh data. |
46+
47+
---
48+
49+
## 2. Continuous AI
50+
51+
**Canonical source:** [GitHub Next — Continuous AI](https://githubnext.com/projects/continuous-ai/), published June 2025 by Eddie Aftandilian, Peli de Halleux, Russell Horton, Don Syme.
52+
53+
### Definition (verbatim)
54+
> "All uses of automated AI to support software collaboration on any platform."
55+
56+
Positioned explicitly as the AI-era counterpart to CI/CD: *"Just as CI/CD transformed software development by automating integration and deployment, Continuous AI covers the ways in which AI can be used to automate and enhance collaboration workflows."*
57+
58+
GitHub explicitly does **not** claim ownership of the term — it's a label for the industry, not a product.
59+
60+
### Seven characteristics (GitHub Next's taxonomy)
61+
Continuous AI tasks are: **automatable, repetitive, collaborative, integrated, auditable, event-triggered**, and have **many variants**.
62+
63+
### GitHub Next's example workflows
64+
- **Continuous Documentation** — docs in sync with code automatically
65+
- **Continuous Code Improvement** — comments, tests, small refactors
66+
- **Continuous Triage** — label/summarise/respond to issues in natural language
67+
- **Continuous Summarization** — rolling summaries of project activity
68+
- **Continuous Fault Analysis** — auto-explain failed CI runs
69+
- **Continuous Quality** — LLM-driven quality analysis
70+
- **Continuous Team Motivation** — PRs into poetry/zines/podcasts (the social layer)
71+
- **Continuous Accessibility** — auto-check & improve a11y
72+
73+
### Continuous AI vs. its cousins
74+
75+
| Term | What it is |
76+
|------|-----------|
77+
| **Continuous AI** | AI participating *in* the SDLC continuously (review, docs, triage, fault analysis). The AI is the actor. |
78+
| **MLOps** | CI/CD/CT *for* ML models — training, evaluation, deployment, monitoring. The model is the product. |
79+
| **LLMOps** | MLOps specialised for LLM apps: prompt versioning, evals, retrieval, guardrails, cost/latency monitoring. |
80+
| **AIOps** | AI/ML applied to IT operations — anomaly detection, alert correlation, RCA. Gartner term, ~2017. |
81+
82+
### How Continuous AI augments each Continuous X practice
83+
84+
| Traditional practice | Continuous-AI augmentation | Example tools (2025) |
85+
|---------------------|---------------------------|----------------------|
86+
| Continuous Integration | AI summarises broken builds; suggests fixes | GitHub Copilot Workspace, Sweep |
87+
| Continuous Delivery | Agents drive multi-step deploys; AI-authored release notes | GitHub Copilot agents, Devin |
88+
| Continuous Testing | Test generation, flaky-test detection, auto-repair | Diffblue, Qodo (CodiumAI), Meta TestGen-LLM |
89+
| Continuous Quality | LLM PR review beyond linters | CodeRabbit, Greptile, Graphite Diamond, Copilot review |
90+
| Continuous Security | LLM-aware SAST, auto-remediation PRs | Snyk DeepCode, Semgrep Assistant, Copilot Autofix |
91+
| Continuous Operations | "AI SRE" — autonomous triage, RCA, runbook execution | Resolve.ai, Cleric, PagerDuty AIOps, Rootly AI |
92+
| Continuous Documentation | Docs stay in sync with code | Mintlify, GitHub Next *Continuous Documentation* |
93+
| Continuous Code Review | Always-on AI reviewer | CodeRabbit, Greptile, Copilot review |
94+
| Continuous Refactoring | Background agents propose refactors | Cursor background agents, Sourcegraph Cody, Grit.io |
95+
| Continuous Triage | Issue labelling, dedup, summarisation | GitHub Models + Actions recipes, Linear AI |
96+
| Continuous Improvement | Auto-postmortems, retro summaries | incident.io, Rootly, Jeli (Atlassian) |
97+
| Continuous Discovery | LLM synthesis of user research | Dovetail AI, Maze AI |
98+
| Continuous Training (MLOps) | Pre-existed; now intersects with eval-driven LLM dev | Vertex AI, Databricks, Weights & Biases |
99+
100+
### What structurally changes
101+
102+
- **Evals are the new tests.** For AI features, regression suites are eval suites — graded by LLM judges or humans. Eval drift = test failure.
103+
- **Pipelines gain non-deterministic actors.** Every Continuous AI step needs auditability: which agent, which model version, which prompt, which tools, what did it touch.
104+
- **Cost and runaway risk.** Traditional CI steps have bounded cost; agentic steps can recurse. Need budgets, timeouts, concurrency caps.
105+
- **Prompt injection becomes a CI/CD threat.** Untrusted issue text, PR descriptions, error messages, third-party docs become attack surfaces when an agent reads them.
106+
- **Governance.** Expect "AI-generated change" to need provenance equivalent to a signed commit. SOC2/ISO27001/regulators catching up.
107+
108+
### Tooling stack referenced by GitHub Next
109+
- [GitHub Actions](https://github.com/features/actions)
110+
- [GitHub Models](https://github.com/features/models)
111+
- [GenAIScript (Microsoft)](https://microsoft.github.io/genaiscript/)
112+
- [Datasette `llm`](https://llm.datasette.io/)
113+
- [GitHub Agentic Workflows](https://githubnext.com/projects/agentic-workflows/) — sister project at GitHub Next
114+
- [The Agentics](https://github.com/githubnext/agentics/) — example workflows
115+
116+
---
117+
118+
## 3. Microsoft DevOps Dojo — Status
119+
120+
**Status:** alive but dormant. White Belt remains a real Microsoft Learn path; higher belts are blog posts; GitHub org quiet since late 2022.
121+
122+
### History
123+
Started ~2018–2019 inside Microsoft (catalysed by a 2019 conversation with German CIOs); grew into a cross-org community spanning Services, Customer Success, Digital Advisory, and product groups. Public face was largely **April Edwards** (Senior Cloud Advocate). Authoritative intro: [*Intro of DevOps Dojo*](https://devblogs.microsoft.com/devops/intro-of-devops-dojo/) on Azure DevOps Blog (July 2022).
124+
125+
### Belt curriculum
126+
- **White Belt** — standardised DevOps fundamentals — *only one with a formal Microsoft Learn path*
127+
- **Orange Belt** — scaled DevOps (enterprise/program/portfolio) — blog only
128+
- **Green Belts** — domain lenses (e.g. UX/Accessibility) — blog only
129+
- **Black Belt** — data-driven, intelligent DevOps for executives — never published
130+
131+
Four pillars: Culture & Mindset, Lean Product, Architecture, Technology.
132+
133+
### Where the content lives today
134+
135+
**Microsoft Learn — White Belt (six modules):**
136+
- [DevOps Dojo White Belt Foundation](https://learn.microsoft.com/en-us/training/paths/devops-dojo-white-belt-foundation/)
137+
138+
**Azure DevOps Blog (the deeper belts):**
139+
- [Intro of DevOps Dojo](https://devblogs.microsoft.com/devops/intro-of-devops-dojo/)
140+
- [People & Teams (Orange)](https://devblogs.microsoft.com/devops/devops-dojo-people-teams/)
141+
- [UX/Accessibility (Green)](https://devblogs.microsoft.com/devops/devops-dojo-ux-accessibility/)
142+
- [Culture and Mindset](https://devblogs.microsoft.com/devops/devops-dojo-culture-and-mindset/)
143+
- [Experiential Learning](https://devblogs.microsoft.com/devops/devops-dojo-experiential-learning/)
144+
- [Lean Product Part 1 / Part 2](https://devblogs.microsoft.com/devops/devops-dojo-lean-product-part-1/)
145+
146+
**DevOps Lab video series:** [learn.microsoft.com/shows/devops-lab](https://learn.microsoft.com/en-us/shows/devops-lab/)
147+
148+
**GitHub:** [github.com/microsoftdevopsdojo](https://github.com/microsoftdevopsdojo) — sparse, last meaningful activity Oct 2022.
149+
150+
### What to use today
151+
1. **Dojo White Belt** on Learn — for the Continuous X scaffolding
152+
2. **[Evolve your DevOps practices](https://learn.microsoft.com/en-us/training/paths/evolve-your-devops-practices/)** — practical follow-on
153+
3. **[ISE Engineering Fundamentals Playbook](https://microsoft.github.io/code-with-engineering-playbook/)** — Microsoft's public, actively-maintained engineering playbook. The de facto modern equivalent.
154+
4. **[AZ-400 Enterprise DevOps](https://learn.microsoft.com/en-us/credentials/certifications/devops-engineer/)** — certification track
155+
156+
The ISE Playbook is the more living artifact — updated regularly, public PRs welcome, covers similar ground without the belt theatre.

‎src/docs/Ways-of-Working/development-practices.md‎

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
# Development Practices
2+
3+
How we work on this team. Short, opinionated, and meant to be argued with — if a practice stops serving us, we change it in a retro.
4+
5+
---
6+
7+
## 1. How we think
8+
9+
**Deliver value, not output.** Shipping code is not the goal. Changing outcomes for customers is.
10+
11+
- **Customer first.** Every story answers: who is this for, and what changes for them?
12+
- **Small batches.** Smaller changes are safer, faster to review, and faster to learn from. If a story takes more than a few days, split it.
13+
- **Optimize the whole.** A local win that slows the next team down is a loss. Think in flow, not silos.
14+
- **Build quality in.** We do not "add testing later" or "harden it in hardening sprint." Quality is a property of how we work, not a phase.
15+
- **Decide reversibly.** Prefer decisions that are cheap to undo. For one-way doors, slow down and write it down.
16+
17+
---
18+
19+
## 2. How we plan
20+
21+
**Flow over utilization.** A busy team is not the same as a productive team.
22+
23+
- **One backlog, ranked.** The top is always the next most valuable thing. No parallel priority lists.
24+
- **Thin vertical slices.** Each story delivers end-to-end value — UI through to data. No "backend-only" stories that wait weeks for a frontend.
25+
- **Limit WIP.** Finish before you start. Work-in-progress is inventory; inventory is risk.
26+
- **Definition of Ready / Done are contracts.** Ready = small enough, clear enough, testable. Done = merged, deployed, observable, documented.
27+
- **Estimate to align, not to commit.** Sizing is a conversation tool. If we need a date, we forecast from throughput, not from gut feel.
28+
- **Retro every two weeks, minimum.** One concrete change per retro, owned by a person, checked next retro.
29+
30+
---
31+
32+
## 3. How we build
33+
34+
**Simple, tested, readable — in that order of argument-winning power.**
35+
36+
- **TDD where it pays.** Red-green-refactor for logic with branching, edge cases, or money. Not dogma for trivial glue.
37+
- **Pair or review, always.** No code reaches `main` without a second pair of eyes. Pairing counts as review.
38+
- **Trunk-based.** Short-lived branches, merged daily. Feature flags over long-lived branches.
39+
- **SOLID, applied with judgement.** Especially: single responsibility, and depend on abstractions at module boundaries. Don't invent interfaces you have one implementation of.
40+
- **DRY the knowledge, not the code.** Two things that look the same but change for different reasons are not duplication. Premature deduplication is worse than repetition.
41+
- **YAGNI.** Build for the requirement in front of you. Extensibility you don't need is complexity you pay for.
42+
- **Clean Code basics.** Names reveal intent. Functions do one thing. Comments explain why, not what. Delete dead code.
43+
- **Refactor continuously.** Leave the code better than you found it. Refactoring is part of the story, not a separate ticket.
44+
45+
---
46+
47+
## 4. How we ship
48+
49+
**You build it, you run it.** The team that writes the code owns it in production.
50+
51+
- **Everything in version control.** Code, infra, pipelines, dashboards, runbooks.
52+
- **CI on every commit.** Build, lint, test, security scan. Red build blocks everyone — we fix it first.
53+
- **CD by default.** `main` is always deployable. Deploys are boring, frequent, and automated.
54+
- **Feature flags for risk.** Decouple deploy from release. Roll forward, not back.
55+
- **Observability is a feature.** Logs, metrics, traces, and a dashboard ship with the service. If you can't see it, you don't own it.
56+
- **Alert on symptoms, not causes.** Page on customer impact. Everything else is a ticket.
57+
- **Secure by default.** Least privilege, secrets in a vault, dependencies patched, threats modelled for new surfaces.
58+
- **Runbooks for the top 5 alerts.** Written by the team, tested in game days.
59+
60+
---
61+
62+
## 5. How we improve
63+
64+
**Learning is the work.** The service will outlive any single feature we build.
65+
66+
- **Blameless postmortems.** For every incident that hurt a customer or woke someone up. Output: actions with owners, not blame.
67+
- **Measure what matters.** Lead time, deploy frequency, change fail rate, MTTR (the DORA four). Plus whatever customer metric this service moves.
68+
- **Kill your darlings.** Deprecate and delete code, features, dashboards, and meetings that stopped paying rent.
69+
- **Share the learning.** Demos, brown bags, ADRs. If only one person knows how it works, that's a bug.
70+
71+
---
72+
73+
## Principles we borrow from
74+
75+
- **Agile Manifesto, Scrum, Kanban, XP** — iteration, flow, TDD, pairing, collective ownership.
76+
- **Lean Product Development** — small batches, flow, limit WIP, build quality in, defer commitment.
77+
- **DevOps / DevOps Dojo** — you build it you run it, automation, measurement, blameless culture.
78+
- **SOLID, DRY, YAGNI, Clean Code** — keep the inside of the code honest.
79+
- **DORA** — measure delivery performance.
80+
81+
---
82+
83+
## How this document works
84+
85+
This is version 0. We review it every quarter and after any incident that exposes a gap. Propose changes in a PR; we decide in a retro.

0 commit comments

Comments
 (0)