How do you promote and artifact?

[Aris Green <ar...@gmail.com>]

I have a manually scripted build process using MSBuild for compiling
and Ant + Ivy for publishing and sharing artifacts.  The goal is to
move this in a Jenkins based CI system.  I was wondering, how are
artifacts promoted from snapshots to let say, integration/release?  I
have yet to find much on how this is actually accomplished.  Do you
retrieve the artifacts from one branch into a local folder and publish
them to another.  What are the "best practices".  I am hoping to get
started in the right direction.

Thanks
agreen

Re: How do you promote and artifact?

[Aris Green <ar...@gmail.com>]

We currently have an MSBuild build and began using Ant and Ivy for build
artifact management.  The artifacts are stored in a local file system
repository.  Ivy is used to manage the dependencies between upstream and
downstream build jobs.  We have been moving towards trying to implement
continuous integration with Jenkins and I figured that clean build artifact
management was key.  We didn't want to have to force a the flatter folder
structure used for MSBuild upon Jenkins nor did we want to be copying build
artifacts all over the place from upstream to downstream projects using
scripting.  From what you're saying, it seem that you have builds for
continuous integration that are "integration" builds.  Then you plan a
"milestone" build that may get more attention and that all products would
be build from the same revision in version control.  You would then have
your "release" builds for you're release candidates.

In what you say, I suppose you do not promote (i.e. copy) an artifact out
of integration to let's say milestone.  I had been wondering if, in the IC
methodology, every builds starts out in integration, and then gets
"promoted" to the level of milestone, and then final release, based on
whether all of the tests are passed and the final criteria for release are
met.  This would seem to be difficult to do as in this case, the exact
source revisions of the resultant binaries would differ and this would be
hard to maintain.

I am having some success using ant properties to control the ivy status
(integration, milestone, release).  That way I would not have to copy
entire sets of Jenkins jobs just to change the ivy status.  You're answer
has given me some insight and I appreciate the help.

Thanks
agreen

Re: How do you promote and artifact?

[Mitch Gitman <mg...@gmail.com>]

Since no one else is fielding this question just yet, I'll go ahead. Ivy
has three predefined statuses, where the status attribute appears
/ivy-module/info in an ivy.xml file:
integration
milestone
release

Even though Ivy in no way enforces this, the presumption is that the
integration status represents snapshot or, well, integration
versions—builds of a version that is still under development. The milestone
and release statuses represent one-off builds. Once you build version
1.0-beta1 with milestone status, you aren't going to overwrite it with
another 1.0-beta1 version, unless you do some kind of special in-house
demotion. Once you build version 1.0.0 with release status, you're not
going to produce another 1.0.0; the next release will be 1.0.1. The
milestone and release modules should be built off tags in your SCM system.

You're welcome to define your own statuses, but it's still advisable to
make a sharp distinction between integration versions and non-integration
versions. It's also advisable to bake the fact that we're talking an
integration version into the the literal version and not just rely on
status="integration". Sticking a suffix in the version, like 1.0-SNAPSHOT
or 1.0-timestamp or 1.0-buildnumber (not unlike what Maven does), is the
typical way to do this. There's a longer discussion about reproducible
builds which I'll spare you.

Now, suppose you have a release branch where you're preparing a release.
You'd create a Jenkins job for this branch, and you'd make it publish to
your enterprise artifact repository with status="integration". As you go
along in the development of this branch, you'd weed out all the
dependencies on integration (i.e. snapshot) versions of other modules. Then
when you finally tag a milestone or release in source control, you would do
a one-off build that publishes the Ivy module and its artifacts to the
enterprise repository with status="milestone" or status="release" and the
integration suffix stripped from the version string (revision="…" in the
ivy.xml). Whether you create a Jenkins job to do this and do it from a
shell shouldn't make a difference in terms of what gets published although
at least with Jenkins you can take advantage of the reporting. At this
point you should  lock the job so that it doesn't build again (don't recall
offhand how you do this). The job becomes effectively a historical document.

Trying to capture some best practices here, but certainly Ivy will give you
plenty of rope with which to hang yourself.

On Thu, Dec 27, 2012 at 6:38 PM, Aris Green <ar...@gmail.com> wrote:

> I have a manually scripted build process using MSBuild for compiling
> and Ant + Ivy for publishing and sharing artifacts.  The goal is to
> move this in a Jenkins based CI system.  I was wondering, how are
> artifacts promoted from snapshots to let say, integration/release?  I
> have yet to find much on how this is actually accomplished.  Do you
> retrieve the artifacts from one branch into a local folder and publish
> them to another.  What are the "best practices".  I am hoping to get
> started in the right direction.
>
> Thanks
> agreen
>