七、持续集成和持续部署

大多数项目都是团队努力的结果。 团队可以位于不同的地方，也可以位于相同的地方，来自不同位置的成员必须以同步模式工作，这样他们的更改就不会与其他团队成员发生冲突。 一个系统只有在各种场景中使用时才会成熟; 这些场景可以基于领域专家的经验，也可以来自生产环境。 即使系统被认为是一个完美的系统，系统也有可能在生产环境中崩溃。 对于 web 应用来说，由于性能故障、糟糕的用户体验等原因，这些条件更加关键。 一个系统应该经历这样一个过程:如果团队成员进行了更改，那么代码在单元测试之后被集成，然后构建被部署到相关的环境中。

当我们说到部署时，我们立即想到 Xcopy 部署。 在这种类型的部署中，您只需构建和复制相关文件，并将其部署/粘贴到相关环境中。

在这一章,我们将讨论的基本部署和新兴实践的影响,如持续集成(CI)和持续部署(【T6 CD】)。 我们将重点关注以下议题:

  • Azure 环境
  • 出版社/托管
  • 在线使用 TFS 的 CI 和 CD
  • CI 和 CD 之间的区别

简介—部署术语

在进一步讨论之前，我们应该首先讨论为什么要讨论部署。 部署周期具有特定的流程，我们应该理解部署术语。 部署术语简单地包括从代码更改到发布的步骤。 在本节中，我们将讨论所有这些部署步骤。

构建阶段

在构建阶段，随着所有相应单元测试的通过，服务源在没有任何错误的情况下被编译。 这个阶段生成构建工件。

持续集成

每次开发人员提交任何更改时，CI 强制重新构建整个应用——应用代码将被编译，并针对它运行一组全面的自动化测试。 这种实践产生于大型团队中频繁集成代码的问题。 其基本思想是保持增量或对软件的更改较小。 这为软件处于可操作状态提供了信心。 即使开发人员的签入破坏了系统，使用这个过程也很容易修复它。

部署

硬件供应、安装基本操作系统和. net 框架的正确版本是部署的先决条件。 下一部分是通过各个阶段将这些构建工件推进到生产环境中。 这两个部分的组合称为部署阶段。 在大多数应用中，部署和发布阶段之间没有区别。

持续部署

在 CD 中，每个成功的构建都被部署到一个首选环境中，例如生产环境。 环境因组织而异。 因此，CD 并不适用于生产环境，但您也可以将其用于其他环境，如开发、登台等。 从技术团队的角度来看，CD 更重要。 在 CD 之下，还有一些其他的实践，例如自动化单元测试、标记、构建号的版本控制，以及变更的可追溯性。 通过持续交付，技术团队确保通过各种较低环境推动到生产中的变更在生产中按预期工作。 通常，它们很小，部署得很快。

持续交付

持续交付与 CD 不同，CD 是从技术团队的角度出发的，而持续交付更关注于尽早向客户提供已部署的代码。 为了确保客户得到正确的无缺陷产品，在连续交付中，每个构建都必须通过所有的质量保证检查。 一旦产品通过了令人满意的质量验证，何时发布就由业务涉众决定了。

构建和部署管道

构建和部署管道是通过自动化实现持续交付的一部分。 它是一个步骤工作流，代码通过这些步骤提交到源存储库中。 在部署管道的另一端，生成用于发布的构件。 构建和部署管道的一些步骤如下:

  • 单元测试
  • 集成测试
  • 代码覆盖和静态分析
  • 回归测试
  • 部署到临时环境
  • 负载/压力测试
  • 部署到发布存储库

释放

最终用户可用的业务特性被称为特性的发布版本。 要发布一个特性或服务，应该事先部署相关的构建构件。 通常，功能开关管理一个功能的发布。 如果特性标志(也称为特性切换)在生产环境中没有被打开，它被称为指定特性的暗版本。

成功的 RESTful 服务部署的先决条件

任何系统部署的成功都取决于团队所遵循的体系结构风格和实践。 采用以下实践，我们的 RESTful 服务获得成功的机会更大:

  • 自给自足的团队:作为 SOA 和微服务架构的先驱，Amazon 遵循了两个披萨团队的范例。 这意味着一个微服务团队的成员通常不超过 7 - 10 人。 这些团队成员将拥有所有必要的技能和角色; 例如，开发、运营和业务分析师。 这样的服务团队处理微服务的开发、运营和管理。
  • CI 和 CD:CI 和 CD 是实现基于微服务体系结构风格的系统的 RESTful 服务的先决条件。 小型自给自足的团队，能够经常整合他们的工作，是微服务成功的先行者。 这个建筑不像巨石那么简单。 然而，自动化和定期推动代码升级的能力使团队能够处理复杂性。 诸如Team Foundation Online Services(TFS)、TeamCity 和 Jenkins 等工具是这个领域中非常流行的工具链。
  • 基础设施即代码:用代码表示硬件和基础设施组件(如网络)的想法是新的。 它可以帮助您使部署环境(如集成、测试和生产)看起来完全相同。 这意味着开发人员和测试工程师将能够很容易地在较低的环境中重现产品缺陷。 使用 CFEngine、Chef、Puppet、Ansible 和 Powershell DSC 等工具，您可以将整个基础设施编写为代码。 通过这种范式转换，您还可以将基础设施置于版本控制系统下，并将其作为部署中的工件发布。
  • 云计算的利用:云计算是采用微服务的一大催化剂。 然而，对于微服务部署来说，它并不是强制性的。 云计算具有近乎无限的规模、弹性和快速供应能力。 云是微服务的天然盟友，这一点是显而易见的。 因此，Azure 云的知识和经验将帮助您采用微服务。

Azure 环境

Azure 是微软提供各种云计算服务的服务。 Azure 是一个云平台，可以帮助您在全球范围内构建、部署和管理应用。

在讨论 Azure 环境之前，我们应该先了解云计算。

云计算

简而言之，云计算是一种存储/场所，通过互联网提供各种基于计算机的服务，即存储、数据库、服务器和软件(这里的互联网被称为云)。

There are various terms in existence related to cloud-computing, you can refer to this link for these terms: https://azure.microsoft.com/en-in/overview/cloud-computing-dictionary/.

任何人都可以出售这些服务，提供云计算服务的供应商/公司被称为云提供商。

云计算并不是一个新术语，它已经存在一段时间了，只是现在它变得流行起来。 如果你正在使用任何在线服务来帮助你向他人发送或接收电子邮件，那么这就是云计算。 在云的帮助下，您几乎可以做任何您想做的事情。 这些服务包括:

  • 创建新应用
  • 存储数据
  • 托管、部署应用

还有更多的活动，这取决于你的云提供商提供的服务或你的订阅类型。

云计算的好处

目前，云计算在 IT 资源相关业务的增长中扮演着重要的角色。 如今，每个人的想法都与传统系统不同; 云对所有人都有好处，正如这里所讨论的:

  • Pick and start:如果你有任何类型的云计算订阅，你不需要思考，只要选择你的服务，从任何地方开始。 你只是需要一个互联网开始。
  • 成本:当你使用云计算时，没有必要考虑花钱购买昂贵的硬件或相关基础设施。 你可以得到你需要的硬件，这些都是划算的。
  • 速度:可快速委托新资源; 这些服务的性能非常好。
  • 可用性:云计算最重要的好处是，您不需要考虑服务的可用性，因为它们是全球可用的。 例如，如果您从印度委托了一台虚拟机，那么您不必担心使用这台机器，即使您可能在世界的另一个地方。

要决定适合您的云提供商，请参考https://azure.microsoft.com/en-in/overview/choosing-a-cloud-service-provider/。

云计算服务模型

云计算服务有很多，但最好的云计算服务类型定义如下(其他类型仅基于这些服务类型):

讨论 Azure 环境

Azure 环境提供了一种通过互联网获取各种服务的方法。 以下截图代表了所有云计算服务模型的典型概述:

它展示了 IaaS 是提供服务器和存储的基本模型，SaaS 是提供几乎所有云计算服务的高级模型。

从 Azure

要开始使用 Azure，您需要访问 Azure 门户。 遵循以下步骤:

  1. 使用以下链接登录 Azure 门户:https://portal.azure.com。

如果你没有 Azure 账户，可以在这里免费创建一个:https://azure.microsoft.com/en-in/free/。

  1. 登录后，会看到如下截图所示的仪表盘:

Azure portal dashboard

门户仪表板可能与您在前面的屏幕截图中看到的不同。 如果您是第一次登录，那么您可能需要创建资源(根据您的需求)。 在这里，您可以委托您的虚拟机(参见 IaaS)，选择一个特定的环境，比如 Windows 机器或 Linux(参见 PaaS)，或者部署您的应用(参见 SaaS)。

  1. 现在你可以做任何你想做的按照你的订阅。

出版社/托管

发布/托管是一种使您的应用公开可用的服务。 应用可以存储在托管提供商提供的服务器上。 在本节中，我们将使用 TFS(现在是 VSTS):参见https://www.visualstudio.com/tfs/。

如果现有项目托管在 TFS 上，则需要迁移它。 详见链接:https://www.visualstudio.com/team-services/migrate-tfs-vsts/。

项目托管

您需要访问 Visual Studio Online/TFS Online(现在是 VSTS)来托管一个项目。 为此，你需要遵循以下步骤:

  1. 使用您喜欢的浏览器转到https://www.visualstudio.com/vso/。
  2. 点击 Sign in，如图所示:

VSTS home screen

  1. 输入您的微软帐户; 如果你没有，你可以创建一个。
  2. 按照步骤创建您的帐户。
  3. 你会被重定向到你的 Visual Studio 团队服务帐户页面:

VSTS my profile page

  1. 单击 Create new project。
  2. 您将被重定向到一个新页面，在那里您将被要求提供一些与您的项目相关的信息。
  3. 添加您的项目信息，如下图所示:

Creating a new project

  1. 选择您的版本控制-您将被给予选择 Git 或团队基础版本控制(TFVC)。

如果你对这些选项感到困惑，请参考这个链接来比较 Git 和 TFVC:https://docs.microsoft.com/en-us/vsts/tfvc/comparison-git-tfvc?view=vsts。

在我们的例子中，选择 Team Foundation Version Control:

  1. 现在，选择 Work Item Process，参考https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/choose-process?view=vsts以了解更多可用的各种选项。 在我们的例子中，选择 Scrum:

  1. 现在单击 Create。
  2. 你会被重定向到一个新创建的项目页面，看起来像下面的截图:

FlixOneProductServices project main screen

  1. 项目主屏幕是一个快速显示页面，在这里您可以快速地看到所有的活动。

您的项目已经创建，现在可以开始您的项目了。

仪表板

仪表板是一个包含项目活动快照的屏幕。 它告诉你分配给你的任务，显示一个 sprint burndown 图表，项目进度，或任何你在仪表板上配置的东西:

Dashboard of FlixOneProductServices project

在项目仪表板中，您可以通过添加新的或删除现有的小部件来编辑小部件。 前面的屏幕截图显示了我们项目的默认视图。

代码

下面是您可以管理当前项目的实际代码的屏幕:

Code screen of FlixOneProductServices project

您可以查看以下内容:

  • Files:存储库中的所有文件。
  • 变更集变更集:代码变更带有变更集编号，您还可以获得关于什么变更集针对什么任务/bug 的信息。
  • 搁置集:可用于审查或与当前项目相关的任何其他用途的任何搁置更改。
  • Pull Requests:这是一种协作方式。 你可以在任何时候发起一个 Pull Request，点击 Code 并选择 New Pull Request，项目的所有者或维护者将被告知这个 Pull Request。

工作

默认情况下，它显示 Work Items 屏幕，向您显示分配给您的项目，或者您正在处理或已经处理的任务/bug。 我们已经创建了一个新的项目，所以你会得到一个空白页; 要从工作项开始，您需要创建一些待定项，然后在团队中分配它们。

单击 Backlog，然后从屏幕上出现的新模板中为 Product Backlog 添加一个标题。 见下图:

New product backlog

你可以在前面的截图中看到，默认情况下，你有六个 sprint。 现在，打开一个新创建的产品待办事项列表项，并提供一个完整的描述—详细信息，例如该工作的工作内容、谁将处理该工作项，或者谁将是该工作项的所有者。 请看下面的截图，它显示了一切:

Product backlog item

现在，进入 Sprint 1 并设置日期——你应该设置开始当前迭代的日期，如下面的截图所示:

类似地，您可以添加更多产品待办事项列表项。 不要将项目移动到 Sprint 1。 Backlog 条目屏幕的视图如下图所示:

Board backlog items

向存储库中添加代码

我们没有在存储库中添加任何代码; 现在，是时候这么做了。 要添加代码，你可以点击 code 并直接从 web 界面上传文件，或者从 Visual Studio IDE 进入源代码控制，在添加存储库后签入代码。 在本节中，我们将使用 Visual Studio 添加代码。 要做到这一点，请遵循以下步骤:

  1. 打开 Visual Studio
  2. 创建或打开现有项目
  3. 开放的团队资源管理器
  4. 单击连接 TFS 服务器
  5. 如果找不到服务器，就添加一个 TFS 服务器，然后为它提供一个有效的地址
  6. 点击连接

下面的截图显示了与 FlixOneProductServices 的连接:

Connecting TFS server

  1. 您需要将 TFS 存储库映射到本地驱动器。 映射源代码并获得代码:

Mapping and getting source code

  1. 现在单击“源代码管理资源管理器”，将打开“源代码管理资源管理器”选项卡。 你会看到空的项目节点，如下图所示:

Source Control Explorer

  1. 在“解决方案控制资源管理器”中，右键单击“解决方案”，然后单击“将解决方案添加到源代码控制”。 参考以下截图:

Add solution to Source Control

  1. 做出你的选择并选择它:

Add solution to FlixOneProductServices

  1. 现在你可以看到一个新的文件夹和文件已经被添加到源代码控制中——请看下面的截图:

Newly added project

  1. 转到 Team Explorer 并单击 Pending Changes。 您将发现签出的各种文件。

  2. 添加一个工作项并添加一条注释，然后单击 Check In:

Check In pending changes

  1. 您已经成功地将解决方案添加到源代码控制中。

  2. 现在回到您的 TFS Online 并单击 Code。 您将发现最近添加到源代码控制中的所有代码文件/文件夹。 参考以下截图:

Viewing Code

您已经成功地将项目托管到 VSTS。 在下面的部分中，我们将讨论构建和部署。

测试

VSTS 的这个屏幕帮助您创建各种测试计划，以便您可以跟踪一个 sprint 的手动测试。 它有助于监控当前 sprint 的手动测试何时完成。 我们在第 6 章、测试 rest 式 Web 服务中讨论了测试的各种术语。

在接下来的章节中，我们将看到这如何帮助我们通过创建一个测试计划和测试用例来测试我们的冲刺。

创建测试计划

在“测试计划”选项卡上单击+，然后单击“测试计划”，如下图所示:

Creating a test plan

在下一个屏幕中，命名您的测试计划，确保您为测试计划选择了正确的冲刺。 参考以下截图:

Naming your test plan

由于测试计划是针对手动测试的，我们现在必须添加需要测试的待定项。 在您的案例中，我们只是添加了 Sprint 1 待办事项列表项。 在这样做的过程中，我们为 Sprint 1 的所有待定项添加了测试套件。

创建测试用例

在前面的部分中，我们已经创建了迭代 1 测试计划，并向其添加了一个测试套件。 现在，我们需要创建一个测试用例，点击 New 并选择 New test case:

Creating a new test case

通过添加一个有效的名称来完成您的测试用例，并将具有预期输出的步骤添加到测试用例中。 参考以下截图:

Writing a test case

您现在可以将测试人员分配给这些测试用例或测试套件，以便测试人员可以运行这些测试。

运行手动测试

在前面的部分中，我们已经创建了手动运行的测试用例。 单击测试套件并单击 Run 以运行可用的测试。 参考以下截图:

Running manual tests

这些测试将在浏览器窗口中运行，所以请确保您的浏览器不会阻止弹出窗口，如下截图所示:

Verifying manual test results

由于这些测试是手动的，因此您需要手动测试这些测试。 执行这些测试之后，您必须验证预期的输出，并相应地将测试标记为通过或失败。 测试用例的总体结果将显示在测试套件窗口中。

在这个部分中，您已经创建了一个测试计划，一个针对当前迭代的测试套件，以及用于测试特定迭代、代码更改、构建或发布的手动测试用例。

维基

Wiki 页面帮助团队成员一起工作。 这些页面可以包含项目文档或处理项目的指示，比如编码指南，等等。 最初，通过点击 Create Wiki 按钮，你会得到一个空白模板，如下截图所示:

Creating Wiki

从 Create Wiki 页面模板中，您可以添加任意多的页面。 Wiki 页面支持 markdown:https://docs.microsoft.com/en-us/vsts/collaborate/markdown-guidance?view=vsts。

构建和发布选项卡

Build and Release 选项卡提供了为项目创建构建和发布的工具。 在本节中，我们将讨论使用 VSTS 的 CI 和 CD。 最初，不会有任何构建定义。

CI 和光盘

我们已经在前面的小节中讨论了这两种方法。 在本节中，我们将简要讨论 CI 和 CD 之间的区别。

CI 是所有团队成员(开发人员)集成代码的实践。 这发生在每次签入时，每当开发人员推送更改时，或者在代码配置时，CI 触发。 这样做最重要的好处是，它可以在开发周期中节省时间，因为它可以识别冲突(如果存在冲突的话)。 这从设置汽车测试的初始步骤开始。 一旦有人将更改推送到存储库，就会触发构建和测试。

持续部署解决了在部署到生产环境时代码的部署问题。

在线使用 TFS 的 CI 和 CD

在本节中，我们将讨论项目的持续集成。 转到构建选项卡，然后构建定义，然后点击+新建:

Creating a new definition

在下一步中，系统将要求您选择存储库。 选择 Repository Source Control 并映射分支，然后单击 Continue:

Selecting a repository source

在下一个屏幕中，选择你的模板; 在我们的例子中，选择 ASP.NET Core:

Selecting ASP.NET Core template

按照模板的说明，提供所需的值，如下图所示:

Creating build tasks

以下是与 VSTS 有关的基本但重要的概念; 理解这些也很重要，这样你就可以成功地配置构建步骤:

  • 任务:这些构建步骤指导 VSTS 执行特定的任务
  • 变量:这些构建配置值告诉构建代理关于系统或自定义值
  • 触发器:这些触发器根据您是否启用 CI 来启用各种任务
  • 选项:这些是构建属性，您可以为此提供构建描述、构建作业超时时间等
  • 保留:保留策略可根据需要构建; 典型的策略是您希望将好的或坏的构建保留多久

为了使我们的例子简单，我选择了变更#5 来保存构建定义:

Saving build definition and queue

现在，您可以在 build and Release 选项卡下看到构建结果——您的构建可能没有运行(请重新访问所有步骤); 下面的截图显示了验证的步骤:

Build steps

启动 CD 发布过程

你已经设置好了 CI 流程，现在是时候使用 CD 了。转到 Release 选项卡，点击 New definition 按钮:

Adding release definition

根据您的应用选择一个模板。 参考以下截图:

Selecting Azure App Service Deployment

通过选择您的存储库或构建，将工件添加到发布定义中，请参考以下截图:

Adding an artifact

为您的部署环境、将要使用的 Azure 服务或应用类型设置值，等等。 参考以下截图:

Adding task values

去 Release，你可以看到你的 Release 的状态; 我们只添加了一个版本定义，所以你会看到如下截图:

Release deployment status

我们还没有部署我们的版本，所以它的状态是未部署。 您可以手动触发部署。 这个版本是针对开发环境的——您可以设置任意多的环境。 在本节中，我们看到了如何使用 VSTS 启动 CI 和 CD。

总结

部署术语使团队与其工作保持一致，即使团队工作在不同的地理区域。 在 CI 的帮助下，CD 团队在项目中的任何团队签入后都会立即收到最近的更改，从而保持同步。

在下一章中，我们将讨论日常开发活动中的测试范例。 我们将讨论与测试范例相关的重要术语，包括围绕这些术语的理论，然后我们将讨论具有存根、mock 知识的代码示例，并理解集成和安全性，以及性能测试。

版权属于：月萌API www.moonapi.com，转载请注明出处

本文链接：https://moonapi.com/news/32772.html