概述

在本实验中,您将了解Azure Pipelines提供的用于自动化部署应用程序的发布管理功能。这些功能可帮助开发和运营团队与Team Foundation Server集成,以便更轻松地对自动化构建后的部署进行配置和自动化。开发团队还可以对其发布流程进行建模,并跟踪审批,签署和可视化其发布状态。

先决条件

练习1:使用Azure DevOps实现持续交付

任务1:设置Azure资源

  1. 首先创建本实验所需的Azure资源。这包括一个数据库和两个应用服务:一个用于QA,另一个用于生产。登录https://portal.azure.com登录您的帐户。

  2. 单击创建资源并搜索”sql“。

  3. 选择SQL Database并单击Create

  4. 输入”partsunlimited“作为数据库名称。选择一个订阅(哪个订阅无关紧要,但对本实验中的所有步骤使用相同的订阅)。选择创建新资源组,并输入”partsunlimited“作为名称。确保选择源设置为空白数据库并单击配置所需设置。如果您还没有要使用的服务器,请单击创建新服务器

  5. 输入服务器名称的唯一名称,例如包括您的姓名。输入您可以记住的管理员用户名和密码。请注意,”P2ssw0rd“符合密码要求。单击选择以选择这些选项。请务必勾选允许Azure服务访问服务器

  6. 单击创建。这需要一些时间才能完成,但您可以在后台运行时继续下一步。

  7. 单击创建资源并搜索”web“。

  8. 选择Web App模板,然后单击创建

  9. 对于Name,输入一个唯一的名称,例如使用您的姓名作为部分。由于这将用于我们的QA部署,请将名称附加”-qa“。一定要选择“ASP.NET 4.7”运行时堆栈并像以前一样选择相同的订阅资源组。如果需要创建应用服务计划,请接受默认值。单击查看并创建以创建。

  10. 重复上述过程,为生产阶段创建第二个应用服务。这一次,用”-prod“代替它。

  11. 可能需要几分钟才能使所有新的Azure资源可用,因此请继续执行下一个任务。保持此浏览器选项卡打开以供日后使

任务2:创建QA阶段的连续发布

  1. 在新的浏览器选项卡中导航到Azure DevOps上的团队项目。它应该在https://dev.azure.com/YOURACCOUNT/Parts%20Unlimited

  2. 导航到Pipelines | Releases

  3. 删除现有的PartsUnlimitedE2E发布管道。我们将在这里重新开始。

  4. New下拉列表中,选择创建发布管道以创建新的发布管道。

  5. 有许多起始模板可供选择,或者您甚至可以从空的流程模板开始。在这种情况下,请选择Azure App Service Deployment并单击Apply

  6. 将默认阶段重命名为”QA“。此模板将部署到QA,然后部署到生产阶段。我们先设置这个。

  7. 将发布管道重命名为”PUL-CICD“。

  8. 要定义的第一件事就是应该部署的内容。单击Artifacts部分中的Add以指定要部署的工件。

  9. 有很多类型的工件,但这个工件非常简单:从这个团队项目中已经存在的PartsUnlimitedE2E构建管道构建的项目。单击添加

  10. 现在已经定义了制品,是时候将部署配置为QA了。在QA阶段单击1 job,1 task

  11. 选择之前用于创建资源的Azure订阅,然后单击授权。如果您需要创建与其他Microsoft帐户关联的Azure帐户的连接,请单击New并按照该工作流程继续。

  12. 按照工作流程授权访问您的Azure帐户。

  13. 输入创建QA应用服务时之前使用的应用服务名称

  14. 返回Pipeline选项卡。

  15. 单击触发器按钮以定义将调用此部署的触发器。

  16. 启用 持续部署触发器。添加一个Build分支过滤器,它指向构建管道的默认分支。这将在构建完成时启动部署。

  17. 保存发布管道。

任务3:配置Azure应用服务

  1. 返回打开Azure门户的浏览器选项卡。

  2. 单击左侧菜单中的资源组选项卡。找到并单击之前创建的partsunlimited组。

  3. 单击您的SQL数据库(pul-johndoe/partsunlimited)。确保单击您创建的数据库而不是服务器。请注意,数据库和服务器可能需要几分钟才能使用,因此请每隔一段时间单击刷新按钮。

  4. 在新页面中,单击显示数据库连接字符串

  5. 这将为您提供基于平台的连接字符串列表。将ADO.NET字符串复制到剪贴板,以便配置新网站以使用它。关闭此面板。

  6. 打开Notepad的新实例并将连接字符串粘贴到其中。这将使以后更容易编辑和检索,以防剪贴板副本发生任何事情。

  7. 使用痕迹导航返回partsunlimited资源组。

  8. 单击之前创建的QA应用服务。

  9. settings部分中选择Configuration选项卡。

  10. 在此区域,您可以配置应用程序的设置,例如连接字符串。找到连接字符串部分,并添加一条记录,Name设置为DefaultConnectionString,value设置为从剪贴板粘贴的值。您需要找到“{your_username}”和“{your_password}”部分,并使用之前输入的实际SQL凭据替换它们(包括大括号)。按Enter完成。

     Server=tcp:pul-johndoe.database.windows.net,1433;Initial Catalog=partsunlimited;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
    

  11. 单击工具栏中的Save进行提交。

  12. 重复上述过程,将相同的连接字符串添加到生产应用服务。

任务4:触发QA阶段持续发布

  1. 返回打开Azure DevOps项目的浏览器选项卡。

  2. 现在发布管道已经到位,是时候提交更改以调用构建和发布。在本实验过程中,您需要对此进行一些更改,因此建议您使用单独的选项卡进行Code | files以保持该过程的该部分分开。

  3. 导航到PartsUnlimited-aspnet45 / src / PartsUnlimitedWebsite / Views / Shared / _Layout.cshtml。这是一个定义站点总体布局的文件,是进行部署后很容易看到的更改的好地方。

  4. 单击编辑以内联编辑文件。

  5. 找到Parts Unlimited Logo并在其后添加文本”v2.0“。在部署之后检查这将是一件容易的事情。

  6. 将更改提交到仓库中。这将基于预配置的构建管道启动构建。

  7. 导航到 Pipelines

  8. 打开PartsUnlimitedE2E的最新版本。它可能已排队,正在进行或已完成。

  9. 按照构建直到完成。

  10. 单击Releases选项卡以查看新版本的运行情况。

  11. 单击release。与构建一样,它可能正在排队,正在进行中,或者已经完成。

  12. 等待发布运行成功。

  13. 如果您愿意,现在可以关闭此选项卡。

  14. 在新的浏览器选项卡中,导航到QA站点。它将是您的应用服务的名称加上”.azurewebsites.net“。它应该显示之前添加的v2.0

任务5:在生产阶段创建一个Gated版本

  1. 返回Azure DevOps浏览器选项卡。

  2. 随着release管道变得越来越复杂,定义门以确保整个release管道的质量变得非常重要。从下一阶段我们部署到生产,我们需要确保既包括自动质量门,也包括手动审批门。返回发布管道浏览器选项卡,然后单击QA阶段中的Clone。由于生产阶段几乎相同,我们几乎可以重用所有现有配置。

  3. 新阶段是在当前阶段之后添加的,这是我们想要的。但是,在我们认为QA部署成功之前,我们需要定义部署后条件。单击QA阶段上的部署后条件按钮。

  4. 启用 Gates 选项。

  5. 有几种可用的门可以自动测试您需要的几乎任何东西,以确保部署良好。这些可以是Azure功能或REST API的返回值,Azure中的警报查询或Azure DevOps中的工作项查询。您还可以配置平台在首次评估门之前应延迟多长时间。在这种情况下,将其更改为0,以便在部署后立即对其进行测试。然后单击添加|查询工作项

  6. 将查询选择为Shared Queries| Critical Bug。我们的策略是,在所有关键错误得到解决之前,QA部署不能被视为成功。

  7. 展开评估选项并更新重新评估大门5之间的时间。如果此门失败,我们希望它每隔5分钟重新评估一次查询,直到它清除为止,因为工程师需要一些时间来确认当前版本中是否修复了这些关键错误。但是,如果未清除这些错误且未手动失败,则此配置将在1天后自动失败。

    我们现在可以将注意力转向生产阶段。选择QA阶段的副本。

  8. 将其重命名为”Prod“。

  9. 单击其部署前条件按钮。

  10. 启用预部署批准并将自己添加为审批人。这里的想法是,在QA部署成功之前,不会要求您批准生产部署。此时,此列表中的某个人需要批准部署到生产。同时清除User requesting a release of deployment should not approve 勾选。出于本实验的目的,您可以批准自己请求的release。

  11. 单击Prod阶段的1job,1个task

  12. 更新App服务名称以反映“ -prod”(而不是”-qa“)。

  13. 保存发布管道。

  14. 重复更改代码库的过程”PartsUnlimited-aspnet45 / src / PartsUnlimitedWebsite / Views / Shared / _Layout.cshtml“之前的新选项卡。这次,将版本号从”2.0“更新为”3.0“。这将调用发布管道。

  15. 和以前一样,按照发布版本,直到部署到QA。点击可在发布后自行关注。

  16. 进入发布视图后,单击发布(管道视图)。这将提供发布在管道中的位置的可视化。

  17. 最终QA部署会出现问题。虽然它成功部署,但其中一个质量门失败了。这个阶段需要得到解决才能获得批准。单击查看部署后门按钮。

  18. 看起来查询工作项门失败了。这意味着必须清除一个严重错误。

  19. 打开一个新选项卡以板| 查询以找到错误。

  20. 使用All选项卡上的查询列表打开Shared Queries | Critial Bugs查询。

  21. 单击打开一个错误。

  22. 通常你会检查网站以确认错误是否已修复,但我们将在此处跳过并标记完成。单击保存并关闭选项卡。

  23. 返回发布管道选项卡。根据时间安排,Azure DevOps最多可能需要五分钟才能再次检查查询。一旦发生,将清除错误并批准发布。然后,您可以单击批准以批准部署到生产。

  24. 确认部署。

  25. 单击进行中链接以关注发布工作流程。

  26. 发布可能需要一些时间才能启动并完成。

  27. 发布完成后,打开生产应用服务URL的新选项卡。它应该与您的QA URL相同,但使用”-prod“而不是”-qa“。注意v3.0

任务6:使用部署槽

  1. 返回打开Azure门户的浏览器窗口。

  2. Azure App Services提供部署槽,它们是应用程序部署的并行目标。使用部署槽的最常见方案是为应用程序提供一个预生产环境,以便针对生产服务运行,但不替换当前的生产应用程序。如果与生产的部署通过审核,则可以通过单击按钮立即将其“置换”为生产槽。作为额外的好处,如果新构建发现问题,可以快速撤消并回滚。找到之前创建的资源组,然后单击prod app服务。

  3. 选择部署插槽选项卡。如果您看到一条消息,指示您当前的定价层不支持插槽,请按照工作流程将此服务升级到Production层或更高级别,然后返回此处。您可能需要刷新浏览器以启用Add Slot选项。

  4. 单击添加插槽。请注意,production插槽被视为“默认”插槽,并未在用户体验中显示为单独的插槽。

  5. 输入名称staging“并选择与您现有部署匹配的配置源(应该只有一个)。单击确定以创建插槽。

  6. 使用Prod阶段管道编辑器返回Azure DevOps选项卡。

  7. 选择Deploy Azure App Service任务。

  8. 检查Deploy to slot并将资源组Slot设置为先前创建的那些。

  9. 保存发布管道。

  10. 按照之前的工作流程,通过将布局模板从”3.0“更新为”4.0“。

  11. 按照发布管道进行部署,并在请求时批准发布到生产。

  12. 生产部署完成后,刷新该浏览器选项卡。请注意,由于部署被推送到不同的插槽,因此不应进行任何更改。

  13. 打开staging插槽的新选项卡。这与您的生产URL相同,但”-staging“附加到域中的应用服务名称。这应该反映新的v4.0

  14. 返回到打开Azure门户的浏览器窗口。单击插槽面板中的Swap

  15. 这里的默认选项正是我们想要的:交换生产和临时插槽。单击确定。请注意,如果您的应用依赖于插槽级配置设置(例如标记为“插槽”的连接字符串或应用设置),则将重新启动工作进程。如果您在这种情况下工作并希望在交换完成之前预热应用程序,则可以选择交换预览交换类型。