ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: ivy promotion levels?
Date Wed, 29 Jul 2009 14:19:51 GMT
Shawn, from what I've seen and heard, I would say that #1 above is a bare
minimum but #2 above is also recommended. However, I would rephrase #2 from:
"set up separate resolvers so that each promotion level has its own top
level directory such that promoting a module from one level to the next is
less about ivy statuses but more about copying modules between different top
level directories"

To:
"set up separate resolvers so that each status level has its own Ivy
repository such that promoting a module from one level to the next is less
about ivy statuses but more about either the CI server automatically or the
build engineer manually publishing modules to different Ivy repositories"

The general idea of having different Ivy repositories for different
publication statuses is that you're ensured that, simply by using one
resolver and not another, you're not going to have any pre-release Ivy
modules intermingling with your release Ivy modules.

Also, it's not a matter of copying between repositories. It's a matter of
configuring different ivy:publish task invocations to use one resolver and
one publication status as opposed to another.

I would add an optional #3 here to the process of promoting a module, and
that is to change the version on it. But that really ties into (A) your own
team's versioning practices and (B) how they integrate with your source
control system. For example, to follow the Subversion convention of
trunk/branches/tags, you could do all your 2.0 development on trunk with an
integration status and then when you're really for the alpha version, create
a 2.0_alpha branch and give your module a version 2.0_alpha with a status of
either integration or release. Once 2.0_alpha is ready for release, you tag
it and, if you haven't already, give it release status.

On Tue, Jul 28, 2009 at 10:24 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:

> Is there a good description of the promotion level concept generally
> speaking and then a good description of how promotion levels and IVY work
> together?  I can see that IVY statuses are essentially promotion levels, but
> I am looking for best practices in implementing them.  For example, I can
> see two methods of promoting a module:
>
>
> 1.       change the published ivy.xml status attribute from one level to
> the next (can use the xmltask to do this in place within ANT)
>
> 2.       set up separate resolvers so that each promotion level has its own
> top level directory such that promoting a module from one level to the next
> is less about ivy statuses but more about copying modules between different
> top level directories
>
> I currently have two promotion levels:
>
> development
> release
>
> However, I am using #2 method above where I don't use the ivy status
> attribute but just use the ivy:install task to transitively copy modules
> from the development resolver to the release resolver.
>
> I would like to add two more statuses:
>
> development (build successful)
> testing (means all unit tests have passed)
> integration (means the final app module has been smoke tested with real
> world workflows and passed)
> release (RTM)
>
> I am just looking for a general description of this concept and some best
> practices in its implementation with IVY.  Thanks for any help.
>
> ---
> Shawn Castrianni
>
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly prohibited.
>  If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message