You are viewing a plain text version of this content. The canonical link for it is here.

Posted to ivy-user@ant.apache.org by "Bieringer, Dominik" <db...@thegoldensource.com> on 2009/02/05 15:05:02 UTC

How to promote a set of artifacts

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

Re: How to promote a set of artifacts

Posted by Mitch Gitman <mg...@gmail.com>.

When I think of "promoting a build," I think of preparing a release. And
when I think of preparing a release, it's hard not to think of it in terms
of the version control system I'm using. Suppose I'm using Subversion and
I'm using the typical Subversion single-project layout:
* branches
* tags
* trunk

To use an example, my team might be developing a project called superportal
1.0 in trunk. The Ivy file might specify:
organisation="com.mycompany" module="superportal" revision="1.0"
status="integration"

Whenever my team does an *ivy:publish *in the course of developing that,
they publish with status="integration" to:
* com.mycompany
    * superportal
        * 1.0

Now when I want to prepare a release, I create a branch. Maybe call it 1.0.0
or 1.0-rc1. But, by convention, *I'm calling it something different from
just 1.0*. In the Ivy file for the branch, the revision will now be that
different revision.

Whenever my team does an *ivy:publish *on this branch, they will publish
with status="milestone" or status="release". Now that will publish *to a
different location*:
* com.mycompany
    * superportal
        * 1.0.0

Of course, whenever I'm finally happy with that release, I'll create a tag
for it. The Ivy file for that tag should specify status="release".

Warning: I could be getting a few details wrong in the specifying of the
status in the module Ivy file or for *ivy:publish*. Also note that I'm
glossing over the detail of having to recursively branch every dependent
in-house module in a release.

On Thu, Feb 5, 2009 at 6:05 AM, Bieringer, Dominik <
dbieringer@thegoldensource.com> wrote:

> 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 |
> dbieringer@thegoldensource.com<ma...@thegoldensource.com> |
> www.thegoldensource.com<http://www.thegoldensource.com>
>
>