Ivy is a flexible tool and also the release process can be tuned according
to your own needs.

Personally, I think that you should not try to copy the  "release process"
used in the maven world.
I believe more in a continuous build process where builds are promoted to
releases when they have been properly tested.
A binary repository manager such as Artifactory can help with this.

Here is the build and release process that I propose for Ivy:

In the SCM system, dependencies to modules which are part of your
"build-project" always have a dynamic revision (latest.integration).
Dependencies to modules which are not part of the build-project are
specified with a fixed revision.

During the continuous build process, a "resolved" module descriptor (aka
ivy-file) is published to the binary repository manager. A "resolved"
ivy-file means there are no dynamic revisions in it. The related commit in
your SCM system is tagged with the name of the build. The status of the
resolved ivy-file is "integration".

When a build has to be released (according to appropriate own test and
acceptance criteria), the resolved module descriptor is retrieved from the
binary repository manager, its status is changed to "released", and the
module descriptor is published to a "release" repository. Depending on your
needs, you can do the same with all its dependencies (the exact revisions
are available in the published ivy-files). The corresponding build artifact
is then promoted in the binary repository manager. If you are using Git,
you can then merge the associated tagged commit into the release branch
(this should be a simple forward merge, or else something is messed up in
your branching tree).  Additionally, you can also tag your SCM-system with
the actual release name of your product. That would be the end of the
release process.

* This process implies that your binary repository manager is as important
for your build and release process as the SCM system. So it should be
protected appropriately. It is also usefull to setup a batch job to scrub
build artifacts which haven't been promoted within a specific timeframe
(e.g. one month).
* Because builds and tests are done prior to the release process and not
afterwards, this release process is much lighter than the maven release
process.

I am also curious how other people make their releases with Ivy. So feel
free to comment and propose alternative release process.

Regards,
Marc




2017-01-23 20:02 GMT+01:00 <michael.fitz...@bmw.de>:

> We are searching for a best practice documentation about the release
> process of an IVY module like described here [1]. For us it is quite
> important to produce reproducible builds with all dependencies of the
> release build. For that, we have to push the resolved IVY descriptor in the
> SCM system and create a tag. Does anybody know how this could be achieved
> with the IVY system?
>
> - Resolve dependencies
> - Commit descriptor to the SCM system
> - Checkout source from the tag
> - Do release build and test
> - Publish module artifacts
>
> Thanks
> Michael
>
> [1] Maven release process of modules
>       http://maven.apache.org/maven-release/maven-release-plugin/
> examples/prepare-release.html
>

Reply via email to