# Continuous documentation: publishing docs early and often

DevFeed: [Continuous documentation: publishing docs early and often](<https://devfeed.tech/articles/continuous-documentation-publishing-docs-early-and-often-30942.md>)

Original publisher: [Read original article](<https://www.doctave.com/blog/continuous-documentation>)

Author: Niklas Begley

Published: 2024-01-23T07:00:00Z

Content type: tutorial

Language: en

Sources: [Doctave - Build beautiful developer portals with docs-as-code](<https://devfeed.tech/sources/doctave-build-beautiful-developer-portals-with-docs-as-code.md>)

Topics: [Documentation](<https://devfeed.tech/topics/documentation.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>), [monorepo](<https://devfeed.tech/topics/monorepo.md>), [Git](<https://devfeed.tech/topics/git.md>), [GitHub](<https://devfeed.tech/topics/github.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [ci-cd](<https://devfeed.tech/tags/ci-cd.md>), [docs-as-code](<https://devfeed.tech/tags/docs-as-code.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [git](<https://devfeed.tech/tags/git.md>), [github](<https://devfeed.tech/tags/github.md>), [monorepo](<https://devfeed.tech/tags/monorepo.md>)

## AI overview

This article explains continuous documentation as a docs-as-code practice: update documentation incrementally alongside product changes, make documentation part of the release definition of done, and review and deploy documentation with code. It also discusses enabling contributions from engineers, technical writers, and product managers.

## Source excerpt

One of the key pillars of docs-as-code is releasing changes via CI/CD. Just as how software is often released continuously, we can keep our documentation up to date as the product changes. This lets us achieve continuous documentation: instead of large bulk releases, we can incrementally improve our documentation, as we make changes to our product. Let's dive into how continuous documentation is implemented in practice. Making it easy to make changes The key to continuous documentation is making it easy to contribute to documentation. We want to lower the barrier to making changes, and empower contributors to make the docs better. Let's see how! Smaller, iterative changes The bigger the change, the harder it is to make. Everyone who has worked in the technology industry has seen large project spiral out of control, missing deadlines, and seemingly never ending. Fast-moving teams get around this problem by splitting work into smaller chunks. Instead of a large monolithic release, preferring smaller, iterative changes that are easier to manage. Small changes are easier to review, have less risk, and can be shipped with fewer checks in place. Releasing docs with code It makes sense to update your product and documentation at the same time. Documentation should be in your "definition of done": a hard requirement for a feature to be released. A Git monorepo, it's natural to even have code and documentation changes in the same branch or pull-request. Engineers and technical writers can work in the same branch, and eventually merge and deploy the code and documentation in tandem. This is what we do at Doctave. We use a monorepo with a dedicated /docs folder. Every customer-facing feature will have documentation changes included, and get reviewed as part of the same pull-request on GitHub. A multi-repository setup requires some more coordination. but the same principles apply. Every feature change should have a corresponding change in the documentation repository. Empowerin