Empowering our users with more tools at their disposal...
Our customer’s missions are growing in complexity each day, and we continuously evaluate and add new tools to our platform to meet those customer’s needs.
Our Docs-as-Code initiative is built on a simple principle: treat documentation as a living, breathing part of the development process.
Our documentation framework is rooted in the Diátaxis methodology, not just for its organizational clarity, but because it creates a more user-centric experience. Dividing content into tutorials, how-to guides, reference documentation, and explanations ensures that users, whether developers or stakeholders, can find exactly what they need without digging through extraneous information. This separation helps maintain focus and relevance, which are crucial when users need fast, actionable answers.
We’ve also automated much of the documentation process using tools like MkDocs and Docusaurus, ensuring that changes to code or configurations trigger immediate updates to documentation. This approach aligns with a key principle in automation: documentation should evolve alongside the system, not lag behind. For architecture documentation, we apply the C4 Model, chosen for its simplicity and accessibility. By avoiding complex tools like UML, we empower all team members—not just architects—to contribute and understand. The diagrams are automatically updated via CI pipelines, keeping everything in sync with the current architecture.
For release documentation, we use Semantic Versioning, Semantic Release, and Conventional Commits to automate changelog creation, ensuring that every release is traceable and communicated efficiently across all channels. This practice not only enhances transparency but also provides a single source of truth for changes, making it easier for both technical and non-technical stakeholders to track progress.
Our Docs-as-Code initiative is built on a simple principle: treat documentation as a living, breathing part of the development process. By applying a GitOps approach, where documentation is stored and managed as Markdown in GitLab, we ensure that every piece of documentation is version-controlled, reviewed, and updated in sync with the code itself. When should this be adopted? Whenever your documentation is critical to compliance, security, or frequent iteration cycles. For highly regulated environments like the DoD, this practice guarantees that all documentation is not only accurate but also auditable, supporting strict compliance needs.
By using static site generators like MkDocs or Docusaurus, we can transform Markdown files into user-friendly interfaces, ensuring that whenever there’s a significant change in code or configuration, the documentation automatically reflects those changes. Why is this important? It prevents the common issue of out-of-date documentation, which can mislead users and undermine the trustworthiness of the platform. In a fast-moving DevSecOps environment, automation here ensures that documentation evolves with the platform, rather than becoming an afterthought.
The Diátaxis methodology structures content across four dimensions: tutorials, how-to guides, reference docs, and explanations. Why this structure? Because each type of content serves a different purpose for users, ranging from hands-on guidance to deep technical explanations. When should you use it? When your documentation needs to serve multiple audiences with different needs—in our case, developers, security teams, and non-technical end users.
At its core, documentation should reflect who it’s for. We’ve adopted a user-first approach because different groups—whether they’re security stakeholders, developers, or end users like warfighters—need different kinds of information, and they need to find it quickly. Why this focus? Tailoring documentation for your audience ensures efficiency, improving the user experience by cutting down on time spent searching for relevant content.
For example, security teams are primarily concerned with how our platform adheres to RMF processes, while developers need quick-start guides and technical references for deploying on SmoothGlue. By focusing on the when and why of what each audience needs, we make sure the right information is accessible to the right people at the right time. When should you think about audience segmentation in documentation? From day one. Tailored documentation isn’t just a nice-to-have—it’s an operational necessity when dealing with complex, multi-faceted platforms.
One of the biggest challenges in DevSecOps is keeping architecture documentation up to date. By adopting the C4 Model, we solve the problem of complexity without sacrificing clarity. Why C4? Because it enables even non-architects to contribute to and understand architecture diagrams. These diagrams evolve with the system, ensuring that when there’s a change in architecture, the documentation reflects it immediately, not weeks later.
The diagrams are automatically generated via CI pipelines, ensuring that each time new code is committed or infrastructure is updated, the architecture is documented and version-controlled. Why automate architecture documentation? To reduce the risk of human error and ensure that documentation stays aligned with system changes. When should you automate this? As soon as your system starts evolving rapidly. Manual architecture documentation may work early on, but as complexity grows, it’s too easy for it to fall out of sync.
For release documentation, we leverage Semantic Versioning, Semantic Release, andConventional Commits. Why this trio? They provide a standardized way to automatically generate release notes and changelogs, ensuring traceability from feature requirements to code commits to final releases. This becomes especially important when your platform is mission-critical and every release needs to be tracked, validated, and communicated.
By automating release documentation, we ensure that every change, from minor bug fixes to major feature updates, is properly documented. When does this become critical? When transparency and accountability are non-negotiable—for example, when working with government clients or regulated industries. Automated changelogs reduce the manual workload on developers and ensure that no change slips through the cracks.
Automating documentation isn’t just about making life easier—it’s about ensuring accuracy, compliance, and efficiency. Why should you automate? Because manual processes break down at scale. When should you automate? As soon as your documentation becomes mission-critical to your operations, whether for internal teams or external stakeholders. By combining automation with user-centric content organization (via Diátaxis) and standardized release documentation (via Semantic tools), we ensure that our documentation is not only always up to date but also clear, accessible, and compliant with the strictest industry standards.
Our customer’s missions are growing in complexity each day, and we continuously evaluate and add new tools to our platform to meet those customer’s needs.
In his remarks, Mitch Rubinstein, BrainGu’s Director of Mission Systems Group, contextualized cyberwarfare with patterns of conflict throughout history, described the DevSecOps approach to security, and provided examples illustrating DevSecOps as a critical factor in the time-competitive cybersecurity environment of today.
Traditionally, the saying is 'think outside the box.' All too often, when approaching the 'impossible,' it is assumed that a current or previously tried approach is entirely useless. We believe that all progress against a difficult outcome is valuable, so we seek to evaluate the situation, maximize its strengths, and minimize its weaknesses.