2015-04-16 43 views
2

我们与一些开发人员合作开发了一个巨大的TYPO3项目。我们试图建立一个CI基础设施,GIT,作曲家和詹金斯。 我们有发展(流浪),舞台和生产环境。临时服务器 上同时有多个功能是很常见的。由于不同的人员负责测试这些功能,因此这些功能通常不会同时应用于生产服务器。 因此,我们建立了以下工作流程:CI工作流程和单一功能部署的大型TYPO3项目

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

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

功能可以更新或安装软件包。只要两个特征分支操作composer.lock文件,就会与文件的“散列”发生冲突,而该散列不能自动合并。

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

此工作流程是一个巨大的边缘案例,还是有最佳实践解决方案?

感谢您的帮助!

回答

-1

我的建议是:

  • 保持composer.lock上(功能)分支机构和(版本)标签只有
  • 分支稳定和发展的一个新功能的版本背景下被锁定
  • 从主开发分支(主)删除composer.lock
  • 主要始终是边缘和发展发展,直到功能(或功能集)冻结
  • 合并功能分支时开发分支排除了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)。从(锁定)版本标记+分配(释放)

  • 安装/生产升级的发布包或后续使用上生产箱作曲家的做法和安装的版本标签


    • 构建部署包: (

    在我看来,最干净的方法是合并整体开发环境到生产的所有功能都经过测试后...

    合并到生产:) - 错,不,那太容易了!

  • 0

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

    我不会合并超过詹金斯当前特征+主,并将手动解决可能的合并问题