Great. Thanks. On Aug 11, 2010, at 10:25 AM, Mitch Gitman wrote:
> One best practice, I believe, is to coordinate the > /ivy-module/i...@statusattribute with your environment. The typical > status values are: > integration > milestone > release > > This means that, when you're invoking ivy:deliver and ivy:publish, you're > publishing with the status appropriate for the environment. > > What's more, I would recommend having separate integration, milestone, and > release Ivy repositories and setting up chain resolvers accordingly. This > way, you're ensured that integration artifacts are never creeping into your > release builds. > > Now, in a Subversion world, I normally see a correspondence as follows: > integration = trunk > milestone = branch > release = tag > > So developers and the CI server would normally being hitting an integration > repository (possibly backed up in a chain by milestone and release > repositories), but if you're working on a branch, you'd be hitting a > milestone repo. > > In terms of staging environments like dev, QA, production, I think the > correspondence is roughly the same. Normally, only release builds should be > going into a production staging environment. The key thing to me is that > every publication to the release repo should be a "one and done" for that > particular release. > > Andrew mentions versioning, which is a whole topic unto itself, but which > also needs to be coordinated here. I like the practice where you incorporate > the fact that it's an integration build into the version, like 1.0-DEV or > 1.0-CI or 1.0-SNAPSHOT. But there are other equally valid approaches. > > On Wed, Aug 11, 2010 at 10:13 AM, Andrew McFague <[email protected]> wrote: > >> At my company, we do this using the versions, which makes sense. I.e., >> production may be using 1.0 (because that's the current release), but >> dev may be using 1.1 (because that's the future release). This works >> with branching because, well, its essentially a code change. Current >> ivy.xml points to 1.0, future ivy.xml points to 1.1. >> >> I am not an Ivy expert, but the theory seems sound, and its worked well >> for us. :) >> >> Andrew >> >> On 08/11/10 13:07, Simon Lin wrote: >>> Hi, >>> >>> I wonder what's the best practice to publish artifacts for different >> environments such as dev, QA and production. I tried to use extra >> attribute. But it doesn't seem to work. Or should I just publish to >> different directories on the repository? >>> >>> Thanks. >>
