将部署通道与扩展版本配合使用

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

使用部署圈，可以逐步部署和验证对生产中扩展的更改，同时限制对用户的影响。

我们不建议同时部署到所有生产环境，这会向更改公开所有用户。 逐步推出会向用户公开一段时间内的更改，从而验证生产中的更改，且用户较少。

下表显示了在使用环与无环时受影响区域的差异。

没有戒指	受影响的区域	带环
手动和容易出错	生成	自动化且一致
手动和容易出错	版本	自动化且一致
小时数	生成时间（TTB）	秒
日	发布时间（TTR）	分钟
从用户呼叫	问题检测	主动
天数到周数	解决问题	分钟到天

有关详细信息，请参阅 配置用于安全部署的发布管道。

先决条件

• 查看 CI/CD 管道和审批，了解管道的详细文档以及发布的审批功能。

分配用户类型

确定哪些用户最适合每个用户类型。 传达提供反馈的机会以及每个层的风险级别，因为设置期望并确保成功至关重要。 在以下示例中，用户分为生产中的三个组：

• Canaries：在功能可用后立即自愿测试功能。
• 早期采用者：自愿预览版本，被视为比金丝雀位更精细。
• 用户：在通过 Canaries 和早期采用者后，使用产品。

映射拓扑

将扩展的拓扑映射到环形部署模型，以限制更改对用户的影响并传递价值。 对于开源社区扩展，我们大多使用基于环的部署来逐步向 Canary、早期采用者和用户公开新版本。

在应用程序级别，Azure DevOps 扩展的组合易于独立消化、缩放和部署。

每个扩展执行以下任务：

• 具有多个 Web 和脚本文件之一
• 与 Core 客户端的接口
• 使用 REST 客户端和 REST API 的接口
• 在缓存或复原存储中保留状态

在基础结构级别，扩展将发布到 市场。 在组织中安装扩展后，它由 Azure DevOps 服务门户托管，状态将保存到 Azure 存储或扩展 数据存储。

扩展拓扑非常适合环形部署模型，并将扩展发布到每个部署圈：

• Canary 通道的专用开发版本
• 早期采用者圈的专用预览版
• 用户圈的公共生产版本

提示

将扩展发布为 专用扩展，以控制对受邀用户的公开。

通过部署圈移动更改

请参阅以下示例流，通过部署通道移动更改。

使用 Azure DevOps 开发人员工具生成任务扩展将扩展打包并发布到市场。

1. 倒计时小组件扩展项目的开发人员将更改提交到 GitHub 存储库。
2. 提交会触发持续集成生成。
3. 新生成会触发持续部署触发器，该触发器会自动启动 Canaries 环境部署。
4. Canaries 部署将专用扩展发布到市场，并将其与预定义组织共享。 只有 Canaries 才会受到更改的影响。
5. Canaries 部署触发早期采用者环境部署。 部署前审批门要求任何一个授权用户批准发布。
6. 早期采用者部署将专用扩展发布到市场，并将其与预定义组织共享。 Canaries 和早期采用者都受到更改的影响。
7. 早期采用者部署触发用户环境部署。 更严格的预部署审批门要求所有授权用户批准发布。
8. 用户部署将公共扩展发布到市场。 在此阶段，组织中安装了扩展的每个人都会受到更改的影响。
9. 意识到更改在环中移动时，效果会增加，这是关键。 向 Canaries 和早期采用者公开更改可提供两个机会，在发布到生产环境之前验证更改和修补程序关键 bug。

监视问题

监视和警报有助于检测和缓解问题。 确定哪种类型的数据很重要，例如：基础结构问题、冲突和功能使用情况。 专注于可操作的警报，以避免用户忽略它们并缺少高优先级问题。

提示

从数据的高级视图开始，视觉仪表板，你可以根据需要从远处观看和向下钻取。 定期管理视图并消除所有噪音。 视觉对象仪表板讲述的故事比许多通知电子邮件更好，通常通过电子邮件规则筛选和忘记。

使用 团队项目运行状况 和其他扩展来生成管道、潜在顾客和周期时间的概述，并收集其他信息。 在示例仪表板中，很明显，有 34 个成功生成、21 个成功版本、1 个失败的版本和 2 个版本正在进行中。

是否依赖于功能标志？

否。 有时，可能需要将某些功能部署为发布一部分，但最初不会向用户公开。 功能标志提供对更改中包含的功能的精细控制。 例如，如果你对某个功能不完全有信心，则可以使用功能标志在 一个或多个部署圈中隐藏 该功能。 可以启用 Canaries 圈中的所有功能，并为早期采用者和生产用户微调子集，如下图所示。

有关详细信息，请参阅 使用功能标志的渐进式试验。

常见问题解答

问：如何知道可以将更改部署到下一个圈？

答：对于批准发布的用户，应具有一致的检查列表。

问：在将更改推送到下一个圈之前，你等待多长时间？

没有固定持续时间或“冷却”期。 这取决于成功完成所有发布验证所需的时间。

问：如何管理修补程序？

答：环部署模型允许像处理任何其他更改一样处理修补程序。 捕获问题越早，可以更快地将修补程序部署到下游通道。

问：如何处理跨共享发布环境的变量？

答：请参阅 默认和自定义发布变量。

问：如何管理管道使用的机密？

答：若要保护管道使用的加密密钥和其他机密，请参阅 Azure 密钥库。

相关文章

• 安全部署实践
• 采用功能标志的渐进式试验
• 为安全部署配置发布管道。