问CD与GitFlow相结合

EN

将部署环境和分支混为一谈常常会导致您所描述的问题。这似乎是一种自然的契合，很容易映射到理想解决方案的心理模型，但是，现实生活绝不是理想的。

基本上，git不是一个部署工具，不应该克隆来部署一个版本，而是获取一个包( tarball、zip文件、docker容器、NPM包等等)。

实际上，这两个概念是正交的。分支策略(无论是什么，急流、主干为基础等)是帮助开发人员隔离和共享其工作的一种方法。它自然地与版本控制策略联系在一起，是构成CI/CD系统的一半的内容。在这里，您必须强迫自己将CI (连续集成)与CD (连续部署)分开，如果您阅读，您将看到这一点。

然而，部署消耗了所创建的版本的结果，并集成了系统的各个部分，使得整个系统是可用的、可测试的。

因此，如果您将分支和其中的代码视为一种组装版本的方法，构建系统将对其进行构建和打包，然后将其存储在某个地方。可以像网络共享或FTP站点一样简单，也可以将其绑定到具有适当后端的现有包管理器中，这是最适合您的团队的。这一选择将在很大程度上取决于您正在使用的技术栈和您将要部署到的底层平台(静态环境、对接器、kubernetes、独立复制和运行等)。

然后，另一组任务可以引入这些版本中的任何一个，并组装一个工作部署。在这里，如果您的部署环境是动态的，那么这是最好的，但是它也可以用于静态环境。这将构成您的连续系统的CD部分。

一旦解耦，您就可以创建一个包含以前构建的任何版本的环境。

在术语上，您甚至可以拥有多个生产环境，用户界面的细微变化会使它们相互矛盾--其他的技术有A/B测试和聪明的负载平衡/分发给最终用户。

回到您的特定情况，它将简化您的gitflow回到一个更传统的主/开发永久分支和一组特性/修复和发布分支。

使用符号学，您可以严格地为主合并(来自发布分支或修复分支)和所有其他分支的预发行版本保留正式版本。对于您的发布前分支，只需添加一个-SOMETHING，其中某些内容是分支的名称，例如，也可能是区分连续部署的时间戳。

例如,

• 发布分支将获得x.y.0-RCi (第一个发布候选版本)。x.y是将发布的版本，在该版本中，当-RC合并到主服务器中时，只需删除该版本。0作为修补程序，因为发行分支用于新特性和产品开发。
• 除补丁号设置为非零值外，hotfix分支遵循与发布分支相同的原则。
• 开发部门可以获得x.y.z-dev.time戳
• 特征分支x.y.z-JiraID-时间戳。其中，JiraID是用于跟踪新特性(如Jira、Bugzilla等)的系统的票号。

我在这里提出语义版本控制，因为我对它很熟悉，但是通过版本控制分离分支的同样广泛的原则几乎可以适用于任何版本控制方案。

在源代码管理中，您看不到任何与部署环境有关的内容。只有您的版本控制策略才能将它们连接起来，否则它们是完全孤立和独立的。

在这个新的环境中，您的开发人员会感到更舒服，您的部署也会感到不那么拘束和尴尬。

希望这能有所帮助