Skip to content

Latest commit

 

History

History
340 lines (184 loc) · 18.8 KB

03.md

File metadata and controls

340 lines (184 loc) · 18.8 KB
Raw

三、在 VSTS 中创建持续集成管道

构建伟大的应用不是一项简单的任务。 相反，这是一项困难而复杂的工作，许多参与者需要有效地一起工作，以创建符合高端用户期望的应用。

今天，一切都进展得非常快，上市时间对成功非常重要。 本章将介绍帮助您优化开发过程的方法、过程和工具，从而以较短的发布周期构建高质量的软件。

传统上，构建软件是通过从头到尾规划整个软件项目，编写详细的规格说明，开发和测试(通常是匆忙的)，同时希望一切都按照预期工作(v 模型)来完成的。

这种方法有时有效，有时无效。 当它不起作用时，开发人员在只进行手动测试的同时实现特性，其目标是稍后添加单元测试。 然后，在项目结束时，他们必须加快速度以确保按时交付，但往往没有时间。

这将导致具有重大技术、功能和质量缺陷的项目，大量的 bug 和巨大的维护工作将导致较长的发布周期。 在最坏的情况下，最终用户将不喜欢交付的特性，因此最终产品可能被认为是一个彻底的失败。

有一种更好的做事方式，人们已经讨论了一段时间了，你肯定已经听说过敏捷方法论了!

敏捷方法,结合持续集成(CI)和持续部署**(**CD),为建设更好的软件解决方案提供一个快速上市时间,降低维护成本,更好的整体质量,和更高的客户满意度。

虽然这本书并不是关于敏捷方法论本身，但我们建议您熟悉这个主题，并且我们将解释所有伴随和围绕它的工具和过程。

在本章中，我们将涵盖以下主题:

  • 持续集成、持续部署以及构建和发布管道
  • 使用Visual Studio Team Services(VSTS)进行持续集成和持续部署
  • 创建免费的 VSTS 订阅和您的第一个 VSTS 项目
  • 通过工作项组织工作
  • 使用 Git 作为版本控制系统
  • 创建 VSTS 构建管道
  • 创建 VSTS 发布管道

持续集成、持续部署以及构建和发布管道

当使用持续集成时，开发团队编写代码，在代码审查之后，将其集成到版本控制系统中，并在那里自动构建和测试。 这种情况通常一天发生多次。 因此，开发团队可以快速检测问题和错误，并尽早修复它们，从而实现通常称为Fail Fast的功能。

持续部署是持续集成的自然扩展，因为它确保了构建和测试后的每个应用修改都是可发布的。 它由自动升级开发、测试、登台和生产系统组成。

管道定义了一个完整的开发和发布工作流。 它包含了概念、开发、质量保证和测试所需的所有步骤，直到最终产品的交付。 它包括持续集成和持续部署流程，用于以工业化的方式构建高质量的应用。

Note that you can separate your development process into two different pipelines, a build and a release pipeline, or have only one single pipeline that does it all, depending on your specific needs.

有各种各样的技术和工具可以帮助您实现基于持续集成和持续部署的高效、高效、全自动和工业化的软件开发过程。 在下面的示例中，我们将使用 Visual Studio Team Services。

使用 VSTS 进行持续集成和持续部署

如果你需要相互协作和共享代码,规划和管理您的用户故事和开发任务,跟踪进度的特性和缺陷,所有在敏捷环境中,然后 VSTS 是一个解决方案你可以找到在云中,甚至可能是最好的。

它支持许多不同的编程语言(c#、Java、JavaScript 等等)和各种开发工具(Visual Studio、Eclipse 等等)，并且可以扩展到任何团队规模。

此外，在一个私人团队项目中，最多 5 个用户可以免费使用它，这对尝试本书中展示的示例非常有帮助。

VSTS 提供以下主要功能:

  • 工作项目和看板:计划和分配工作和任务
  • 源代码管理:在版本控制系统中共享代码
  • 测试:创建并执行包含测试用例的测试计划
  • Package store:将自己的 NuGet Package 放入 store
  • 构建管道:构建用于创建应用包的代码
  • 发布管道:将应用包部署到不同的发布目标

For further information on VSTS and all of its features, please go to https://www.visualstudio.com/team-services/features.

创建免费的 VSTS 订阅和您的第一个 VSTS 项目

我们现在将解释如何创建您自己的免费 VSTS 订阅和您的第一个项目。 你将在后面使用它来尝试和理解这本书中的例子:

  1. 转到https://www.visualstudio.com/team-services，点击 Get Started 免费按钮:

  1. 用你的工作、学校或个人微软账户登录:

  1. 如果你是第一次连接，输入额外的信息，如你的姓名，你的国家，和你的电子邮件地址，然后点击继续:

  1. 现在您的帐户已经创建，让我们创建一个新项目。 在我们的例子中，选择 Git 作为版本控制，点击 Change Details，然后选择 Work item process-Scrum:

  1. 新项目生成了，现在可以创建第一个工作项和 Git 存储库了，如本书后面所示。

通过工作项组织工作

工作项用于计划、分配、跟踪，更一般地说，在软件开发项目期间组织您的工作。 它们有助于更好地理解需要做什么，并对项目的状态提供见解。

一些常见的工作项用法是:

  • 为应用特性创建、划分优先级并跟踪用户描述
  • 创建和跟踪实现用户描述所需的开发任务
  • 创建、划分优先级并跟踪应用错误
  • 确定应用质量和发布日期
  • 在一个看板板中显示用户故事、任务和 bug 的进展

如前所述，您可以在 VSTS 项目创建期间选择工作项流程。 这个选择定义了可用的标准工作项类型(WITs)。

默认情况下，有超过 14 个 WITs，您可以为高级场景创建自己的自定义 WITs。 大多数时候，您不需要创建自己的自定义 WITs。

可能的工作项过程选择有:

  • Scrum，如果你的团队使用 Scrum 方法，并且你想在看板板上跟踪你的产品待办事项列表(PBI)
  • 敏捷，如果你的团队在实践一种敏捷方法，但不想遵守特定的 Scrum 约束和术语
  • 如果您的团队遵循更正式的开发任务，那么您可以跟踪请求、更改、风险和评审

下面是一个取决于工作项流程的 WITs 列表:

| 领域 | Scrum | 敏捷 | cmmi | | 产品规划 | PBI 错误 | 用户故事错误 | 要求改变错误 | | 投资组合 | 史诗功能 | 史诗功能 | 史诗功能 | | 任务和冲刺计划 | 任务 | 任务 | 任务 | | 缺陷积压管理 | 错误 | 错误 | 错误 | | 问题与风险管理 | 障碍 | 问题 | 问题风险审查 |

在我们的例子中，我们选择了 Scrum 流程。 产品所有者创建主题、特性和产品待办事项列表项(相当于用户描述)。 在 sprint 计划开发期间，任务被定义并与产品待办事项列表项相关联。 通过云中的看板板，整个团队都可以看到所有内容:

测试人员通过使用 VSTS web 门户或 Microsoft test Manager 来创建和执行测试用例。 他们创建并分配 bug 和代码缺陷，并且可以跟踪阻塞问题:

VSTS 允许您分层地组织您的工作。 您可以向上钻取、向下钻取、重新排序和修改父项，以及在层次视图中使用过滤器。

For even more information, go to https://www.visualstudio.com/en-us/docs/work/backlogs/create-your-backlog.

让我们更详细地看看不同的元素。 史诗可以被描述为具有大量工作的大型用户故事。 它必须被分解成特性和更小的产品待办事项列表项，以便能够完全理解它的需求，然后在多个 sprint 中高效地实现它:

特性将史诗分解成更小的可理解的部分。 它们由一组产品待办事项列表组成，这些待办事项列表对应于详细的预期功能:

产品待办事项列表项是一个具有商业价值的工作单元，它足够小，可以在一次 sprint 中完成。 如果你不能在一个 sprint 内完成它，那么它就必须被认为是一个特性，必须进一步分解:

任务描述了在 sprint 期间实现预期的产品待办事项项功能所需的开发工作。 它们链接到产品待办事项列表项，以实现可跟踪性，并能够自动计算项目进展。

bug 包含已经提出的问题，需要在 sprint 中解决。 它们链接到相应的产品待办事项列表:

在定义了史诗、特性和产品待办事项列表项之后，您可以进行 sprint 计划，并决定在哪个迭代中需要做什么。 此外，看板板为更好地理解提供了一个很好的视觉表达:

每个团队成员的工作能力可以被定义为每个 sprint，一个工作细节报告可以让你实时跟踪他们的工作成就:

此外，每个工作项都有一个随时间变化的状态。 该状态允许您跟踪工作成就并过滤工作项，以便更好地理解和检测问题。

下图显示了依赖于工作项过程的各种默认工作项状态:

| | Scrum | 敏捷 | cmmi | | 工作项状态 | 新批准承诺完成删除 | 新活跃的解决关闭删除 | 提出了活跃的解决关闭 |

您可以查询工作项，创建图表，并将它们发布到 VSTS 项目主页。 如果您需要检索特定的工作项或需要获得项目的整体视图，这是一个非常有用的特性:

使用 Git 作为版本控制系统

Git 在过去几年中取得了相当大的成功。 它已经成为开发人员社区首选的分布式版本控制系统。

VSTS 和 Git 之间有一个很好的集成，并且你可以使用一些强大的、高效的特性(https://www.visualstudio.com/en-us/docs/work/backlogs/connect-work-items-to-git-dev-ops):

  • Git 分支可以在待办事项列表或看板板中创建
  • 可以直接从 VSTS 网站轻松地为多个工作项创建 Git 特性分支
  • 拉请求和提交会自动链接到相应的工作项
  • Build Summary 页面将链接到提交的工作项显示为相关联的工作项

让我们看看如何创建一个新的 Git 仓库，本地克隆，在 Visual Studio 2017 中使用，然后创建你的第一个提交:

  1. 在您的 VSTS 项目中，单击顶部菜单中的代码，然后单击在 Visual Studio 中的克隆按钮:

  1. 将显示一个新的窗口; 选择 Microsoft Visual Studio Web 协议处理程序选择器:

  1. Visual Studio 2017 自动启动，您可以使用您的工作、学校或个人微软帐户进行认证:

  1. 选择本地 Git 存储库的目标文件夹，然后点击 Clone 按钮开始下载:

  1. 进入团队资源管理器-主页，点击设置:

  1. 在 Team Explorer - Settings 中，点击 Repository Settings:

  1. 在忽略&属性文件部分，为每个文件点击添加:

  1. 返回 Team Explorer - Home，这次单击 Changes，为第一次提交输入注释，然后单击 commit staging 按钮:

  1. 你的第一个提交已经在本地创建; 点击 Sync 链接将其推送到服务器:

  1. 进入 VSTS 网站，点击上方菜单中的 Code; 你可以看到你创建的文件已经上传:

就是这样! 您已经创建并初始化了 Git 存储库。 就这么简单! 从这里开始，你有多条路可以走。 例如，将所有内容都放在同一个分支中并不是一个好主意，特别是当您必须维护应用的多个版本时。

You can get some guidance for different branching strategies from https://www.visualstudio.com/en-us/articles/git-branching-guidance.

使用特性分支

特性分支背后的哲学是，每次开始处理一个新的 VSTS 特性(甚至是 VSTS 产品待办事项列表项)时，您必须做的第一件事就是创建一个新的，所谓的特性分支。

然后，您在这个分支中完全独立地工作，直到您准备好将经过测试和验证的修改推到主分支(或者在更复杂的环境中，推到开发分支)。 在推出之前，它不会干扰你的其他功能，也不会导致 bug 或降低整体质量。

如果一个项目的最后期限临近，而你没有及时完成所有计划的功能，你就不需要再紧张了! 为什么? 因为您只能集成准备发布的特性。 您将拥有一个功能较少的产品，但您可以确信这些功能将会像预期的那样工作，没有任何风险。

让我们看看如何使用 Visual Studio 2017 和 Git 创建一个特性分支:

  1. 打开 Visual Studio 2017，进入 Team Explorer 选项卡，点击 Branches 按钮:

  1. 在 Team Explorer - Branches 中，点击 New Branch 链接:

  1. 输入一个新的特性分支名称(使用FEA-前缀)，然后单击 Create branch 按钮:

合并更改和解决冲突

有时，团队成员在同一时间处理相同的文件，从而导致冲突。 让我们看看在这种情况下如何合并更改和解决冲突:

  1. 创建一个名为HelloWorld.txt的文本文件，并将其添加到本地存储库中。 将文件推到服务器，并在服务器上和本地存储库中更新该文件。
  2. 如果你试图推送已经在本地和远程存储库中修改过的HelloWorld.txt文件，你会得到一条错误消息，并且推送失败:

  1. 当查看输出窗口时，你会得到额外的信息:

  1. 单击 Pull 链接，您将获得远程更改，这将导致本地副本和远程副本之间的冲突。 单击“解决冲突”或“冲突”链接:

  1. 您将看到一个冲突文件列表。 点击你想解决的冲突，然后点击合并按钮:

  1. 您将看到冲突的修改。 选择你想保留的(左边的，右边的，或者两者都保留)，然后点击 Accept Merge 按钮:

  1. 回到 Team Explorer，点击 Commit Merge 按钮:

  1. 输入一条注释，然后单击 Commit staging 按钮，在本地完成并提交合并:

  1. 在本地创建提交后，单击 Sync 链接，然后单击 Push 链接:

  1. 现在你应该看到修改已经被上传到远程存储库:

创建 VSTS 构建管道

在计划和组织好你的工作并创建了 Git 仓库之后，你现在应该配置一个 VSTS 构建管道，这将允许你对你的应用进行持续集成:

  1. 打开 Visual Studio 2017，进入 Team Explorer 选项卡，然后单击 build 按钮:

  1. 接下来，点击 New Build Definition 链接:

  1. 打开 VSTS 网站，你会看到一个构建定义模板的选择，选择 ASP.NET Core 模板:

  1. 在新的构建定义中，输入名称并选择默认代理队列。 我们推荐使用 Hosted VS2017:

  1. 要选择源存储库，请单击 Get sources。 在我们的例子中，我们使用默认值(这个项目，Branch: master, Clean: false):

  1. 要启用持续集成，请单击“构建定义”菜单中的“触发器”，然后单击“启用此触发器”按钮:

  1. 在确认已经选择了 Git 存储库和主分支后，正确地单击 Save 或 Save & queue 按钮。 配置已经完成，每次代码提交到存储库时都会自动触发构建:

创建 VSTS 发布管道

您的应用不断地被集成，并且您已经看到了一些巨大的好处，例如可以更快地检测和修复错误和问题。 我们不要止步于此; 进一步改进开发过程比你想象的要容易得多!

现在我们来看看如何通过创建一个 VSTS 发布管道来采用应用的持续部署:

  1. 打开 VSTS 网站，点击上方菜单中的 Build & Release，点击 Releases，然后点击 New definition 按钮，选择 Empty definition 模板:

  1. 你现在可以选择 Project 和 Source (Build 定义)并启用连续部署，然后点击 Create 按钮:

  1. 发布定义被创建，你可以在列表中看到它:

所示的示例版本定义目前并没有做太多工作。 稍后我们将在相应的 Azure 章节中看到部署到 Azure 的更高级的版本。

总结

在本章中，您已经学习了持续集成、持续部署、构建和发布管道、它们的好处以及如何使用 VSTS 实现它们。

您已经创建了一个新的 VSTS 订阅并初始化了一个新项目。 然后我们探讨了一些基本概念，例如用于源代码控制的工作项和 Git。 最后，我们通过一个实际示例说明了如何配置 VSTS 构建管道和 VSTS 发布管道。

在接下来的两章中，我们将解释 ASP 的基本概念.NET Core 2.0 包括 Startup 类，使用中间件、路由、错误处理等。