Ivy 非常适合管理依赖关系，但它并不意味着跨多个模块处理整个软件生命周期。也就是说，它确实有几个似乎支持它的功能（例如 status 和 branch 属性），以及 常春藤最佳实践模糊暗示能够“通过一些工作”促进对里程碑或版本的集成修订。
不幸的是，我还没有找到关于如何管理开发的明确指南 ->测试->部署周期。以下是我想要实现的一些目标：（
考虑到开发人员通常在本地工作区中跨多个模块工作）
- 开发人员可以在本地发布对模块的更改，以便工作区中的其他模块可以获得更新文物。
- 开发人员可以使用一个命令将版本指定为“准备部署测试”。
- 测试人员可以使用一个命令将一个版本指定为“准备生产”。
- 开发人员可以从源代码重建任何版本，并且正确选择适当的依赖项（也称为可重复构建）。
我相当清楚的一些事情是：
- 修订版
status 应该用于指示该修订版是仅用于开发、已准备好测试还是已准备好用于生产
branch< /code> 属性应该足以处理不同的项目分支
这是我正在努力解决的问题：
如何促进集成构建
假设我在工作区中签出了这些模块：
现在我对模块 a 很满意，并决定使用工作区中签出的版本发布一个里程碑。存储库中需要发生的事情是：
-
e-1.0-RC1 发布
d-1.1-RC2 发布，引用 e-1.0-RC1 > 作为依赖项c-2.0-RC1 发布，引用 d-1.1-RC2 作为依赖项b-3.3-RC1 发布，引用 e-1.0-RC1 作为依赖项- 最后，发布
a-7.1-RC2，引用 c-2.0-RC1 和 b-3.3-RC1 作为依赖项。
如果我尝试自己解决这个问题，我可能最终会做一些工作区管理，ivy.xml find & 。在我打开那罐蠕虫之前，我想得到一些意见。解决这个问题的最佳方法是什么？
Ivy is great for managing dependencies, but it isn't meant to handle the entire software lifecycle across many modules. That said, it does have several features that seem to support it (such as the status and branch attributes), and the ivy best practices blurb alludes to being able to promote integration revisions to milestone or release, "with some work".
Unfortunately I haven't found definitive guidance on how to manage the dev -> test -> deploy cycle. Here are some things I want to achieve:
(Given that devs typically work across many modules in a local workspace)
- Dev can locally publish changes to a module, so that other modules in the workspace can get the updated artifacts.
- Dev can designate a version as "ready to deploy to test" with one command.
- Tester can designate a version as "ready for prod" with one command.
- Dev can rebuild any version from source and the appropriate dependencies are picked up correctly (aka repeatable builds).
Some things I'm fairly clear about are:
- The revision
status should be used to denote whether that revision is meant only for development, is ready for testing, or is ready for production
- The
branch attribute should be sufficient to handle different project branches
Here is what I'm grappling with:
How to promote integration builds
Say I have these modules checked out in my workspace:
Now I'm happy with module a, and decide to publish a milestone using the checked out versions in my workspace. What needs to happen in the repo is:
e-1.0-RC1 gets publishedd-1.1-RC2 gets published, referencing e-1.0-RC1 as a dependencyc-2.0-RC1 gets published, referencing d-1.1-RC2 as a dependencyb-3.3-RC1 gets published, referencing e-1.0-RC1 as a dependency- Finally,
a-7.1-RC2 gets published, referencing c-2.0-RC1 and b-3.3-RC1 as dependencies.
If I try to roll my own for this, I'd probably end up doing some workspace management, ivy.xml find & replace, etc. Before I open that can of worms, I'd like to get some opinions. What's the best way to tackle this?
发布评论
评论（2）
您可以使用递归交付来发布具有更高状态的模块及其依赖项。
使用您的示例：
e-1.0-RC1以integration状态发布d-1.1-RC2以integration< 发布/code> 状态，引用e-1.0-RC1作为依赖项c-2.0-RC1发布时带有集成状态，引用d-1.1-RC2作为依赖项b-3.3-RC1以集成状态发布，引用e-1.0-RC1作为依赖项a-7.1-RC2以集成状态发布，引用c-2.0-RC1和b-3.3-RC1作为依赖项。a-7.1-RC2提升为里程碑状态，因此您进行了递归交付 (使用delivertarget属性）。这将为状态低于milestone的每个依赖项递归调用delivertarget，并以milestone状态发布它。这样做的好处是，您不需要（或希望）在工作区中签出每个项目，只需
a即可。这也意味着创建部署管道并让 CI 服务器变得更加容易：a运行单元测试、a、a作为集成，a部署到系统测试环境，a从集成提升为milestone（促进其依赖项）a到验收测试环境，a从milestone提升到release（这会提升它的依赖关系） ）a部署到生产环境（或将其上传到下载站点）管道在任何时候都不需要访问依赖项目，并且由于递归交付是通用的，因此当您添加或删除依赖项时（通过你的 ivy.xml 文件），你不需要改变管道中的任何内容。
我已将此答案标记为社区维基。还有其他人愿意扩展它或纠正我做错的任何事情吗？
You can use recursive delivery to publish modules and their dependencies with a higher status.
Using your example:
e-1.0-RC1gets published with anintegrationstatusd-1.1-RC2gets published with anintegrationstatus, referencinge-1.0-RC1as a dependencyc-2.0-RC1gets published with anintegrationstatus, referencingd-1.1-RC2as a dependencyb-3.3-RC1gets published with anintegrationstatus, referencinge-1.0-RC1as a dependencya-7.1-RC2gets published with anintegrationstatus, referencingc-2.0-RC1andb-3.3-RC1as dependencies.a-7.1-RC2to amilestonestatus, so you do a recusive delivery (use thedelivertargetattribute). This will recursively call thedelivertargetfor each dependency that has a status lower thanmilestoneand publish it with amilestonestatus.The nice thing about this, is that you don't need (or want) to have each project checked out in your workspace, just
a. This also means that it's much easier to create a deployment pipeline and have your CI server:a,a,aasintegration,ato a System Test environment,afromintegrationtomilestone(which promotes it's dependencies)ato a Acceptance Test environment,afrommilestonetorelease(which promotes it's dependencies)ato production (or upload it to a download site)At no time does the pipeline need to access the dependant projects and, since the recursive delivery is generic, when you add or remove dependencies (via your ivy.xml files), you don't need to change anything in your pipeline.
I've marked this answer as a community wiki. Anyone else care to expand on it or correct anything I got wrong?
你如何做到这一点？：
我计划进行检索和发布。有更好的办法吗？
How do you do the line?:
I was planning on doing a retrieve and publish. Is there a better way?