- π― The exploration and experimentation of how documents can be transformed into valuable sources of information. π
- π Live Demo: solution.job4u.io
- π§ docs.oceansoft.io
βοΈ Documentation as Code (Docs-as-Code) is a growing trend in software documentation, in which documentation is written using the same tools as code:
- Issue Trackers, Version Control (Git), Code Reviews:
Github
- Plain Text Markup (Markdown, Asciidoc, reStructuredText):
Markdown
- CI/CD, Automated Tests:
AWS Amplify
π The product team needs to follow the same workflows as the development teams. As a result, both writers and developers feel ownership of documentation and work together to create a valuable source of information:
- Adopt an βagileβ approach to content creation
- Content is the responsibility of the entire team, not just the technical writers
- The culture of adapting and improving content and processes over time.
In general, Docs-as-Code offers the following benefits for Technical Documentation:
- By integrating with the Development Team more effectively, the Release Technical Writer can deliver higher-quality documentation (information architecture, customer experience, etc.) more quickly through collaboration with multiple voices.
- Developers often write the first draft of documentation, avoiding the documentation becoming a bottleneck. The writers then define and automate the process, including approval gates, automated quality checks, such as spelling and grammar, and external content publishing, such as https://solution.job4u.io and/or Developer Portal.
- New features canβt be merged if they donβt include documentation, which incentivizes developers to document them immediately. Furthermore, Documents-as-Code eliminates the need for proprietary tools for technical writing and publishing.
The above diagram depicts a simple content authoring, review, and publishing workflow:
- The documentation is located in the docs folder in the docs branch. We use an IDE like VSCode to create markdown files as well as extensions for diagramming tools like DrawIO, so you can also version control your diagrams!
- Authors publish the branch to the GitHub source control system. Technically, they donβt have to do this every time, but itβs good practice as a backup.
- Authors create a Pull Request (PR) when they are ready to submit content changes.
- Content Editors will receive a notification when a new PR is published. Upon reviewing the content, the Editor can approve or reject the submission; the Editor can add comments so the author knows what must be approved.
- Once a PR is created/updated (following feedback), an automated pipeline will execute various quality checks against the content.
- Once the editor has approved the PR, the content can be merged into the main branch.
- Content from the main branch can be built and deployed automatically to users using
AWS Amplify
CI/CD (Continuous Integration and Continuous Delivery) Pipeline.
Ideally, the architecture document should be prepared in Markdown format and managed in a Git repository to ensure high quality, manageability, version control, and traceability.
We use the following developer tools and processes to create and deliver content:
Documentation template: VS Code || Intellij
Developer-based workflows: GitHub || GitLab
Static Site Generators (SSG)
CI/CD Pipeline:
Script-Based Design Tools & Architecture Templates
β
Β Markdown Extensions
β
Β AWS Amplify CI/CD Pipeline
- Docs Like Code - Anne Gentle
- Modern Technical Writing - Andrew Etter
- Amazon Web Services (AWS) told the story of their teamβs move to docs as code: what worked, what didnβt, whatβs next.