Promoting several modules (integration -> milestone) in ivy

Question

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)

1. Dev can locally publish changes to a module, so that other modules in the workspace can get the updated artifacts.
2. Dev can designate a version as "ready to deploy to test" with one command.
3. Tester can designate a version as "ready for prod" with one command.
4. 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 published
• d-1.1-RC2 gets published, referencing e-1.0-RC1 as a dependency
• c-2.0-RC1 gets published, referencing d-1.1-RC2 as a dependency
• b-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?

Answer 1

You can use recursive delivery to publish modules and their dependencies with a higher status.

Using your example:

• e-1.0-RC1 gets published with an integration status
• d-1.1-RC2 gets published with an integration status, referencing e-1.0-RC1 as a dependency
• c-2.0-RC1 gets published with an integration status, referencing d-1.1-RC2 as a dependency
• b-3.3-RC1 gets published with an integration status, referencing e-1.0-RC1 as a dependency
• a-7.1-RC2 gets published with an integration status, referencing c-2.0-RC1 and b-3.3-RC1 as dependencies.
• Finally, you decide to promote a-7.1-RC2 to a milestone status, so you do a recusive delivery (use the delivertarget attribute). This will recursively call the delivertarget for each dependency that has a status lower than milestone and publish it with a milestone status.

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:

• run unit tests for a,
• build a,
• publish a as integration,
• deploy a to a System Test environment,
• run some System Tests
• promote a from integration to milestone (which promotes it's dependencies)
• deploy a to a Acceptance Test environment,
• run some Acceptance Tests
• promote a from milestone to release (which promotes it's dependencies)
• deploy a to 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?