ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: How to promote a set of artifacts
Date Thu, 05 Feb 2009 16:37:03 GMT
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>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message