Trunk Based Development 部署流水线最佳实践

43次阅读
没有评论

问题描述

团队正在过渡到Trunk Based Development(主干开发模式),并开始研究他们的部署流水线以及如何改进。他们当前的工作流程如下:
1. 所有工程师在主干上工作,频繁提交代码,自动部署到开发环境。
2. 当QA在开发环境上进行签名后,通过从主干切出一个发布分支(releases/v1.0)生成一个发布版本,然后将其部署到UAT环境。这是一个手动批准步骤。一旦批准,发布分支会动态生成并推送到代码仓库,并进行部署。
3. 测试团队(QE)随后在UAT中进行端到端测试,他们要求除了仅限于P1缺陷的挑选外,不要合并新的代码。P1缺陷的修复从主干中挑选。开发人员继续在主干上工作,修复其他P2/P3缺陷或添加新功能。
4. 一旦QE在UAT上签字,如果适用,该快照可以被推送到下一个环境,最终进入生产环境。

用户提出了以下问题和问题:
1. 在这种方法中,UAT从发布分支更新。如何处理UAT中未来工作(P2,P3,功能)的签名?我们是否需要一个单独的阶段从DEV部署?
2. 基本上,我正在尝试找出在签名和实际发布之间存在较长间隔时处理发布的最佳方法。随着未来引入功能标志,并最终实现真正的CI/CD,这将发生变化。
3. 我们目前使用Azure DevOps。

解决方案

根据你的问题和现有工作流程,以下是一些建议的解决方案,以便更好地管理Trunk Based Development的部署流水线。

提前引入开发人员测试

在切出发布分支之前,建议加强开发人员的测试文化,特别是自动化测试。可以考虑以下步骤:
– 开发人员应该对主干上的代码进行测试,尤其是自动化测试,以减少在后续阶段发现的问题。
– QA团队可以使用主干在开发环境中进行手动测试,从而提供及早的反馈。

自动化UAT环境的端到端测试

对于UAT环境的端到端测试,建议进行自动化,以减少手动测试的负担。这可以通过以下方式实现:
– 编写端到端自动化测试用例,以覆盖主要的用户场景和功能。
– 将这些自动化测试用例整合到持续集成流程中,确保每次提交都会运行这些测试,以尽早发现问题。

在发布分支上处理P2,P3和功能

在现有的发布分支模式下,如何处理P2,P3和功能的签名是一个重要问题。以下是建议的做法:
– 对于P2和P3缺陷修复,建议从主干进行挑选并合并到发布分支。这样可以确保发布分支中包含了最新的修复。
– 对于功能的签名,可以将功能的代码合并到发布分支,并确保在UAT环境中进行测试。

管理并行UAT环境

如果同时存在多个UAT环境,需要仔细管理以确保并行测试的有效性。以下是一些建议的方法:
– 确保每个UAT环境都有独立的数据和资源,以避免相互干扰。
– 如果可能,尽量减少并行UAT环境的数量,以降低管理复杂性。
– 定期同步并行UAT环境中发现的问题和修复,确保环境之间的一致性。

未来计划:功能标志和CI/CD

考虑到未来引入功能标志和实现CI/CD的计划,以下是建议的步骤:
– 开始逐步引入功能标志,以便在需要时可以启用或禁用特定功能。
– 逐步引入CI/CD流程,将持续集成和持续交付纳入工作流程中。这将有助于减少发布的时间间隔,并提高部署的可靠性。

使用Azure DevOps

作为你目前的工具,Azure DevOps可以帮助你实现上述建议的步骤。你可以使用Azure DevOps的自动化构建和发布功能来实现持续集成和持续交付流程。

总结

在过渡到Trunk Based Development并改进部署流水线时,需要考虑如何有效地管理不同阶段的签名和部署。通过引入开发人员测试、自动化测试、合理处理发布分支上的工作、管理并行UAT环境以及未来计划功能标志和CI/CD,你可以逐步优化你的工作流程,实现更快速、可靠的部署。

请注意,这些建议是基于当前的情况和目标,随着你的团队的发展和技术的进步,可能需要进行调整和优化。

正文完