在任何给定时间，只有大约4个git分支正在积极开发和测试。在每个git分支中，可能必须运行数据库演化脚本（直接SQL），以及来自后端的演化脚本以进行更繁重的处理（本质上，这些是必须在应用程序中使用执行数据库的管理员凭据调用的HTTP路由迁移和其他更改，这些更改太困难/不可能在上述普通的SQL演化脚本中编写）。我们有一台全新的Dell PowerEdge服务器，可以随时使用，并且可以随时安装。 ：
如何在登台服务器上运行几个不同的分支？这些分支通过质量检查后会突然弹出并消失，并合并为master并释放。
我将如何设置数据库演化系统以确保每个分支始终具有适当的数据库？每个分支可能会以不同的方式对数据库进行修改，直到合并后它们才彼此不一定兼容。
如何使这些分支保持最新状态？有没有一种方法可以在每个分支上自动提取提交？
我将不胜感激，因为我对如何设置所有内容都有些迷茫。当前的工作流程对所有相关人员都很困难：开发人员具有在本地运行的应用程序的完全隔离的本地副本，并且质量检查人员轮流使用3-4台便携式计算机作为其暂存“服务器”
#1 楼
1）如何在登台服务器上运行几个不同的分支？
2）我将如何设置数据库演化系统以确保每个分支始终都有合适的数据库？使用克隆数据库数据的方法会使您大为疯狂，但是通常情况下，您会希望在代码发布到生产环境之前不要更改主副本，并在备份时保留良好的备份。虽然您的基础架构可以是不变的且可支配的，但您的数据却并非如此。您只能用数据模拟可处理性。 4.2 GB确实没什么可复制的。您可以制作一个脚本，为要运行的每个构建生成一个新的数据库实例，然后在测试完成后将其丢弃。日期？有没有一种方法可以在每个分支上自动提取提交？
您可以考虑使用git hook之类的东西来触发构建，强制执行代码检出或开始产生容器并克隆数据库。您可以对诸如Jenkins之类的构建自动化系统进行API调用，和/或使用它来启动诸如Puppet，Chef，Salt Stack，Ansible之类的配置管理系统。
从问题的措辞来看，很明显，您正在考虑可变的基础结构，但可以考虑使用不可变的测试部署。 >
#2 楼
我认为这实际上与登台服务器无关。登台服务器紧密地模拟了生产环境，并且在发布之前立即将其发布。尚未合并到master中的功能分支不会直接发布到生产环境中，因此它不应在登台服务器上运行。如果将问题重构为关于共享开发服务器的问题，那么您将在搜索时找到更多资源。您已经注意到，共享这样的开发资源会导致许多问题，因此，专注于解决根本问题可能更好：为什么参与此过程的每个人都很难在本地运行开发服务器机器？
现在，有时候情况是您确实需要拥有这些共享服务器。如果您已经通过并确定自己确实做到了，那么可以采用多种技术来简化该过程。
如何在登台上运行多个不同的分支服务器？这些分支通过质量检查并合并到master并释放后，经常弹出并消失。已执行（此更改是为什么它不是适当的登台环境的一部分）。我过去使用通配符DNS（因此任何
foo.our-dev-domain.com都将重定向到同一台服务器）和路由代码（已在包含路径中加载/our/release/directory/foo）完成了此操作。使用类似Ansible的东西）为分支添加必要的配置。这可能是部署过程的一部分，我将在稍后讨论。每个分支？每个分支可能会以不同的方式对数据库进行修改，直到合并后，它们不一定彼此兼容。最简单的方法就是忍受它，并鼓励人们拥有短暂的分支。
另一种方法是使用动态路由代码切换到单独的副本。基于分支名称的数据库（在RDBMS术语中为“数据库”）。
如何使这些分支保持最新状态？有没有一种在每个分支上自动拉动提交的方法？
您可以推入或拉出。例如：
拉-设置一个cron作业，每隔几分钟执行一次
git pull（或者可能是git fetch和git reset --hard）push-设置一个在推送时触发的webhook，并在机器上监听一个小Web服务，并在必要时更新存储库
push-让开发人员明确运行deploy命令来更新其在服务器上分支
首先与您的用户交谈，并收集他们的要求以查看他们想要的内容（他们可能不喜欢在测试过程中自动更新它），并且告知您的决定。
但是再次：轮流充当其暂存“服务器”的问题
问题似乎在于，QA旋转共享笔记本电脑，而不是像开发人员那样仅检查特定分支。
#3 楼
这就是gitlab最好的，考虑迁移到gitlab，设置kube集群并自动部署。这会将每个分支部署到唯一的URL进行测试。
评论
也许考虑（真正的）持续集成-基于主干的开发？整个分支梦night将消失，每个人都将在同一页面上，依此类推……更简单，更快，更好。您正在使用或已考虑使用数据库版本控制工具？ releasemanagement.org/2016/02/数据库版本控制工具