Visual Studio Code 使用 Azure Pipelines
2018年9月12日 João Moreno, @joaomoreno
作为 Visual Studio Code 团队的一名开发人员，我的职责之一是维护和改进我们的构建和持续集成 (CI) 基础设施。鉴于 Azure Pipelines 的最新功能发布，Visual Studio Code 团队已显著改变我们利用微软技术的方式，为我们的开发人员和用户提供更好的协作平台。在这篇博客文章中，我将引导您了解 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