ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Sahlbach" <andreas.sahlb...@gmail.com>
Subject Re: Build promotion?
Date Thu, 04 Jan 2007 00:15:12 GMT
Hm, I have a different opinion here, but I think, this is a matter of
taste. I prefer to build a webapp once, then test it and then deploy
the very same artifact that I have successfully tested to the
production environment. Out webapps are independent from their
location, getting most configurations from the jndi environment, so
why taking a risk and do a new build just for promoting? Yeah sure, my
build should guarantee that the builds will produce the same
artifacts, but why taking a risk? This way the deployment is done just
by promoting and a little bit of file copy and server restart.

So I like build promoting and here is, what I am doing:

1) Our staging goes like this: development - integration - qs - productive

2) in my ivyconf, I have this
<?xml version="1.0" encoding="utf-8"?>
<ivyconf>
...
    <statuses default="development">
        <status name="productive" integration="false"/>
        <status name="release" integration="false"/>
        <status name="qs" integration="false"/>
        <status name="milestone" integration="false"/>
        <status name="integration" integration="false"/>
        <status name="development" integration="true"/>
    </statuses>
...
   <resolvers>
        <filesystem name="install">
            <artifact pattern="${user.home}/.ivy/install/[artifact].[ext]"/>
            <ivy pattern="${user.home}/.ivy/install/[artifact].[ext]"/>
        </filesystem>
   </resolvers>
</ivyconf>

3) in my common ant script, I have this:
    <macrodef name="change-status-macro">
        <attribute name="fromstatus"/>
        <attribute name="tostatus" />
        <sequential>
            <delete dir="${install-rep}"/>
            <mkdir dir="${install-rep}"/>
            <ivy:install from="umsrep"
                         to="install"
                         organisation="${ivy.organisation}"
                         module="${ivy.module}"
                         revision="latest.@{fromstatus}"
                         overwrite="true"/>
            <delete>
                <fileset dir="${install-rep}" includes="ivy.xml.*"/>
            </delete>
            <groovy>
                import org.dom4j.*
                import org.dom4j.io.*
                File ivyFile = new File(properties['install-rep'],"ivy.xml")
                Document ivyDoc = new SAXReader().read(ivyFile)
                def xpathSelector =
DocumentHelper.createXPath("/ivy-module/info[@status='@{fromstatus}']")
                xpathSelector.selectNodes(ivyDoc).each() {
                    ((Element)it).addAttribute("status","@{tostatus}")
                    OutputFormat outformat = OutputFormat.createPrettyPrint();
                    XMLWriter writer = new XMLWriter(ivyFile.newOutputStream());
                    writer.write((Document)ivyDoc);
                    writer.flush();
                }
            </groovy>
            <ivy:install from="install"
                         to="umsrep"
                         organisation="${ivy.organisation}"
                         module="${ivy.module}"
                         revision="latest.@{tostatus}"
                         overwrite="true"/>
        </sequential>
    </macrodef>

    <target name="promote-development" depends="configure,resolve"
            description="Pushes the latest.development version to
integration status">
        <change-status-macro fromstatus="development" tostatus="integration"/>
    </target>

    <target name="promote-integration" depends="configure,resolve"
            description="Pushes the latest.integration version to qs status">
        <change-status-macro fromstatus="integration" tostatus="qs"/>
    </target>

    <target name="promote-qs" depends="configure,resolve"
            description="Pushes the latest.qs version to productive status">
        <change-status-macro fromstatus="qs" tostatus="productive"/>
    </target>
4) install-rep is a simple directory
<property name="install-rep" value="${user.home}/.ivy/install"/>
which is also defined as a repository (see above)

I had to simplify the script a bit, but it should give you an idea how
to do it. The targets configure and resolve do the ivy tasks that you
expect.

Some support in ivy itself for it would be nice too, but it actually
works pretty well this way. Once again groovy saved my day... :)

Hope that helped a bit,

ciao,

Andreas

On 1/3/07, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> On 1/3/07, John Williams <jrw@pobox.com> wrote:
> >
> > I read about to idea of build promotion at
> > <http://www.jaya.free.fr/ivy/doc/bestpractices.html>, but I can't find
> > any documentation on how to actually do it.
>
>
> As I say on this best practices page, Ivy does not support build promotion
> on its own, because build promotion is a complex thing that is not only
> related to module and dependency management. For instance you will certainly
> need to tag the sources that were used for your build if you promote it.
>
> Is the best way just to
> > manually edit an Ivy file in the repository to change the status
> > declaration?  That sounds easy enough, but the presence of the
> > checksum files in the repository makes me think that editing the ivy
> > files after the fact is frowned upon.
>
>
> I don't think that editing the ivy file is a good thing. I think that a
> revision should never change. So in my opinion a build promotion needs to be
> a new version. And in this case  you don't have to modify a file, you just
> publish a new version, and state somewhere (maybe in your ivy file in the
> description section) that it is simply another build which has been
> promoted.
>
> Ivy has no particular support for build promotion, the only thing is that
> Ivy helps in build reproducibility, and it's a good basis for build
> promotion. But setting up a build system supporting build promotion is not a
> trivial task IMO.
>
> Xavier
>
> Alternatively, does anyone have experiences to share with "snapshot"
> > revisions?  My understanding is that every snapshot revision should
> > eventually be replaced by a non-snapshot revision that is identical to
> > the last snapshot, but then what happens to the snapshot revision?
> > Does it just get deleted?  Or do you keep two identical revisions with
> > different numbers?
> >
> > --jw
> >
>
>



-- 
Andreas Sahlbach

Mime
View raw message