兴趣点是：(随意改变)
>避免发明超出想象的需要的新的“头痛”.
>仍然可以轻松构建一切,当您仍然想要在给定的开发机器或CI服务器.
>生产包装：能够使用SbtNativePackager将您的东西包装在生产中而不会有太多的痛苦.
>轻松控制在给定的开发机器上使用的每个库的哪个版本,并且能够无缝地在它们之间切换.
避免git操作变得比它基本上更糟糕.
另外,你会使用某种“本地sbt / maven团队资源库”,还有什么可能需要做到这一点？希望这是没有必要的.
谢谢！
解决方法
>最终在不同部署中的代码在同一个存储库中的不同文件夹中,在一个总体项目下 – 什么SBT称为multi-project build(我使用maven而不是SBT,但概念非常相似).它将被构建/部署到不同的罐子.
在设计有意义的部门时,我会尝试考虑最终的部署.例如,如果我的系统foosys具有foosys-frontend和foosys-backend可部署性,那么foosys-frontend将HTML模板和foosys-backend与数据库进行通信,并且两者通过REST API进行通信,那么我将把它们作为单独的项目,以及用于通用代码的foosys核心项目. foosys-core不允许依赖于html模板库(因为foosys-backend不需要),也不允许在ORM库中(因为foosys-frontend不希望这样做).但是我不用担心将REST库中的代码与“核心域对象”分开,因为foosys-frontend和foosys-backend都使用REST代码.
现在我想添加一个新的foosys-reports可部署,它访问数据库来做一些报告.然后我可能会创建一个foosys-database项目,这取决于foosys-core,以保存foosys-backend和foosys-reports所使用的共享代码.而且由于foosys报告不使用REST库,我也应该从foosys-core中分离出foosys-rest.所以我最终得到一个foosys核心库,另外还有两个依赖它的库项目(foosys-database和foosys-rest)和三个可部署的项目(foosys-报告取决于foosys-database,foosys-frontend取决于foosys -rest和foosys-backend取决于两者).
您会注意到,这意味着可以使用该代码的每个可部署组合的一个代码项目.所有三种可部署的代码都在foosys-core中.该部署项目中只有一个可部署的代码.在三个可部署中的两个中的代码在foosys-rest或foosys-database中.如果我们想要一些代码是foosys-frontend和foosys-reports可部署的一部分,而不是foosys-backend可部署的代码,那么我们必须为该代码创建另一个项目.在理论上,这意味着在我们添加更多可部署项目时,项目数量呈指数级的上升趋势.实际上,我发现这并不是太有问题 – 大多数理论上可能的组合实际上都没有意义,所以只要我们在创建新的项目时,我们实际上有代码就可以了.而如果我们结束了几个foosys核心的课程,这些课程并不是每个可部署的实际使用的,所以并不是世界的末日.
在这种观点中,测试最好被理解为另一种可部署.所以我将有一个单独的foosys测试项目,包含用于所有三个可部署项目(取决于foosys-core)的测试的通用代码,也可能是一个foosys-database-test项目(取决于foosys-test和foosys-database )用于在foosys-backend和foosys-report之间通用的测试助手代码(例如数据库集成测试设置代码).最终我们可能会得到完整的并行层次结构的测试项目.
一旦它们具有不同的发布生命周期,只需将项目移动到单独的git存储库中(并且同时分开整体构建).
不同存储库中的代码必须独立版本化,因此在某种意义上,这是一个空虚的定义.但是我认为只有当你必须(只有使用this post：你应该只使用Hadoop,当你的数据太大,不能使用任何更友好的东西)时,你应该继续分开git仓库.一旦您的代码在多个git存储库中,您必须手动更新它们之间的依赖关系(在一台可以使用-SNAPSHOT依赖关系和IDE支持的开发机器上工作,就像这些版本仍然保持同步,但是您必须手动更新每次你与主人重新同步,所以它增加了开发的摩擦力).由于您正在发布和异步更新依赖关系,您必须采用并执行类似语义版本控制的操作,以便人们知道何时可以更新对foocorp-utils的依赖关系以及何时不更新.您必须发布更改日志,并具有早期警告的CI构建和更彻底的代码审查过程.所有这一切是因为反馈周期要长得多;如果你在一个下游项目中打破某些东西,直到他们更新对foocorp-utils的依赖,几个月甚至几年后才会知道这一点(是的,几年 – 我见证了这一点,而在80个人的启动中,一个megacorp).所以你需要防止这种情况的过程,一切都变得相对较少敏捷.
有效的理由包括：
>您的项目的完整构建需要太长时间,减慢您正在开发的代码的集成 – 尽管尝试加快速度.
>部署所有可部署时间太长 – 尽管如此,尝试自动化并加快速度.保持一切都保持同步的真正优势,你不想放弃,直到你绝对必须.
>单独的团队需要处理代码.如果你不是彼此不断沟通,那么你还需要过程开销(语义版本控制等),所以你可以获得更快的构建时间. (很明显,我认为每个git仓库都应该有一个拥有并负责任的团队,当团队分裂时,他们应该拆分仓库,我对发布流程和责任有进一步的想法,但是这个答案已经很久了) .
我会使用一个团队maven仓库,大概是Nexus.实际上,我会推荐这个甚至在你进入多项目阶段之前.它很容易运行(只是一个Java应用程序),您可以通过它proxy your external dependencies,这意味着您有一个可靠的依赖项的源,即使您的上游依赖关系消失,您的构建也将重现.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
