Hi,
I've just started using ivy and read the following on the best practices page:
---
Imagine you have a customer which comes on a monday morning and asks your
latest version of your software, for testing or demonstration purpose.
Obviously he needs it for the afternoon :-) Now if you have a continuous
integration process and a good tracking of your changes and your artifacts, it
may occur that you are actually able to fulfill his request without needing the
use of a dolorean to give you some more time :-) But it may occur also that
your latest version stable enough to be used for the purpose of the customer
was actually built a few days ago, because the very latest just break a feature
or introduce a new one you don't want to deliver. In this case, you can deliver
this 'stable' integration build if you want, but be sure that a few days, or
weeks, or even months later, the customer will ask for a bug fix on this demo
only version. Why? Because it's a customer, and we all know how they are :-)
So, with a build promotion feature of any build in your repository, the
solution would be pretty easy: when the customer ask for the version, you not
only deliver the integration build, but you also promote it to a milestone
status, for example. this promotion indicates that you should keep track of
this version in a long period, to be able to come back to it and create a
branch if needed.
Unfortunately Ivy does not by its own allow to have such reproducible builds
out of the box, simply because Ivy is a dependency manager, not a build tool.
But if you publish only versions with a distinct name and use Ivy features like
versions constraint replacement during the publication or recursive delivery of
modules, it can really help.
---
What I have in place already is a build system which publishes the artifacts
and a resolved ivy file to a repository. Version identifiers for those builds
are generated (the default date time pattern provided by ivy). Builds are
started automatically whenever a commit is performed or a developer starts the
build manually on the build server. Developers take a look at the build results
and, in case they want to release a build, send a release request (mail) to
another department within our company. There the build will get checked and
might get approved. In case a build gets approved, I want to somehow update the
ivy file in the repository to: 1) use the correct revision provided on qa
approval step 2) change the status from integration to release. I guess that is
exactly what is meant by "promote a build" in the text above.
My question is now how to actually promote a build. What I already thought of
is writing some scripts to update the XML file, but those scripts would be
dependent on the actual file system structure of the repository, which I want
to prevent if possible. Are there any ivy tasks to do such a thing? I found an
ivy task called "install" which is performing a very similar work... I thought
of using it with the same resolver set as source and target, but there are no
attributes to update the revision and status properties of an ivy descriptor
during the install process...
Any help would be appreciated.
Regards,
Dominik
Dominik Bieringer | Internal Tools & Test Automation | GoldenSource Corporation
| Skype: dominik.bieringer | T: +43 7229 76656 44 |
[email protected]<mailto:[email protected]> |
www.thegoldensource.com<http://www.thegoldensource.com>
