Building Docs like Code: Continuous Integration for Documentation
summary
Move documentation into the repository and wire it to CI so commits build and publish artifacts automatically. Uses MKDocs and Sphinx (doc tests validate examples), a Cookiecutter starter, Travis or similar CI, and GitHub Pages for deployment. A real team files 29 internal and 111 external sections, reduces onboarding from months to days, and keeps docs versioned and up to date. The concrete claim is reproducible: a working docs-as-code pipeline that auto-tests links and snippets and publishes without human intervention.
AI-written summary · about
chapters (19)
- 0:00Intro
- 1:02A Common Approach to Documentation
- 1:49Issues with This Approach
- 3:12Why Do Developers Dislike Writing Documentation?
- 3:53The Real Issue
- 5:19What Do We Mean When We Say "Treat Docs Like Code"?
- 6:41What Do We Gain From This?
- 9:23Case Study
- 11:41How Does This Change the Workflow?
- 12:42What is Continuous Integration and Continuous Deployment (CI/CD)?
- 13:11What Does This Mean for Docs?
- 14:11Types of Documentation
- 17:01Documentation Tools - Mkdocs
- 19:20Documentation Tools - Sphinx
- 20:46Sphinx - Documentation Testing
- 21:48Documentation Tools - ronn
- 22:33My Solution
- 30:57Final Thoughts
- 33:02But Wait! There's More
related talks
36mBuilding Docs like Code: Continuous Integration for Documentation
23mTreating Documentation like Code: a Practical Account
44mPushing documentation (so it doesn't hurt anymore)
45mDocs as Code Fix a poor documentation culture in your organization
42mEngineering Documentation
47mEngineering Documentation
50mContinuous and Automated Documentation Docs As Code in Practice
44mUseful and Beautiful Developer Docs and How to Create Them