Visual Studio Code 使用 Azure Pipelines
2018 年 9 月 12 日，João Moreno，@joaomoreno
作为 Visual Studio Code 团队的开发人员，我的职责之一是维护和改进我们的构建和持续集成 (CI) 基础设施。鉴于 Azure Pipelines 的最新功能发布，Visual Studio Code 团队已大幅改变了我们利用 Microsoft 技术的方式，以为我们的开发人员和用户提供更好的协作平台。在这篇博文中，我将向您介绍 Visual Studio Code 的一些历史，重点是我们的 CI 流程和工具以及它们如何随时间变化。
Visual Studio Code 工程
与任何其他开源项目一样，我们需要拥有正确的工具和能力来接收、分类和处理尽可能多的代码贡献。这在开发人员工具领域尤其如此，因为用户本身就是开发人员：他们是一个充满激情、勤奋且非常高效的群体。截至这篇博文发布时，我们有 148 个未解决的 PR 和 3,482 个已关闭的 PR，鉴于该项目迄今为止 3 年的生命周期，这平均每天大约有 3 个 PR。我们必须为处理如此规模的贡献做好充分准备，这不仅是为了保持项目开发的健康，也是为了帮助其他开源项目树立一个如何在此规模下运作的榜样。我们实现这一目标的部分方式是将 PR 体验带入编辑器来简化我们的工作流程，但 CI 是处理大规模贡献的另一个重要部分。
直到最近，我们还依赖于开源社区对公共持续集成的默认选择：用于 Linux 和 macOS 构建的 Travis CI 以及用于 Windows 的 AppVeyor。此外，我们还使用 Coveralls 来提供详细的测试覆盖率报告。这些服务为我们的公共仓库中的 PR 和代码分支提供质量报告，因为它们自动化了编译、运行代码卫生检查和执行多个测试套件，所有这些对于在拥有大量传入贡献的分布式团队中保持质量至关重要。这种服务组合需要理解和维护至少 3 个不同的系统，每个系统都有自己特殊的文件格式、语法、怪癖、限制等。
采用 Azure Pipelines
今年早些时候，Azure Pipelines（当时称为 Visual Studio Team Services）团队联系我们，尝试一些新东西。这一发布标志着我们转向更精简的持续集成解决方案。我们的构建现在同时在所有平台上运行，查看一下
为了实现这一转变，有很多很酷的事情需要发生。让我们来分解一下
- Azure Pipelines 对公共项目的支持使我们能够运行一个面向公众的 Visual Studio Code 项目，其中运行我们所有的持续集成构建；
- Azure Pipelines 中的构建代理长期以来一直支持 Windows、macOS 和 Linux 平台矩阵；
- Azure Pipelines 中运行 macOS、Linux 和 Windows 的Microsoft 托管代理提供了一个出色的软件堆栈来构建项目，而无需担心构建机器的维护；
- YAML CI 允许创建与项目源文件紧密相关的 YAML 定义（Visual Studio Code 为此提供了出色的扩展）。
将所有这些整合在一起，我们终于能够专注于一个单一的 CI 解决方案。Azure Pipelines 上的 Visual Studio Code 构建在一个构建中运行我们的编译、卫生检查和测试套件，自动在不同平台之间分发构建。由于我们使用 Microsoft 托管的构建代理，我们不必担心维护这些机器。
第三方集成
Azure Pipelines 还提供 GitHub 集成，这为我们的 GitHub 项目页面（尤其是在拉取请求中）提供了构建结果指示器。
我们还构建了一个聊天机器人，它连接到 Azure Pipeline 的 REST API，并在构建中断时向我们的内部聊天提供通知。
未来展望
我的下一个任务将是利用代码覆盖率报告，以获得比以前的工具组合更好的端到端 CI 流程。
事实证明，转向 Azure Pipelines 对我们来说是一个巨大的成功。由于构建不再分散各地，现在更容易理解整体代码质量。我们还整合了构建定义文件的数量和格式。我们对这一变化非常满意，并对 Azure Pipelines 的未来充满期待。
如果您想了解有关公共项目和 Azure Pipelines 的更多信息，请查看他们的博文。
您想试用 Visual Studio Code 吗？立即下载适用于您选择的平台。如果您像我们一样，总是想运行最新最好的版本，那么获取我们每天构建的 Insider 版本。您只是想联系或保持联系吗？在 Twitter 上关注我们 @code。
代表 VS Code 团队：祝您编码愉快！
João Moreno，@joaomoreno