2016 年 9 月
第 31 卷，第 9 期
此文章由机器翻译。
移动 DevOps - 真相的来源： DevOps 中存储库的作用
通过 Kraig Brockschmidt |2016 年 9 月
此系列中，第一篇文章"从客户的代码︰ 探索移动 DevOps"(msdn.com/magazine/mt767694) 引入 Microsoft DevOps 堆栈以便移动应用程序和后端服务。概述中所示的整个发布管道的阶段 图 1。发布管道，将用于简单地，是如何将提交到源代码存储库的代码将获取转换为客户可以使用的应用程序和服务，并接着传送到客户设备和客户可访问的服务器。发布管道，就其核心而言，只是一个将使发生这种情况的版本所需的步骤。实际上，DevOps 实践开头，要清楚地了解具体步骤而定的版本中所涉及的过程。从这里是相对比较容易以增量方式自动执行这些过程使用 Microsoft DevOps 堆栈内的工具。
.png "源代码控制存储库是对发布管道的输入")
图 1 源代码控制存储库是对发布管道的输入
如在第一篇文章中所述，应始终了解如何执行手动操作的发布管道中的每个步骤。许多应用程序项目入门手动流程，如手动生成，若要尽可能获得尽早测试人员的反馈。在自动化的发布管道的某些部分将分解的情况下，让我们了解如何手动执行一切操作还会提供回退。
但是，手动过程非常昂贵缩放，容易出现人为错误，通常单调乏味并使面临风险的争夺关注您的员工使用其所有其他工作的每个步骤。自动化 — 具有一台计算机执行这些任务 — 提供了更好缩放、 可靠性、 可预测性和审核，这意味着较低的成本更高的质量。自动化还释放您的员工的真正执行需要人工关注的任务。
在这篇文章中，我将探讨的发布管道，但可能已有人理所当然的其中一个非常重要的方面︰ 源代码管理。项目的源代码中所述是发布管道中，输入 图 1, ，和大多数开发人员现在不用说作为源控制系统中接受管理的代码。但它可帮助您更好地理解 DevOps 整个，如果您可以清楚地看到在该上下文中扮演重要的角色源代码管理。
源代码管理的原因
自动化发布管道的第一步是管理某种类型的源代码控制存储库中的代码。同样，源代码发布管道的输入下, 一阶段，生成，是什么将该代码转换为然后送入管道的其余部分的项目。若要特别是自动生成过程中的，使用持续集成，类似于 Visual Studio 团队服务 （简称为团队服务） 的系统必须能够检测到该存储库进行更改时。在这种情况下，不满足需求来管理您的源代码只是在硬盘上的某个任意文件夹中。
注意： 如果还没有可用的团队服务帐户，创建一个由下面的提示进行 bit.ly/29xK3Oo。仍然使用效果更佳，请查看 Visual Studio 开发人员 Essentials 程序 (bit.ly/29xKCYq)，它为您提供团队服务帐户以及容易获取许多其他服务，12 个月 Azure 信用额度中包括 25 美元。
我将讨论如何生成和系列的下一篇文章中的连续集成。这里我要重点放在源控件本身，特别是启动简要回顾一下的源代码管理的初衷，存在的原因，其常规角色中作为一个整体的 DevOps 功能。我这样做的原因是指出了一些您可能永远不会想到有关之前︰ 源控件基本上是一种自动化。
此语句会让您大吃一惊，因为大多数开发人员立即考虑源代码管理给定。但并非总是如此。很可能您曾参与过项目，无需在某一时刻的源代码管理您的职业生涯，尤其是当您第一次已开始。在这些项目中，您可能只是本地硬盘上包含所有代码，这是在 Visual Studio 中创建一个新的本地应用程序项目时获得的内容有一个文件夹。从这里，您可以运行本地生成以生成可执行文件和满足所需的分配，然后手动上载到公共 Web 服务器或可能与其他人共享的物理介质。
简单地说，源代码管理是在没有生成的客户可以使用的应用程序和其后端服务所需的方法。但只有您代码的源代码的单个本地副本具有大量问题和风险，我假设您已经有直接过的所有这些︰
- 如果您的硬盘出现故障，可能会丢失所有内容。
- 对源代码的单个副本不会保留任何更改历史记录，使其很难恢复到以前的工作状态的项目。
- 有关代码的多个人员可以轻松地覆盖彼此的更改，或引入的重大更改，而无需任何人都知道。
就肯定可以手动在某种程度上缓解这些风险。定期备份，例如，帮助防止代码丢失并提供一定程度的历史记录。但是，整个项目的备份的 nongranular 特性使很难在使其他更改保持不变的同时还原项目部分。还有可能让人团队有机会创建个人多份代码以避免冲突，但然后将这些副本一起集成到工作状态非常单调乏味。团队成员还可以进行通信的重大更改其他人通过直接电子邮件或其他消息，但该名称将成为非常繁重，若要在以一致的方式上执行操作。
当然，作为开发人员我们通常避免这种负担通常我们不能。相反，我们发现创造性的方法来自动执行这些任务，这是完全源代码管理的各个方面。
在高级别中，源代码管理意味着︰
- 与某些类型的自动备份机制时，维护的服务器上的所有项目代码的共享存储库。
- 每个文件为基础，以便您可以看到对于任何给定文件的整个历史记录的日志记录更改，以及对已提交到存储库中作为一个组的多个文件的更改。这使得很容易地将关联生成失败，并测试了特定更改的回归测试，以及若要还原单个文件或文件复制到任何以前的状态，而不仅仅是最后一次备份的状态的组。
- 将代码存储在其中生成系统可以检测到存储库的更改并自动触发的生成，这意味着执行与这些更改的即时集成测试 （持续集成） 的位置。
- 管理将覆盖，并通过要求开发人员锁定文件以供独占访问，尽管它们在处理它们，或在工具，可自动将更改合并并将检测冲突在多个用户间发生冲突。
- 当某些文件更改，或者当合并冲突需要手动解决方法，请将自动生成通知发送到感兴趣的开发人员。
简单地说，源代码管理自动执行许多涉及维护可靠，并且可审核的存储库中的项目的代码的繁琐过程。它是所必需的管理项目代码的单独的开发人员和团队相同的并是自动化的发布管道的基础。
源代码管理选项
给出源代码管理的普遍使用需要，则并不奇怪，多年来形成许多不同的系统。在这里，不过，我将讨论您可以直接在工作组服务内托管两个︰ Git 和 Team Foundation 版本控制 (TFVC)。托管存储库是指已直接存储和管理 Team Services 帐户中。Team Services 生成系统还可以从外部 Git、 GitHub 和 Subversion 存储库，同样，我将讨论在下一篇文章中的系列中绘制。
为项目选择的源控制系统实际上是一种首选项，开发团队和成本考虑事项的体验。GitHub，例如，对于公共存储库中，是免费的但具有私有进程的开销 (请参阅 github.com/pricing)。公共 GitHub 存储库是向每个人默认情况下，这就是原因打开开放源代码项目通常托管在 GitHub 上。许多我对在 Microsoft 工作，例如，文档集存储在该处，包括 Microsoft Azure 文档全集 (github.com/Azure/azure-content)，和 Visual Studio tools for Apache Cordova 文档 (github.com/Microsoft/cordova-docs)。我还使用各个示例项目，如以下示例所 Altostratus 的各项的 GitHub (github.com/kraigb/Altostratus)，显示在 MSDN 杂志 》 上一年 (bit.ly/29mKHiC)。同样，我为 MyDriving 项目选择 GitHub (github.com/Azure-Samples/MyDriving) 因为它本来就是从一开始的开放源代码。(有关 MyDriving 总体的详细信息，请参阅 aka.ms/iotsampleapp。)
另一方面，团队服务是面向默认情况下，这意味着当您首次创建一个存储库中，只有您才能访问专用存储库 （Git 或 TFVC）。若要让其他人的访问，您必须专门将它们作为添加团队成员 (请参阅 bit.ly/29QDHql)。优点是，您可以托管无限制私有存储库中你的团队 Services 帐户免费为任意多个 MSDN 订户提供所需以及成本仅启动具有多于五个用户没有 MSDN 订阅时。出于这些原因，我使用个人项目的团队服务、 应用程序如我必须在应用商店和我想要与特定的个人共享代码。
Git 和 TFVC 的主要功能区别在于其相应的源代码控制模型。可以在"选择为你的项目的正确版本控制"主题中的文档中找到的完整比较 (bit.ly/29oZKTZ)，但是让我总结。
TFVC 不同，所示 图 2, 、 进行集中，这意味着文件位于单一、 集中、 只读、 只存储库，则管理员负责备份。若要执行使用 TFVC，您通常维护存储库 （称为工作区），您可以运行生成并测试应用程序中的文件的最新版本的本地只读副本。要进行更改，您签出一个或多个文件，这将使您的独占访问权之前会检查这些文件签入 （即，集成到存储库中）。TFVC 然后将所做的更改合并到存储库。如果多个开发人员签出同一文件同时 （这允许的），TFVC 检测到在签入时合并冲突，并通知开发人员，如果需要手动解决方法。
.png "基本的 Team Foundation 版本控制关系")
图 2 基本 Team Foundation 版本控制关系
Git 分布式的意味着虽然主存储库位于主机上，您"克隆"整个存储库 （更改历史记录及其所有）、 进行本地工作，然后再提交到克隆已完成的更改，如中所示 图 3 (另请参阅 git-scm.com 有关 Git 工作流的详细信息)。当准备好与其他任何人的工作集成的更改时，您提交"pull 请求"从您克隆到母版。在此模型中，每个克隆实际上是存储库中的备份。
.png "基本 Git 关系")
图 3 基本 Git 关系
请注意，Git 和 TFVC 使用某些相似的单词，如"签出"来描述完全不同的进程，可以是令人困惑。最好只需对每个单独工作并不希望这两者之间传输的任何知识。
Git pull 请求机制是能够检测到更改可以自动合并和需要手动解决方法时。当然，公共存储库，如 GitHub，不一定要在任何人都和每个人都能够合并拉取请求。通常情况下，只有某些用户将有权合并拉取请求，然后担任看门人一样的作为一个整体存储库的完整性。
例如，看一看在 MyDriving 存储库中的顶部 github.com/Azure-Samples/MyDriving ，您将看到拉取请求 (请参阅 图 4)。单击显示当前打开请求的等待裁决的人使用合并的权限。您还可以通过单击列表中已关闭选项卡上查看 pull 请求的整个历史记录。
.png "请求的请求在 GitHub 上 MyDriving 项目列表")
图 4 拉取请求在 GitHub 上 MyDriving 项目列表
TFVC 和 Git 支持所谓的分支，这实质上意味着创建主数据库或中央存储库和其他克隆或副本之间的另一层。这使得该分支中而不会影响主存储库的开发人员 （和测试人员） 进行大量工作的子组。一个分支还维护其自己的更改历史记录和，对于 Git，管理其自己的 pull 请求中的每个克隆。仅在该团队已准备好集成与主分支中的工作时不要在提交拉取请求到母版。有关详细信息，请参阅"使用分支隔离风险在 TFVC 中的 (bit.ly/29ndlQz) 和"分支中创建的工作"(bit.ly/29VVmgY) 文档中。
通信和审核
Git 和 TFVC 中，并在源控制系统通常 — 签入、 拉取请求等所有具有关联的注释机制。这就是如何进行通信所做的更改对其他从事项目和团队如何可以讨论这些更改的每个人所做。这些系统通常还会提供通知和讨论内容的更广泛的问题 （如打开 bug） 的工作项，依此类推。
在 GitHub 上，例如，你包含批注的每个代码提交到您的克隆，然后将其他注释时提交拉取请求。那些负责检查和合并该请求可以随后按原样意见或问题中拉取请求，尤其是如果找到新代码的潜在问题。单击环绕 MyDriving 储存库中的前面提到的封闭的拉取请求列表中，您可以看到大量示例。同样，若要查看更多讨论的主页上的问题选项卡上单击。至于通知，这些是通过在通知部分中的个人设置进行管理。
团队服务，其部件具有用于跟踪工作项、 bug，依此类推，整个团队服务文档的敏捷工具部分中可阅读相关信息系统 (bit.ly/29tvKIE)。代码存储库中 (是否 Git 或 TFVC)，没有无处不在注释控件，如中所示 图 5, ，它允许团队成员将保留说明在变更集 （组的更改），单个文件，等等。
.png "用于 Visual Studio 团队服务，显示注释按钮中的变更集的用户界面")
图 5 用于 Visual Studio 团队中的变更集的用户界面的服务，显示注释按钮
此类注释，以及有关对哪些文件进行了哪些更改的特定详细信息所有进入该存储库的历史记录，或更改日志。具有大量详细的是谁做了哪些什么时候更改历史记录 — 以及围绕这些更改发生的所有讨论 — 是使用源代码管理系统的最大的好处之一。历史记录使可审核的各时间整个存储库。如果在发布管道，如通过单元、 集成或 UI 测试，揭示的回归更高版本提出的意外的问题很容易回过头来查看导致该回归的特定文件中的特定更改。
在"简单"的过程的确非常重要作为一个整体的 DevOps 负责。还记得我谈到 DevOps 作为应用程序和服务，其中"性能"包括客户体验和生产环境的成本的性能的连续验证本系列中第一篇文章。可发现的缺陷尽早功能发布管道可以帮助以最小化成本。同样重要的是完全查明 where、 所需的时间、 有缺陷，确实存在 — 得愈快越好 ！ 实际上，您可能已花费很多令人沮丧天尝试跟踪中某些项目中，仅用于查找该修补程序花费了 10 秒的所有 bug 的体验。在这种情况下，几乎所有的成本来自于只定位该 bug。
如果您或您的团队中的任何人都对象添加到使用源代码管理，而不是只"在即兴发挥"通过一些简单的网络共享上保持您的代码，这是非常重要的考虑。通过采用源代码管理系统进行的投资的一些项目，尤其是在与自动生成，持续集成结合使用，并自动测试，正如您看到在将来的文章的生命周期支付大受裨益。持续集成意味着每个代码更改触发的自动生成并运行自动的测试，因此，如果该代码更改会导致任何类型的故障 （生成或测试），您了解它在几分钟之内。
团队项目和多个存储库
若要生成您的应用程序和服务团队服务或 Team Foundation Server (TFS) 中的自动化的发布管道，开始时使用所谓的团队项目。团队项目是您执行团队服务，包括规划、 工作项跟踪、 通过团队聊天室协作中生成的所有内容、 持续集成、 测试管理、 发布管理和源代码管理存储库的容器。因为团队项目可以直接承载多个存储库，并且还可以在 Team Services 生成系统绘制从外部 Git、 GitHub 和 Subversion 存储库，我这里说"存储库"。（同样，TFS 可以绘制从存储库承载于 Team Services 以及进行相反转换。）
请注意，在团队项目，不应与 Visual Studio 项目或解决方案; 混淆您可以有任意多个 Visual Studio 解决方案 — 以及从开发的任何其他系统的任何其他代码 — 全部在同一团队项目中。为此，我想为 DevOps 的极具价值框为团队项目的 — 这有助于我避免术语中，之间产生混淆，并让我想起它可以管理的所有 DevOps 精彩内容 ！
若要创建团队项目，登录到的团队服务门户，并在最近的项目和团队下单击新建。新建命令会打开一个对话框，您从中选择 Git 或 TFVC 作为项目的默认存储库的源代码管理模型。这是实际上只是为了方便起见。如果您选择 TFVC 以后，可以创建 Git 存储库，如稍后; 您将看到如果选择 Git，则可以添加更高版本以及更多 Git 存储库的 TFVC 存储库。如果您喜欢使用 GitHub 等外部主机，不会在所有使用默认存储库并选择此选项不起作用。例如时我的团队项目为设置 MyDriving，我为默认存储库中，选择 Git 但存在来说，只, 是默认自述文件，因为实际项目托管完全在 GitHub 上。
若要显示如何使用单个团队项目可以管理多个存储库，我在我自己团队服务帐户和所选的 TFVC 中创建了一个示例项目。此项目的代码选项卡上最初显示如中所示 图 6。单击以大纲方式显示控件在团队项目中，以及新的存储库和管理存储库的命令显示的现有存储库的列表。新建命令会打开一个对话框，再次选择 Git 和 TFVC 之间。因为我最初使用 TFVC 创建团队项目，我不能创建另一个 TFVC 存储库 （仅允许一个，则），但我可以创建任意数量的其他 Git 存储库中所示 图 7。
.png "对于新项目使用 Team Foundation 版本控制的代码选项卡")
图 6 使用 Team Foundation 版本控制为新项目的代码选项卡
.png "具有多个 Git 存储库和一个 Team Foundation 版本控制存储库的团队项目")
图 7 具有多个 Git 存储库和一个 Team Foundation 版本控制存储库的团队项目
管理存储库命令将进入 Team Services 控制面板，您可以看到所有存储库 （和 Git 分支） 在一次;重命名或删除它们。和管理访问权限。围绕用户、 组和权限的详细信息 — 太多，无法在此一一介绍 — 请参阅"权限和团队服务中的组"的文档 (bit.ly/29nxvpd)"Git 存储库"和"TFVC"部分中。简单地说，您可以练习非常精准控制对于您的团队成员每个项的权限。当然，如果您使用外部源代码控制系统，如 GitHub，你将管理该站点上的权限。但是请注意，权限为团队项目作为一个整体 — 并不存储库 — 通过在该 UI 中显示安全选项卡管理。您还可以在前面所述的同一个文档页中找到这些详细信息 (bit.ly/29nxvpd)。
填充具有代码的团队服务存储库
一旦您创建一个存储库中，最要紧的问题是如何为其获取您的代码。团队服务授予各种各样的方法，如做到这一点 Visual Studio 中，若要关闭此文章让我简要运行通过这些选项。
对 TVFC 的存储库，您可以先将文件上载到存储库中或创建新的文件直接通过 Team Services 门户。第一次导航到代码选项卡中的团队项目，然后单击...旁边存储库和选择 + 添加文件，如中所示 图 8。这将打开一个对话框 （未显示） 通过它您可以创建文件和直接在门户中，对其进行编辑或创建要上载的文件列表。在后一种情况下还包括签入注释。
.png "Visual Studio 团队服务命令将文件添加到 Team Foundation 版本控制存储库")
图 8 Visual Studio 团队服务命令将文件添加到 Team Foundation 版本控制存储库
通过 Visual Studio 解决方案资源管理器是另一种将代码添加到 TFVC 存储库。这是非常方便地将本地解决方案并将所有代码都传输到源代码管理。只需右键单击该解决方案并选择将解决方案添加到源代码管理中所示 图 9。此时会弹出一个对话框，在其中您可以选择相应的团队项目，在您的团队服务帐户或在特定的 TFS 计算机上。若要连接到服务器，您可能需要开始，在 Visual Studio 中使用团队资源管理器 (选项卡底部的概述 图 9)。有关详细信息，请参阅 Visual Studio 文档中的"工作在团队资源管理器"主题 (bit.ly/29oGp5j)。
.png "将解决方案添加到 Visual Studio 中的源代码管理")
图 9 将解决方案添加到 Visual Studio 中的源代码管理
Git 存储库 Team Services 将自动提示您提供的各种选项创建存储库或导航到代码选项卡，不言而喻充分的 UI 时。或者，您可以在 Visual Studio 中创建本地 Git 存储库，然后将其发布到 Team Services 中的存储库。我不会经历这一过程进行详细介绍，因为它可以很好地记录下来主题中的"共享您的代码使用 Git 和 Visual Studio"(bit.ly/29VDYJg)。简短的描述，不过，请单击右下角将显示团队资源管理器发布选项卡中所示的 Visual Studio 状态栏发布按钮是 图 10。在此处可以选择要使用的团队服务帐户。一个重要细节，点击要选择团队项目所示的小型高级文本。如您所见，同一个用户界面为您提供要发布到 GitHub 和其他外部存储库，以及代码的简便途径。
.png "发布 Visual Studio 中的用户界面")
图 10 在 Visual Studio 中发布用户界面
预先准备
与源代码控制存储库中的位置，您现在准备好进行自动执行通过设置发布管道生成和持续集成的下一步。这就是我将介绍在下一篇文章中，您将看到如何在 Visual Studio Team Services 内任何给定的生成定义可以绘制从任何我此处讨论的源代码控制存储库中。此外，团队项目时，可以管理任意数量的此类的生成定义，这意味着可以协调团队项目生成从任意数量的存储库来生成剩下的发布管道或管道，必要的项目，具体情况而定。
Kraig Brockschmidt 担任 Microsoft 的资深内容开发人员和侧重于 DevOps 的移动应用程序。 他是 Microsoft Press 出版的《Programming Windows Store Apps with HTML, CSS and JavaScript》（两个版本）和 kraigbrockschmidt.com 上的博客的作者。
衷心感谢以下技术专家对本文的审阅： Donovan Brown 和 Gordon Hogenson