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 是处理大规模贡献的另一个重要组成部分。
直到最近，我们还依赖于开源社区对公共持续集成的默认选择：Travis CI 用于我们的 Linux 和 macOS 构建，以及 AppVeyor 用于 Windows。此外，我们使用 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 解决方案。Visual Studio Code 在 Azure Pipelines 上的构建 在一次构建中运行我们的编译、卫生检查和测试套件，自动将构建分发到不同的平台。由于我们使用的是 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