Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (nike.apache.org: domain of mgitman@gmail.com designates
 64.233.182.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=joncN5cHfmjCPeX6RDTHHqoY5emLDEDDGzxVj5/ntcPQjUlHs3jwPZsBHkW6Gi3csb
         awZarwAYVQ48PBapXthyLUwzuJ6Nn6rCoUFLevHE6oH1BAuoK6GTvKmsACLHBfC80u9h
         9/G1IlgJ0INTzsWwV/RvVG9ca1Ph3wOFtkh80=
MIME-Version: 1.0
In-Reply-To: <6CE22786EBF2FB4DA38C65DA76CA60D61F00FF3158@atex01.gsc.zz>
References: <6CE22786EBF2FB4DA38C65DA76CA60D61F00FF3158@atex01.gsc.zz>
Date: Thu, 5 Feb 2009 08:37:03 -0800
Message-ID: <7916a6a60902050837x67ace8ddrbe1d1b3cfb3126ef@mail.gmail.com>
Subject: Re: How to promote a set of artifacts
From: Mitch Gitman <mgitman@gmail.com>
To: ivy-user@ant.apache.org
Content-Type: multipart/alternative; boundary=0015174be26a9f0ee704622e8319

--0015174be26a9f0ee704622e8319
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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

--0015174be26a9f0ee704622e8319--