问题描述
目前在GitLab上使用Git工作流程，使用3个核心分支（master、preprod和develop）。他们从develop分支创建功能分支，然后将其合并回develop进行初始测试。将功能合并到develop分支会触发一个流水线，用于测试、构建和部署到开发服务器，以便项目所有者可以审查正在进行中的代码。一旦获得批准，develop分支会合并到preprod，这也会触发一个流水线，将其部署到UAT环境进行用户验收测试。一旦获得批准，preprod分支会合并到master，然后手动触发一个流水线，将其部署到生产环境。
这种方法存在一些问题，但最大的问题是瓶颈。如果在preprod中有一个我们还不想发布的功能，但另一个功能即将到来，那么绕过我们还不想的功能就会变得棘手。因此，我们正在考虑采用不同的分支策略，比如GitFlow。
现在是我无法解决的部分！目前，为了在可以查看和测试功能的环境中部署功能，我们通过合并到特定分支触发流水线。然而，我希望在测试功能和热修复时摒弃这种方法。基本上，我需要一种方式来运行一个流水线，可以随时运行任何分支的自动化测试、构建和部署。因此，如果我正在开发FeatureA，我可以将该分支推送到GitLab，并将其部署到某个地方，以便可以与同事正在开发的FeatureB进行独立审查。这样做有意义吗？就像一个动态的流水线，具有动态环境，需要时启动并在不再需要时销毁。
如果有人能指点我正确的方向，我将不胜感激！
还应该补充一点，我们正在开始在本地使用Docker进行开发，因此可以考虑使用Docker来创建动态测试环境的解决方案。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
将持续集成（CI）和持续部署（CD）分离是一个好的做法。在Git工作流程中，分支策略（如GitFlow）用于帮助开发人员隔离和共享他们的工作，而部署环境则是独立的过程。这样可以使开发人员更加舒适，部署过程更加灵活。
以下是将CD与GitFlow结合的一种方法：
1. 将GitFlow简化为传统的master/develop永久分支和一组feature/hotfix和release分支。
2. 使用语义化版本控制（如semver）来区分不同的分支。官方版本（release分支或hotfix分支合并后）保持严格，而其他分支则使用预发布版本。例如，预发布分支可以添加一个-SOMETHING，其中SOMETHING是分支的名称，可能还包括一个时间戳以区分连续的部署。
– release分支的版本号可以是x.y.0-RCi（第i个发布候选版本）。x.y是将要发布的版本，-RC在合并到master时会被删除。0表示release分支用于新功能和产品演进。
– hotfix分支与release分支的原则相同，只是修补程序号设置为非零值。
– develop分支可以是x.y.z-dev.timestamp。
– feature分支可以是x.y.z-JiraID-timestamp，其中JiraID是用于跟踪新功能的系统的票号（如Jira、Bugzilla等）。
3. 将版本构建和打包，并将其存储在某个地方。可以是简单的网络共享或FTP站点，也可以与现有的包管理器结合使用适当的后端，根据团队的需求选择合适的方式。选择取决于使用的技术栈和部署的底层平台（静态环境、Docker、Kubernetes、独立的复制和运行等）。
4. 使用另一组任务来拉取任何已构建的版本并组装一个可用的部署环境。这将形成持续部署（CD）的一部分。可以使用动态环境，也可以使用静态环境，具体取决于需求。
5. 一旦解耦，您可以启动包含以前构建的任何版本的环境。
6. 您甚至可以拥有多个生产环境，其中包含略有不同的用户界面调整，并使用A/B测试等技术将它们与用户进行比较。
通过将持续集成（CI）和持续部署（CD）分离，您可以简化GitFlow并使部署过程更加灵活和自由。
希望对您有所帮助！
方案2
在手动模式下，您甚至不需要这些工具就可以开始并使其正常运行。实际上，我强烈建议您首先手动尝试，这将暴露出需要自动化的内容，并使您更好地了解如何在这些工具中寻找解决方案。在手动模式下，您的打包可以是简单的存储库内容的tarball，保存在共享空间上。部署几乎与现在相同，只是您从这些tarball中获取版本，而不是进行git克隆。
接下来是如何安装此版本。您的虚拟机在git克隆可用之前是否需要进行任何准备工作？如果是，那么也要将所有这些内容脚本化。完成所有这些后，您的下一步可能是使用Docker自动构建一个工作服务器，逐步向着Kubernetes等目标迈进。您不必达到最终目标，只需在添加足够的价值并感觉整个设置变得不那么混乱时停下来。让您学到的所有东西沉淀下来，稍后再回来并进一步推进。