GitLab公司使用GitLab作为单一平台，通过使用“文档即代码”工作流程来归档GitLab。听起来是不是有点混乱？
GitLab技术写作团队使用GitLab来计划、创建、审查、编辑和发布GitLab文档。而且因为使用docs-as-code工作流程，GitLab团队可以通过一个小型、热情、高效的团队来制作大量内容。
如果您不熟悉文档即代码，这里有一个定义：
文档即代码是一种开发和发布产品文档的方式。它使用与软件代码开发相同的工具和流程，将文档文件与代码文件一起放置在存储库中以进行版本控制。
如果您想知道您的公司是否可以在GitLab中采用docs-as-code工作流程，本文披露了GitLab如何做到这一点的五个事实。
使用GitLab来规划GitLab功能和文档内容更新产品经理、用户体验设计师、工程师和质量保证团队共同规划我们的功能工作。也许当您计划发布时，您使用看板，或者您在第三方工具中创建问题。
GitLab使用史诗和问题来计划我们的工作，并使用问题板来跟踪我们的进度。我们重视透明度，因此所有人都可以获得所有这些信息，包括有关规划的讨论。技术写作团队随时了解开发状态。
如果我们有更大的文档工作，我们会在GitLab中跟踪它们，使用GitLab进行更改，并在GitLab中将问题标记为已完成。如果一年过去了，我们想记住我们为什么要做出改变，我们会搜索GitLab并找到做出改变的人以及原因。如果您现在使用许多不同的工具，想象一下在一个地方查看所有内容会是什么样子。一切都感觉更快，更有效率。您可以跳过通常花在浏览电子邮件和网站以及Slack上来查找丢失的讨论的时间。这一切都在GitLab中。
使用GitLab来提供和接收有关文档的反馈如果您已经担任作家一段时间，您就会知道让人们审查您的内容是多么痛苦。
在GitLab，我们的开发人员为我们所有的新功能编写内容的初稿。他们将内容保存在与代码相同的存储库中。功能文档是我们开发“完成的定义”的一部分。他们将草稿内容分配给我们的作者，他们对其进行审核、添加建议，并将他们的想法和编辑反馈给作者。
作者自己也为内容更改打开合并请求(MR)。并且无论谁打开MR（作者、开发人员、支持工程师、社区贡献者），我们都可以轻松地评论彼此的工作。
在合并请求中，就像选择一个建议按钮一样简单。您可以评论一行或多行。您可以提供更改或编辑，创建合并请求的人可以轻松应用您的更改，或创建他们自己的竞争建议，您可以讨论它。要邀请其他人加入对话，您可以在评论中输入他们的用户名，他们会将您的评论视为GitLab中的待办事项。这样，您可以讨论任何更改。它是透明和包容的。
因为文档内容是markdown的，类似于纯文本，所以很容易查看文件版本之间的差异，并查看谁提交了哪些更改。
也许您曾在PDF、Word文档或带有评论的Google文档中进行评论的地方工作过。当您尝试此工作流程时，您会发现该流程的效率更高。没有人传递过时的文档版本。没有人会在无意中删除其他人的评论的更新。
如果有人想知道我们为什么要进行更改，可以轻松查看页面的历史记录，甚至查看谁应该为特定行“责备”。
您不必存储PDF文档的版本并尝试搜索谁建议了哪些更改。这一切都在GitLab中。
使用GitLab来预览文档内容在GitLab，我们有工具可以在本地生成文档站点内容，但您也可以直接从合并请求轻松共享文档站点的视图。如果您正在尝试一个想法并且想要向某人展示，您可以打开一个合并请求，生成我们所说的“评论应用程序”，瞧，更改后的文档站点可以在一个公开的URL上找到。
您的更改是可见的，您可以对其进行迭代或按原样提交。这给我们带来了GitLab中另一个最有用的功能。
使用GitLab测试每个内容更改也许您正在使用第三方工具来测试文档中的链接，或者检查拼写和语法规则。
我们正在使用第三方工具（用于链接的Nanoc，用于拼写和语法的Vale），但与其他所有工具一样，这些工具可以合并到GitLab和编写器工作流程中。
每个作者都在本地安装了我们的工具，并且可以查看所有内容，从文档的阅读级别到本地计算机上的被动和主动修复。但是对于那些没有工具集的贡献者，我们在管道中运行我们的测试版本作为每次提交的一部分。
如果您是开发人员并且您不认为自己是专门的文档工程师，您可能会发现管道在您的合并请求上失败，因为重要的语法或品牌规则。我们已经定义了许多规则的列表，并为它们分配了重要性级别。因此，我们不仅有样式指南和单词列表，而且还运行测试以确保我们的内容不会偏离这些规则太远。
使用GitLab生成HTML输出，并将输出托管在GitLab页面上我们的CI/CD管道转换我们的markdown内容并将其编译成HTML。然后我们在docs.gitlab.