Azure Data Factory发布分支(_publish)使用困惑及分支管理咨询

先明确标准流程 #

1. 创建本地分支：在ADF分支下拉菜单中选择创建本地分支，添加/修改管道（保存时更改自动保存至Git本地分支）
2. 将本地分支的更改推送到master（协作）分支
3. 在ADF中切换到master分支
4. 发布至_publish分支
5. 将_publish合并回master分支

注意：这里用于发布的_publish分支是ADF自动维护的发布分支，它和master分支内容存在核心差异——_publish包含ADF运行时所需的格式化配置文件，而master是团队协作开发的源码分支。

针对你的疑问的解答 #

疑问1：若需在_publish分支上添加存储账户创建等优化操作，是否应从_publish创建特性分支？

绝对不建议这么做！_publish是ADF自动生成并维护的发布分支，它的内容完全由master分支的源码转换而来，手动修改该分支或基于它创建特性分支，后续的ADF发布操作会直接覆盖你手动添加的内容，还会破坏整个发布流程的一致性。

正确的处理方式是：

• 所有配置更改（包括存储账户创建这类优化）都在本地特性分支完成
• 提交并合并到master分支后，再通过ADF的标准发布流程同步到_publish
• 如果是需要在发布阶段执行的自动化操作（比如存储账户创建），应该通过ADF的发布管道或外部自动化工具（如Azure DevOps Pipeline）实现，而非直接修改_publish分支。

疑问2：步骤4至5期间其他开发者可能影响分支，如何使_publish分支及其内容成为“主分支”？

首先要明确：_publish分支从设计上就不应该作为“主分支”，它只是ADF的发布载体。你真正需要的是确保发布流程不受干扰，保证发布内容的一致性，可以通过以下方式实现：

1. 临时分支保护：在执行发布操作前，通知团队成员暂停向master提交更改，或者在Git仓库中给master设置临时保护规则（比如禁止PR合并），直到你完成_publish合并回master的操作。
2. 预发布分支策略：不要直接从master发布，而是创建release/*预发布分支，拉取当前要发布的master代码，在预发布分支完成测试后再发布到_publish，最后将release/*合并回master。这样即使其他开发者在master上提交更改，也不会干扰当前发布流程。
3. 自动化发布流水线：把步骤4和5做成自动化流水线（比如用Azure DevOps Pipeline），触发发布后自动完成发布到_publish并合并回master的操作，压缩手动操作的时间窗口，降低被干扰的概率。

内容的提问来源于stack exchange，提问作者Blue Clouds