用户吐槽：Azure DevOps CI 体验太差

作为一名软件开发者，我亲身体会到快速低成本地构建高质量的产品是一件多么困难的事情。它就像是一门艺术，有时候我们会成功，有时候却会演变成类似于奥巴马时代医疗保健政府网站那样的东西。我们对最终产品的控制水平各不相同，如果要归咎责任，最终往往会落到决策层中错误的人身上。微软的 Azure DevOps（前身是 Visual Studio Team Services）尽管表现出良好的意图，但却是一场决策糟糕和执行不力的完美风暴。

从高层次来看，这个产品看起来棒极了。它为问题跟踪、CI、版本控制、项目管理等问题提供了一个一体化的解决方案。可惜的是，它的复杂性却很成问题。在更新问题后，其他屏幕常常不刷新，无法让人知道发生哪些了变更。例如，更新工时或设置工作量不会触发图表自动更新，需要手动刷新页面。虽然这些问题看起来都是局部的小问题，但放在一起就会导致整个产品在完成日常任务时变得非常困难。

老实说，到目前为止所提到的一切问题都还是可接受的，尽管很不幸。每种工具都有它的问题，而真正“磨砺我的意志”的是 CI 系统，他们称之为管道。在我看来，CI 的实现非常糟糕。不完整的 Github 集成（GitHub 现在是微软的）、通过代理运行的构建会随机崩溃、到 2019 年仍然不提供任何形式的构建缓存，相比其他工具（如 GitLab、CircleCI、Travis，等等），这是一款令人失望的产品。

这篇文章的主要目的是帮助读者节省时间，避免在使用这个工具时犯下我曾经犯过的一些错误。其次，我也希望找到微软能够做决定的人，并说服他们尽快解决这些问题——毕竟，我们为这个工具付了钱。最后，我想澄清一下，我已经就多个问题联系了微软支持部门，但都没有得到解决。

查看构建状态

分辨率问题

奇怪的是，如果你的显示器不够大，那么构建信息页面会隐藏掉大量的数据。即使使用标准的 1920x1080 分辨率，也不可能一次看到所有列。你肯定在想：“这家伙不知道怎么使用水平滚动条”。事实上，我当然知道如何使用水平滚动条，但微软却不知道。

几乎不显示关于每个构建的信息，而且没有水平滚动条。被隐藏掉的区域是一些代码提交及其作者的信息，还有一些是我所在公司的信息和其他敏感信息。

换了大显示器，可以看到更多的列，但仍然不够大，因为无法看到所有的列。

你们可能想知道在手机上是怎样的，但实际上这个工具的 CI 区域完全不支持手机。即使你在手机上使用桌面模式，因为无法更改屏幕大小，大多数列仍然是看不到的。据我所知，现在还没有原生的移动应用程序。

但愿你想看的只是分配给你的任务。

诡异的构建

一个真实而悲伤的故事

要么是微软的网络，要么是 CI 代理服务，要么是两者的某种组合出现了问题。使用由微软托管的 Linux 代理，你会得到使用 hypervisor 运行 Ubuntu 的 Windows 服务器。通常，构建机器实例需要大约 6GB 的可用内存和两个 E5 Xeon Intel 内核。

在运行托管构建时，我们经历了由于机器消失而导致的高构建失败率。这些失败的构建随机发生，有时甚至发生在构建开始之前。通常，导致构建失败的原因都是一样的：“与服务器失去通信”。我们花了几个月时间寻求帮助，希望这个问题能够得到解决，但最后还是决定在 AWS 上构建自己的自托管代理。我们希望它能解决所有的问题，而它确实做到了！我们的构建非常快，但在十分钟后，又出现了“与服务器失去通信”。

不幸的是，这个问题不仅出现在它们的托管代理上，而且似乎还影响到在我们自己的实例上运行的自托管代理。在进一步诊断这个问题之后，我发现 EC2 实例完全没有响应。好吧，我想，一定是服务器坏了或者出了其他什么问题。我关掉了旧实例，创建了一个新实例，并再次设置代理。现在一切又好起来了！

在头几个小时内，构建运行得很顺利。正如预期的那样，代理最终在一次构建过程中又死掉了。构建作业开始排起了长队，我越来越沮丧，AWS 通知我说我们的实例出了问题。一个小时后，面对反应迟钝的服务器，我还是命令它重新启动。为了调试这个问题，我查看了传统的日志存储位置，如 dmesg、kern 和 var。但我仍然无法找到任何根本原因，也找不到任何迹象表明发生了什么。

检查构建

要不要记录日志

要不要记录构建日志？这是最奇怪的实现决策之一。如果在触发构建时已经打开了构建信息页面，那么就可以看到整个构建的历史。如果你是一般用户，并且在几分钟内没有查看构建过程，那么你只能看到从加载当前运行步骤的构建日志开始的历史记录。而作为 Android 开发人员，我看到的第一个构建输出通常是这样的:app:assembleDebug—日志的开头部分丢失了。我们可以在构建完成后通过刷新页面查看整个日志，但这样通常会浪费很多时间。

亲爱的缓存

给我缓存吧

如果我告诉你微软绝对没有提供任何形式的构建缓存，你可能不会相信。因此，我直接贴出链接https://visualstudio.uservoice.com/forums/330519-azure-devops-formerly-visual-studio-team-services/suggestions/32044321-improve-hosted-build-agent-performance-with-build，有人呼吁微软推出这个功能，而微软表示正在考虑要实现它。微软确认他们从 2018 年 2 月开始解决这个问题，但现在已经是 2019 年了，什么进展都没有。这个问题很烦人，同时又衍生出另一个完全不同的问题。如果你用谷歌搜索“azure devops 504 gateway”，你会发现有很多用户在构建时也遇到了网络问题，包括我在内。据推测，构建缓存的缺乏正在压垮他们的网络，导致他们的构建服务器被包存储库系统拒绝。在我们的构建中，经常遇到 HTTP 错误，下载依赖项导致了不稳定的构建。我们跟踪由网络问题导致的大量构建失败，不包括前面描述的“通信丢失”导致的失败百分比。有时构建甚至无法连接到 Github。

微软拥有自己的云服务，却在 CI 实现中缺少缓存，这让我感到非常困惑。市场上的其他 CI 产品，如 Circle、Travis、Jenkins 等，通常都有缓存实现，并将缓存视为 CI 流程的基本部分。

失败的构建

Github 是谁?

CI 的另一个有趣的问题是与 Github 之间的通信。当构建失败时（例如 CI 系统不稳定），通过仪表盘重新排队的构建作业在完成时不会更新 Github。也就是说，你必须推送错误的提交，或者将推送变更强制到拉取请求上，以便触发新的构建来更新 GitHub 拉取请求。作为 Travis 和 Circle 等系统的坚定支持者，我说服了很多人为这些服务掏钱。它们通常运作得很好，不会出现上述的问题。不管怎样，我和我的同事每周都要花很多时间来处理微软的这个问题。

英文原文：https://toxicbakery.github.io/vsts-devops/microsoft-devops-ci/