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 < [email protected]> 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. >
