Sven is DocOps engineer and part of the content team of Pronovix. He collaborates with customers to define and integrate style guides and quality assurance checks of documentation.
Sven has a background as Site Reliability Engineer (SRE) and is part of various open source communities.
Many of us have heard about Docs As Code. Applying the same tooling and delivery CI/CD (Continuous Integration and Continuous Delivery) pipelines as developers to improve the quality of (API) documentation sounds nifty. We’ll take a look at the philosophy, best practices and how to get started.
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.