在常春藤中推广多个模块(集成->里程碑)

|| Ivy非常适合管理依赖项,但并不意味着可以处理许多模块的整个软件生命周期。也就是说,它确实具有一些似乎可以支持它的功能(例如
status
branch
属性),而常春藤的最佳实践则模糊地暗示了能够“通过一些工作”将集成修订版本推向里程碑或发布。 不幸的是,我还没有找到有关如何管理开发->测试->部署周期的权威指南。这是我要实现的一些目标: (鉴于开发人员通常跨本地工作区中的许多模块工作) 开发人员可以在本地发布对模块的更改,以便工作空间中的其他模块可以获取更新的工件。 开发人员可以使用一个命令将版本指定为“准备部署以进行测试”。 测试人员可以使用一个命令将版本指定为“准备生产”。 开发人员可以从源代码重建任何版本,并且可以正确拾取适当的依赖项(也称为可重复构建)。 我相当清楚的一些事情是: 修订版“ 0”应用于表示该修订版是仅用于开发,准备进行测试还是准备进行生产
branch
属性应足以处理不同的项目分支 这是我要解决的问题: 如何促进集成构建 假设我在工作区中检出了以下模块: 现在,我对模块a感到满意,并决定使用工作区中检出的版本发布里程碑。回购中需要发生的是:
e-1.0-RC1
出版
d-1.1-RC2
发表,将,4ѭ作为依赖项
c-2.0-RC1
发表,将,5ѭ作为依赖项
b-3.3-RC1
发表,将,4ѭ作为依赖项 最后,
a-7.1-RC2
被发布,将
c-2.0-RC1
b-3.3-RC1
作为依赖项。 如果为此尝试自己动手,我可能最终会做一些工作区管理,ivy.xml查找和替换等工作。在打开蠕虫病毒罐之前,我想征询一些意见。解决这个问题的最佳方法是什么?     
已邀请:
        您可以使用递归传递来发布状态更高的模块及其依赖项。 使用您的示例:
e-1.0-RC1
的出版状态为published15ѭ
d-1.1-RC2
的发布状态为ѭ15published,将
e-1.0-RC1
作为依赖项
c-2.0-RC1
的发布状态为
integration
,并以dependency5依赖
b-3.3-RC1
的发布状态为published15 ,,并以
e-1.0-RC1
作为依赖项
a-7.1-RC2
的发布状态为published15ѭ,并以dependencies7ѭ和
b-3.3-RC1
作为依存关系。 最后,您决定将
a-7.1-RC2
提升为
milestone
状态,以便进行回溯交付(使用
delivertarget
属性)。对于状态低于
milestone
的每个依赖项,这将递归调用
delivertarget
并将其发布为
milestone
状态。 这样做的好处是,您不需要(或不想)在工作区中检出每个项目,只需
a
。这也意味着创建部署管道和配置CI服务器要容易得多: 对ѭ35进行单元测试, 建
a
, 将
a
设为
integration
, 将ѭ35部署到系统测试环境中, 运行一些系统测试 将
a
integration
提升至dependencies30 dependencies(这增强了它的依赖性) 将ѭ35部署到验收测试环境中, 运行一些验收测试 将
a
milestone
提升至
release
(这增强了它的依赖性) 将ѭ35部署到生产环境(或将其上传到下载站点) 流水线绝不需要访问依赖项目,并且由于递归交付是通用的,因此当您添加或删除依赖关系(通过ivy.xml文件)时,您不需要更改流水线中的任何内容。 我已将此答案标记为社区Wiki。还有其他人愿意扩大它或纠正我做错的任何事情吗?     
        您如何生产? 从里程碑升级到发布(提升了它的依赖性) 我正计划进行检索和发布。有没有更好的办法?     

要回复问题请先登录注册