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: Looking for suggestion on publishing artifacts for different environments
Date Wed, 11 Aug 2010 17:25:21 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message