ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Lin <noise...@gmail.com>
Subject Re: Looking for suggestion on publishing artifacts for different environments
Date Wed, 11 Aug 2010 20:43:00 GMT
Great.  Thanks.

On Aug 11, 2010, at 10:25 AM, Mitch Gitman wrote:

> One best practice, I believe, is to coordinate the
> /ivy-module/info@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 <amcfague@wgen.net> 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.
>> 


Mime
View raw message