2016 年 8 月
第 31 卷，第 8 期
此文章由机器翻译。
移动 DevOps-从客户的代码︰ 探究移动 DevOps
通过 Kraig Brockschmidt |2016 年 8 月
历史标准编写的代码很容易。今天，我们非常喜欢如 IntelliSense、 自动完成、 语法突出显示、 错误突出显示和通过如堆栈溢出的社区支持非常强大的工具。我们还可以享受一个不断增长特别有用的库和工具，其中的许多存储的库可用。但没有巨大的鸿沟 — 名副其实的高道鸿沟，您可能会说 — 之间单纯作用编写代码和交付给客户，最大值的移动应用程序的开发和最低的成本与您的业务在执行此操作。
人员逐渐被称为共同 DevOps 实质上是什么的各种方案有助于桥接该道鸿沟。我说"各种实践"，因为有多种方法来构建桥梁。通过不同的方式来定义的流程本身，并且有许多不同的工具来帮助您进行通信和管理这些进程与相关的所有人员 — 包括了解直接从您的客户的方法。在这种情况下，整个 DevOps 空间通常看上去非常混乱，使用太多的选项和过少的清晰度。
幸运的是，如在本系列文章中，我将探讨，Microsoft 现在提供了答案︰ 为移动应用程序和其关联的后端启用 DevOps 的完整的端到端堆栈。此堆栈中所示 图 1, ，Visual Studio、 Visual Studio 团队服务和 Team Foundation Server，以及 Xamarin 测试云、 HockeyApp、 Application Insights 和 CodePush 组成。
图 1 个移动应用程序和后端服务的 Microsoft DevOps 堆栈的主要组件
| 工具或服务 | DevOps 与用途 |
| Visual Studio (bit.ly/25EVbAw) | 中央开发工具，用于应用程序、 服务和测试代码，以及诊断和与源代码管理集成。 |
| Visual Studio Team Services (bit.ly/1srWnp9) | 云托管的 Agile 计划工具、 源代码、 生成服务，测试服务和版本管理。（请注意，规划工具将不会介绍本系列中）。 |
Team Foundation Server |
在本地与 Visual Studio Team Services，可将完整的自定义服务器以及对这些物理计算机的完全控制等效的功能。 |
Xamarin 测试云 |
自动和手动测试 （包括不使用 Xamarin 编写的） 的所有移动应用数以千计的真实、 物理设备可通过 Web 门户访问。 |
HockeyApp |
预启动应用程序分发到设备的直接的测试客户 （不涉及平台应用程序存储区）。此外预启动和使用自定义遥测、 崩溃分析和用户反馈报告监视生产。 |
| Application Insights (bit.ly/1Zk9Qd3) | 遥测、 诊断和后端服务的监视。 |
CodePush |
部署应用程序更新 Cordova 和本机做出反应的应用程序直接与用户设备而不需要通过应用商店。 |
此堆栈是适用于所有类型的移动应用程序︰ 为单一的移动平台，而编写的 Apache Cordova 的混合应用程序编写的本机应用程序和编写使用本机做出响应或 Xamarin 的跨平台应用程序。较好的做法 DevOps 不可接受或者全盘承诺。相反，它涉及到系统的松散耦合的活动和做法，您可以构建以增量方式，将实际值添加到您的生成移动应用程序的业务。还有可能与新项目以便生成整个 DevOps 管道，然后编写一行代码。
我将在本系列中的方法是专注于不同阶段的"发布管道"，而且看 DevOps 堆栈的哪些部分派上用场。在此篇文章中，但是，我首先需要建立一些必要的背景知识。首先我将描述内容的发布管道并确定所涉及的活动，然后讨论整体 DevOps 的工具以及实行自动化的角色的必要性。接下来，我将介绍一下 MyDriving 项目作为操作中的 DevOps 示例 （和您可以在此问题，请在文章"接纳 DevOps 时构建 Visual Studio 团队服务扩展"中找到另一个示例）。最后，我将回顾中央扮演的角色 Visual Studio Team Services （和 Team Foundation Server） 在总体的 DevOps 情景中，设置后续文章的阶段。
发布管道
管道的思路是，对于应用程序或其后端服务的任何特定版本，其代码和其他项目必须以某种方式从流向项目的源代码存储库的客户设备和客户可访问的服务器。第一次在这些设备和服务器，运行时问题 （崩溃），遥测和直接客户反馈的真知灼见必须所有流回的经验教训，后续的驱动器释放。
当然，这并不会发生变魔术一样。它是通过一系列不同的阶段后代码提交到存储库，如中所示 图 2。这些阶段包括︰
- 生成/CI: 生成的应用程序并运行单元测试;持续集成 (CI) 意味着提交到存储库触发生成和运行这些进程都自动的测试。
- 内部 QA: 执行任意数量的其他测试，并且获得审批者签署。
- 外部或预备 QA: 将该应用程序中的实际客户公开发行之前测试应用程序，并在实际条件下的服务和收集反馈的手中。此阶段还涉及到其他审批者签署。
- 生产监控和学习︰ 无论您执行多少测试，客户将几乎可以肯定会遇到问题后应用程序设置为公共方法 （即，"发布到生产"）。客户将提供什么工作原理的反馈，哪些没用价值，以及通过遥测数据显示的他们的使用模式。
.png "与相关联的 DevOps 活动的典型的发布管道的阶段")
图 2 具有关联的 DevOps 活动的典型的发布管道的阶段
您会注意到在 图 2 其中我已标记为大多数 DevOps 活动为某种形式的测试。实际上，它不是大拉伸想作为一种测试每个活动。例如，运行生成、 测试的存储库和所有其他项目是否是它们需要进行的结构。运行诊断工具是一种探索性测试。收集和分析遥测是一种方法来测试假设客户实际上如何使用应用程序。和审批者签署，如果不是直接检查是否一切就也应该是人类造成是什么？
连续验证的性能
作为不同形式的测试，所有归 DevOps 伞存在多个活动验证质量、 可靠性和应用程序传递的值。另一个角度来讲，这些活动旨在捕获，或确定缺陷，这意味着将导致应用程序以满足客户期望偏差的任何内容。几乎不用说，就在那时，，你越频繁进行 DevOps 活动 — 连续，如有可能 — 必须查找问题发布前的好的机会。
DevOps 活动还设计了最低修复它们的成本时尽可能早捕获管道中的缺陷 (由蓝色线条中所示 图 2)。很明显，成本会高得多，一旦发布应用程序，且缺陷是出开放的此时成本可能包括损失的客户损坏您的声誉和甚至法律责任 ！
将所有此组合在一起，应用程序可提供给客户，最大值和最低的成本在执行此操作非常尽最大"演员"，因为它最终将带来的结果与您的业务。优秀的应用程序，只需说过的都将很好的执行者。出于此原因，我喜欢将 DevOps 视为连续验证最广泛意义上的一词的性能。DevOps 是软件开发哪些培训、 练习、 rehearsals，并后业绩评估是对专业音乐家、 运动员和其他执行者及其相应字段中。它是如何知道和信任和监视什么您提供什么样的承诺，该网站的客户和针对您企业的完整值。
处理第一、 然后工具和自动化
在一系列有关 Microsoft 移动开发运营工具堆栈，您可能认为下一步是直接跳转到这些工具并启动"执行"DevOps。但是，DevOps 无法启动与工具，或甚至自动进行任何操作。DevOps 的基础，正在清楚地了解的流程和策略用于定义您的应用程序和服务移动方式从您的开发人员手中您的客户手。它真的很简单;如此简单，实际上，您可以通过在纸上写下所需的步骤和手动执行每个中肯定定义整个发布管道。
有时，这是开始迁移到有效的 DevOps 的最困难的部分。在团队环境中，尤其是一个尝试速度会加快，移动的年轻的团队的发布管道可能包含大量的演进临时过程的步骤，各个团队成员"只是记住"到执行操作。示例如下：
- 运行生成
- 运行一些测试
- 检查权限的非代码项目位于适当位置
- 从测试用户收集反馈
- 将应用程序包发布到适当的存储
- 将服务代码部署到相应的服务器 （开发、 过渡或生产等）
- 更改从开发到生产环境的 API 密钥
- 推文可用性
- 更新您的网站上的产品页
使用短开发迭代所有这些活动可以轻松地成为因此 enmeshed 没有人意识到不进行任何实际写入的任何位置下的团队的日常例程中，直到，当然，有人在去度假，则获取病假或离开了公司 ！ 更重要的是，如果您的发布过程和策略存在仅在人看来，很难一致地应用这些。它们总是获取交织在一起拥有数百个不相关，但却很重要的其他任务。这是清楚地充满了危险性，尤其是在单个监督功能可在其中灾难性的环境。
通过花些时间很明确地确定所涉及的所有步骤，可定义的进程，则可预测、 可重复和可审核。让所有它清楚每个人都可以访问的位置中还使得备份过程方便地查看和修改，因为所有的相互依赖项是可见的。反过来，这将应用的工具和自动化的基础。否则它就会像是设置以构建小组件，而不必知道它您实际尝试首先生成大量的工业机器运行测试。
让我们是非常清楚地了解这。自动化不在任何发布管道中实际重要 — 每个步骤可以根据需要手动完成。这包括更简单，但需要很长时间的事宜喜欢发送通知电子邮件。但成本缩放，容易出现人为错误，常令人乏味 （并因此有点无聊的形式），并使面临风险的争夺关注您工作的员工使用其所有其他工作的每一步是手动过程。计算机上，另一方面，是非常擅长无休止地重复和毫无意义普通任务，而不获取厌倦或疏忽。它也是若要添加几个更多机如果需求增加，并要时比雇用 （和激发） 合格的人员的需求会下降，使其停止工作要简单得多。
然后，自动化的目的是为了同时降低成本并提高的频率和您的流程的质量，如定义它们，分开工具。即当流程和策略位于的位置，可以然后以增量方式自动执行不同部分，使用工具来强制执行策略，并获取所有内容转换为透明，并且可审核的窗体。作为您这样做，您没有工作的员工能够将精力集中在那些区域的不由计算机，如查看和解释用户反馈，轻松地处理设计遥测图层，请确定最有效形式的测试，并持续改进均已到位的 DevOps 活动的质量。
示例︰ MyDriving 项目
现在看一下如何，所有这就能与 Microsoft 移动 DevOps 堆栈通过查看已工作项目称为 MyDriving 一起 (aka.ms/iotsampleapp)，作者︰ Scott Guthrie 在 Microsoft 生成 2016年引入了。MyDriving 是一个全面的系统，用于收集和处理物联网 (IoT) 数据通过复杂的 Azure 后结束，提供通过 Microsoft Power BI 和移动应用程序使用 Xamarin 编写结果可视化。它类似的 IoT 项目的第一步中创建，并包括完整的源代码、 Azure 资源管理器部署脚本和完整的参考指南电子书。
对于我而言，MyDriving 发布管道是特定的感兴趣。我使用复数此处是因为有四个︰ 一个用于部署到 Azure App Service 的后端代码，每个用于在 iOS、 Android 和 Windows 上的 Xamarin 应用程序。
下面是管道流，包括目前不实现某些活动的概述︰
- 管理 GitHub 存储库中的源代码 (bit.ly/28YFFWg)。
- 运行生成的存储库，包括以下子步骤中使用的代码︰
- 将标记替换为必需的密钥，具体取决于目标环境 （适用于开发人员、 测试、 生产）。
- 还原必要的 NuGet 包和 Xamarin 组件。
- 更新版本名称和数字。
- 运行生成 （使用适用于 iOS 的 MacinCloud 服务）。
- （仅适用于应用程序）创建并签署应用程序包所需的移动平台。
- （未实现）构建任何可用的单元测试项目。
- （未实现）在测试项目中，如果任何测试失败，失败生成运行测试。
- 对于服务代码中︰
- 将成功测试过的生成输出复制到临时服务器。
- 将临时服务器部署到测试服务器，并运行测试。
- 如果成功，请将部署到生产服务器，并重复该测试运行。
- 监视该服务并获取使用 Application Insights 诊断报告。
- 有关在所有平台上的移动应用程序︰
- 将应用程序部署到 Xamarin 测试云并运行失败，则任何用户界面测试失败的生成的 UI 测试。
- 如果生成和 UI 测试都成功，将应用程序包复制到临时服务器。
- 部署该应用程序从临时服务器通过 HockeyApp alpha 测试人员。
- （未实现）在审批者签字认可，将应用程序部署到通过 HockeyApp beta 版测试者。
- （未实现）在额外的审批人签字认可，将应用推送到适当的应用程序存储区。
- 监视应用程序与遥测数据和崩溃报告通过 HockeyApp。
如您所见，这是需要在每个版本中发生的简单列表。但请注意在特别是，它描述应该做什么和标识的某些服务，但不会指定谁实际执行的步骤。这是非常重要，因为有人正在可以始终与列表坐下来并手动执行每个步骤。实际上，这正是发生了什么情况在 MyDriving 的早期阶段 — 我们这样我们可以立即获得测试应用程序到人的手中手动生成未，依此类推。但是，同时与开发团队的编码成果，其他人侧重于以增量方式自动执行其他步骤，直到整个自动化发布管道已建立。
一个类似的故事告诉另一篇文章在本期中，"应用到的软件开发项目的 DevOps"。 请注意，尤其是部分"构建并发布扩展"原理完全什么我谈到此处︰ 它写出在发布过程中的具体步骤的列表。本文的剩余然后说明，在作者的单词，"我们着手实现自动化的生成和发布管道。"
Visual Studio Team Services/Team Foundation Server 的重要的角色
在 MyDriving 项目中，Visual Studio 团队服务 （简称为团队服务） 是用于管理和自动化发布管道以及与各种服务的交互的中心 (请参阅 图 3)。由于 MyDriving 被创建为开放源代码项目从一开始，使用云托管的服务，如团队服务并不成问题。有关其他方案，组织可能不熟悉，或允许使用的云，在其中用例 Team Foundation Server (TFS) 提供了与在本地服务器相同的功能。在我系列中，我将主要在 Team Services 上下文中工作，但了解，所有内容也适用于 TFS。
.png "MyDriving 的的 Visual Studio 团队服务仪表板")
图 3 Visual Studio 团队为 MyDriving Services 仪表板
这里列出了这些核心功能 (请参阅 图 4 团队服务用户界面中放置虚拟机):
- 源代码管理︰ 承载不受限制的私有和公共源代码存储库使用 Git 或 Team Foundation 版本控制 (TFVC)，或者轻松地与存储库 GitHub 上。
- 敏捷规划︰ 跟踪工作项、 用户情景等使用报表等的看板上的协作。（请注意再次规划方面没有涉及本系列中。）
- 生成︰ 使用各种可用的任务，包括生成和运行 （对于持续集成） 的测试项目并部署到 Xamarin 测试云 (XTC) 创建的服务代码和移动应用程序 (iOS、 Android 和 Windows) 的生成定义。
- 版本管理： 定义可选手动批准使用的任意序列之间发生的任何任务生成和发布到"环境"，如部署到 HockeyApp、 Azure 或应用商店。发布管理居中显示在任何环境上你想要定义，如临时、 alpha、 beta 和生产。
.png "Visual Studio Team Services 中的功能的位置")
图 4 Visual Studio Team Services 中的功能的位置
其中涉及 Team Services 管道末尾是此时应用程序发送到其已分配的最终环境的点 (请参阅 图 5)。此后，DevOps 是主要关心的主动监视这些环境中的应用程序。这其中 HockeyApp 和 Application Insights 进入播放，以及任何其他机制在建立用于获取附加的用户反馈 (也显示在 图 5)。
.png "完成 MyDriving 项目中，代码存储库是在 GitHub 的开发运营流程")
图 5 完成 MyDriving 项目中，代码存储库是在 GitHub 的 DevOps 流
预先准备
在本文开头我说过的各种活动和做法称为 DevOps 是什么桥接编写代码和为以最低的成本为您的企业客户提供价值之间的差距。你现在可以看到，移动开发运营的 Microsoft 堆栈提供了所有需要管理质量、 通过自动化而降低成本、 获取应用程序和手中的客户、 监视现行的运行状况和操作的服务和收集用户反馈的所有恢复到后续版本的积压工作的源。这是 DevOps 周期 — 从代码提交到缓冲区 —，我将探讨更详细地在未来几个月中。
Kraig Brockschmidt 担任 Microsoft 的资深内容开发人员和侧重于 DevOps 的移动应用程序。 他是 Microsoft Press 出版的《Programming Windows Store Apps with HTML, CSS and JavaScript》（两个版本）和 kraigbrockschmidt.com 上的博客的作者。
衷心感谢以下技术专家参与本文的审阅： Donovan Brown，Jonathan Carter、 Glenn Gailey 和 Karl Krukow