我正在寻找一个我希望有人建立的软件.我将在这里描述这个软件,希望有人听到这样的事情,并指出我正确的方向.
我正在开发一个部署在Heroku上的Web应用程序.由于Heroku的限制,我被置于不幸的情况下,有四(4)个远程Git回购用于同一个回购.
为什么四个？
我们在Heroku上有多个"应用程序".一个用于制作和一些升级"应用程序".这些都是针对相同的实际应用程序,但在Heroku上它们是独立的"应用程序",因此我们可以在将它们推向生产之前尝试进行分段.
Heroku上的每个应用程序都有自己独立的Git仓库,并在master每次将新提交推送到该master分支时自动部署分支.Heroku的这项政策是我们问题的症结所在.因为这意味着我们在Heroku上有3个不同的回购,加上我们的GitHub回购.
为什么有4个不同的Git遥控器有问题？因为这意味着当您开发和创建新提交时,您必须(1)仅推送到一个遥控器或(2)推送到所有遥控器.
做(1)意味着要考虑你想要推送哪个遥控器.我讨厌不得不考虑这个问题.当我开发时,我不关心遥控器,我承诺并推动并重新开始工作.例如,如果我想将分支部署到临时服务器1,我会将该分支合并到staging_1分支中并推送它.我不喜欢挑选哪个遥控器.
(1)的另一个缺点是你的遥控器不同步.
我想要的是(2).我希望每一次推动都能推动我们所有的四个回购.
但是有两个问题:
问题1:Heroku上的暂存"应用程序"部署了什么master.我不希望他们这样做.我想将staging_1我的仓库中的master分支映射到登台服务器Git repo上的分支.
问题2:将计算机推到所有4个回购站需要很长时间.即使1个Heroku推动动作也需要很长时间.有时可能需要40秒.
这就是我想要的.我想有一个专门的Git服务器充当代理.每当我从本地计算机推送到这个Git服务器时,它会将这些相同的分支并行地推送到我们的4个存储库中.这样,从我本地计算机的角度来看,推送似乎是即时的,而这个代理服务器将自动在后台处理Heroku存储库.
如果由于任何原因推送到4个遥控器中的任何一个失败,我希望这个代理以某种方式报告,所以我会知道某些东西被破坏并且可以解决它.
该代理必须做的另一件事是master映射.每次我将staging_1分支推送到它时,它都会将其推staging_1送到所有远程控制器,但是对于属于登台服务器的远程控制器,它也将推送该分支master,因此Heroku将知道部署它.
(令人非常难过的是Heroku的设计方式让我需要像这样的代理,但这就是我必须要处理的事情.)
就是这样了.这是我想要的解决方案.有谁知道这样的节目？
这对我来说似乎有点疯狂。我在 Heroku 上有多个运行不同环境的应用程序。我有一个 Github 存储库，然后是适用于不同环境的 Heroku 遥控器。我还倾向于维护一个与 Heroku 遥控器之一匹配的 Git 分支。
然后完成部署（如约翰所说）：
git push heroku_remote local_branch:master
我在这里记录了这个基本方法：
http://neilmiddleton.com/deploying-topic-branches-to-heroku/
然而，据我所知，您需要完全自动化。您可以使用TDDium等服务来为您执行此类操作，监视 Git 分支，然后在测试套件通过时推送到远程分支（例如 Heroku 远程分支）。
http://neilmiddleton.com/continuous-deployment-with-heroku/
我非常确定 TDDium 方法将通过附加的 CI 层满足您的需求。
| 归档时间： |
|
| 查看次数： |
416 次 |
| 最近记录： |