尊重部署在Cloudfoundry或Heroku上的Gradle / Spring应用程序的代码库因子(来自12因素应用程序宣言)

时间:2015-12-08 13:40:03

标签: heroku github gradle cloudfoundry 12factor

我的问题涉及12因素应用宣言的第一个因素:代码库。 (见http://12factor.net/codebase)。

TL; DR:

这个因素表明代码库和部署之间存在一对一的关系,因此在这种情况下,您不应该为两个应用程序使用相同的代码库(存储库)

我的要求:我有一个网站Spring应用程序和一个批量Spring应用程序共享一个公共代码,即域模型(JPA实体类)。我需要能够分享这个共同的代码。并且两个应用程序在任何时候都需要使用相同版本的公共代码

我当前的设置:我目前在github上有三个“顶级”存储库:

  • 域模型(JPA实体类)repo
  • 网站申请回购
    • 域模型目录/ gradle项目(包含在git subtree pull/push
  • 批量申请回购
    • 域模型目录/ gradle项目(包含在git subtree pull/push

另请注意,域模型存储库单独存在(如上所述),但也嵌套在网站和批处理应用程序存储库中。我使用git subtree pull/push将此域模型存储库作为目录包含在另外两个存储库中的gradle项目中。原因是Heroku从repos构建代码本身。

这一切都非常繁琐且容易出错。

有人可以建议更好的解决方案吗?

2 个答案:

答案 0 :(得分:2)

我会将公共代码发布到Bintray上的私有Maven仓库,然后将该私有仓库添加到其他消费者应用程序,并将公共模块指定为依赖项。这并不能保证两者都依赖于相同的版本,但可以使用the Maven Versions Plugin等工具通过外部流程轻松管理。但您也可能希望添加一个更灵活的序列化系统来松散地耦合两个应用程序的域模型。

答案 1 :(得分:-1)

我会将域模型捆绑在一个包中(不确定java / gradle对于这样的bundle是什么意思,在ruby中它将是一个gem)并将其作为依赖项安装在生产环境中。否则,git submodule也是一个选项