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, referencinge-1.0-RC1
as a dependencyc-2.0-RC1
gets published, referencingd-1.1-RC2
as a dependencyb-3.3-RC1
gets published, referencinge-1.0-RC1
as a dependency- Finally,
a-7.1-RC2
gets published, referencingc-2.0-RC1
andb-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?