Applying the Docs As Code method assumes that you use the same tooling (e.g. editor, version control, etc) for writing (API) documentation that you use for working on your code. In the same manner that code editors are configured with plugins for reporting coding style violations, you can configure your code editor with plugins that report inconsistencies with your company’s editorial and content style guides (quality assurance).

Depending on your documentation, these could be plugins for checking the consistency of your markup language, the style of headings, the length of documents and many more. Consistent, tested documentation can help your product and your development cycle. Consistency means that you write your documentation according to a defined standard reflecting your product and company. It also means that you can find information quickly, and understand that information when you encounter problems.

We’ll talk about how we setup and configure our workflow and delivery pipeline depending on our project needs. Lastly, we’ll see how we work together with our SRE and DevOps teams to automated test, build and deploy our docs with for example, Jenkins, Travis, CircleCI, DroneCI or Buildkite.

We’ll break “Docs As Code” down to its base principles

• Part one: Content strategy, Editorial style guidelines, Content analytics
• Part two: Automated testing, Deploying (publishing).