具有CI工作流和单一功能部署的巨大TYPO3项目

时间:2015-04-16 20:51:20

标签: git continuous-integration workflow typo3 composer-php

我们与几个开发者合作开展了一个巨大的TYPO3项目。我们尝试使用GIT,作曲家和Jenkins设置CI基础设施。 我们有开发(流浪),分期和生产环境。登台服务器上有多个功能是很常见的 同时。由于不同的人负责测试这些功能,因此这些功能通常不会同时应用于生产服务器。 所以我们设置了以下工作流程:

所有开发人员都从主分支开始,并创建自己的功能分支。当该功能应转到登台服务器时,应推送功能分支。 我们有一个配置,其中定义了所有功能分支,应该进行分段。 Jenkins先生在构建项目之前合并了所有功能分支 将所有内容部署到登台服务器。如果成功测试了一个功能并且应该进入生产,则必须将功能分支合并到主服务器。 詹金斯先生建立了这个项目,一切都将部署到生产中。

到目前为止,除了一点之外,我们对工作流程非常满意:composer.lock文件。

功能可以更新或安装软件包。只要两个功能分支操作composer.lock文件,就会发生与" hash"的冲突。无法自动合并的文件。

在我看来,没有干净的解决方案。对我来说唯一的解决方案是从存储库中排除composer.lock文件,让Jenkins先生做一个"作曲家更新"这导致所有必需包的未定义状态。 我认为最干净的方法是在测试完所有功能后将整个开发环境合并到生产环境中,但由于组织原因,无法做到这一点。

这个工作流程是一个巨大的优势,还是有最佳实践解决方案?

感谢您的帮助!

2 个答案:

答案 0 :(得分:0)

真的应该composer.lock文件添加到你的git项目中,因为否则你会在jenkins获得不同的版本,当然也包括每个开发者!

我不会在jenkins上合并当前的功能+主人,并且会手动解决可能的合并问题

答案 1 :(得分:-1)

我的建议是:

  • 仅在(功能)分支和(版本)标签上保留composer.lock
  • 分支是稳定的,用于开发新功能的版本上下文已锁定
  • 从主开发分支(master)中删除composer.lock
  • master始终处于最前沿,并且在功能(或功能集)冻结之前会发生开发
  • 将功能分支合并到开发分支时,会排除composer.lock文件
    • 您可以使用git merge --no-commit,然后编辑合并,unstage composer.lock,然后git commit -m "merged <feature-branch>"
  • 关于功能冻结,分支输出(新版本标记)并添加composer.lock以锁定版本上下文

归结为:feature branch (locked)dev-master (unlocked)version tag (locked)


  • 从(已锁定)版本标记+分发(发布)
  • 构建部署包
  • 在生产时安装/升级发行包或按照在生产箱上使用composer的方法并安装版本标签:(
  

我认为最干净的方法是在测试完所有功能后将整个开发环境合并到生产中......

合并到制作:) - 错误,不,这太容易了!