[译] 自动化持续集成/持续分发，以节省更多时间编写代码

• 原文地址：Automate CI/CD and Spend More Time Writing Code
• 原文做者：Cormac Foster
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：Yong Li
• 校对者：zhaoyi0113，LeviDing

自动化持续集成/持续分发，以节省更多时间编写代码

该文章由 微软 Visual Studio 应用中心 赞助。请支持咱们的合做方，是他们让 SitePoint 成为可能。

什么是软件开发中最棒的部分？编写漂亮的代码。

什么是最糟的部分？其他的一切。

开发软件是一份精彩的工做。你会用全新的方法解决问题，取悦用户，而且亲眼见证你的工做让生活更美好。然而在咱们花费时间编写代码以外，咱们经常还要花费一样多的时间来管理随之而来的各类琐碎开销 —— 这些都是在浪费时间。如下是一些最大的效率黑洞，以及在微软咱们是如何处理这些问题，以帮助你节省一些开发时间。

1. 生成

让你超赞的应用到达用户手中的第一步是什么？让它出现。许多人可能以为把源代码转换成二进制文件，在今天已经不是什么难事了，但实际上它依然是。取决于项目的不一样，你可能一天须要编译好几回，或是在不一样的平台上编译，而这些都占用了你本能够用来编写代码的宝贵时间。除此以外，若是你在生成 iOS 应用，你还须要 Mac 生成代理，尤为是当你使用跨平台框架来建立应用时。而这甚至都不必定是你最主要的开发工具。

你想要夺回这些时间，最好的办法就是自动化（我还会屡次重申这点）。你须要将配置和硬件管理都自动化，使得应用须要生成的时候，直接就能够开始生成。

咱们对于这一需求的回应就是：Visual Studio 应用中心生成服务。这一服务帮你自动化全部你不想手动重复的步骤，使得你每次提交代码的时候，或者不管什么时候你、你的测试团队、或者你的发布经理但愿的时候，你均可以快速生成。只要将生成服务链接到 GitHub，BitBucket 或者 VSTS 仓库，选取一个分支，配置几个参数，你就能够在云中生成 Android、UWP 甚至 iOS 和 macOS 应用，而无需管理任何硬件。若是你有更特别的需求，你还能够添加 post-clone、pre-build 以及 post-build 脚原本进行自定义。

2. 测试

我花了许多年作软件测试。在个人职业生涯中，如下是我最讨厌听到的三个问题：

“你完成了吗？”

“你能够重现吗？”

“真的有这么糟糕？”

在过去，已经很难有足够的时间和资源来进行完全的，像样的测试。可是移动开发的出现让这一问题更加恶化。现在咱们须要将更多的代码更加频繁地分发到更多的设备上去，咱们不能浪费几个小时来重现一个神出鬼没的重大故障，咱们也没有时间来争论某一个 Bug 是否严重到推迟产品发布时间。然而同时，咱们又是最终须要对没法忽视的故障和劣质产品负责的人。做为团队的成员，咱们但愿比问题更快一步，来提高质量，而不是让问题阻碍了发布。

因此解决之道是什么？固然是”自动化“。但必须是有意义的自动化。若是你不能整合到一块儿的话，一张张的数据表和一个个存满截屏的文件夹就什么用处也没有。当你临近截止日期，而又必须说服产品负责人来打电话停止发布的时候，你不只要给出易于他们理解的信息，同时又要给开发人员保留足够的细节来供其修复。

为了改善这一问题，咱们建立了应用中心测试服务。该服务能够在数以千计的真实设备上使用数以百计的不一样配置来进行自动化 UI 测试。由于测试所有是自动的，每一次都确保运行彻底相同的测试，这样在每一次生成中你都能马上发现性能问题和 UX 误差。测试会生成截图和视频，也会生成性能数据，这样任何人都能发现问题，而开发人员也能点进详细的日志中，即刻开始修复问题。你还能够在每次代码提交时先在个别设备上作抽查，而后再在数以百计的不一样设备上作回归测试，以确保对全部的用户都一切正常。

3. 分发

你终于完成了一个应用而且它能像预期同样正常工做，太棒了！可是真正的迭代如今才开始。你想在应用抵达终端用户以前就知道其余人怎么看你的应用，可是你要怎么作呢？建立一个 beta 版本已经足够难了，而要确保每个人都有你应用的最新版本（若是是移动应用，甚至要先确保用户可以安装它）简直要花费你所有的时间，而且你的团队成员谁都不肯意作这样的工做。

再一次，自动化。当你准备好推送一个版本的时候，你须要自动化的通知流程以及应用分发流程，而且你须要在每一次你生成的时候（或至少发布经理赞成的时候），这二者都可以自动触发。

咱们的解决方案是应用中心分发服务。你须要的只是一组邮件地址，就能够把你的版本发布到内部用户或 beta 测试用户的手中。你只需建立一个分发组，上传你的版本（或者从源代码仓库生成），而后分发服务就会处理剩下的一切。若是你以为这听起来就像 HockeyApp，你猜对了。应用中心分发服务就是下一代的 HockeyApp，将它的自动化分发功能整合进咱们其它的持续集成/持续分发服务之中。一旦你完成了 beta 测试，分发服务就会将你的应用部署到 Google Play，苹果的 App Store，或者 —— 对于企业用户来讲 —— 微软的 Intune，从而让你的应用抵达最终用户手中。

4. 闭环

人们常常谈论部署流水线，但咱们不知足于单向的部署过程。若是你可以知晓在应用发布完以后发生了什么，你就能够把反馈意见告知开发人员，由此造成一个闭环来使你的产品更好、更快。这一反馈信息以两种形式存在 —— 关于用户如何和你的应用进行交互的分析，以及必不可少的，关于应用在什么时候，发生怎样的故障的报告。

先说第二点，由于故障很要命。当应用出现故障的时候，虽然你想快速地了解状况，但你更须要知道故障到底有多紧要。在一个不起眼的小功能中却影响到全部人的故障，一般比只有 iPhone 4 用户彻底没法启动应用，要更严重。应用中心的故障服务能够将类似的故障进行分组，而且告知你最受影响的平台，以使你作出明智的分检决定。当你准备好开始修复问题的时候，故障已经彻底符号化，全部你须要的信息已经准备就绪。你能够自动地在你的故障跟踪程序中建立记录，方便开放人员无需中断他们的工做流就能够开始修复故障。更多的自动化再一次带来更多的时间，以编写更好的代码。

对于第一点的分析数据，你一般须要一些开箱即用的工具。应用中心分析服务提供了用户层面和设备层面的、侧重于参与度的度量应用，这些都是产品负责人最但愿见到的。它们能够告诉你诸如：是谁在使用哪些设备、使用得多频繁、在哪里使用、使用多长时间等信息。固然，你的应用不会和别人的彻底同样，所以你更能够建立和跟踪自定义的度量，好比“预约了乘车”或者“选择了配送上门”。若是你须要更深刻的分析，咱们还支持持续导出到 Azure Application Insights。

5. 使用手边的工具开始工做

你能够花费成天的时间来纸上谈兵地构想你完美的持续集成/持续分发方案，可是除非你能付诸行动，它分文不值。无论是集成一个你十分偏心的现有系统（或许你只是不得不用），仍是先自动化一些小的手动流程再逐渐改善其它部分，重要的是你能利用手边可用的工具当即开始行动。

固然，在这里个人立场是有倾向性的，而且我相信你应该尝试一下咱们的整套系统。不过开发者有着各式各样的需求。若是你只是想要采用应用中心的部分服务，咱们已经把它设计为彻底模块化的了。咱们为每个应用中心的服务提供了 REST API，咱们也和像 VSTS 之类的服务预先作好了集成。咱们相信这才是它应有的样子，由于是你在建立你的应用，你应该用本身的方式来建立它。

咱们欢迎你 试一试 Visual Studio 应用中心，此时它是全新的，而且能够免费开始试用。咱们但愿听到你的想法！

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。