Showing posts with label CI. Show all posts
Showing posts with label CI. Show all posts

Thursday, 28 May 2009

IVY

One of the things I have been using lately is Ivy.

In the past I have had to use Maven on various projects - and must admit, I hated it. Whilst it might be really trendy at the moment to use "convention over configuration" to me doesn't sit well in a build system. Several times what I've needed to do hasn't fit into the Maven model and I really dislike having to "wedge things in" to appease a tool.

But one thing I did like was the dependency management.

Well Ivy gives you this, without all the other stuff you don't need. You use it from Ant, its clean and easy to manage dependencies, and it leverages the existing Maven repositories.

And something else neat is the ability to bootstrap it from Ant, so you don't have to rely on someone having Ivy already installed, you can install it from within your Ant build and use it on the fly.

What I do is this, create an install-ivy.xml with the following contents:

<project ivy="antlib:org.apache.ivy.ant">
  <property name="ivy.install.version" value="2.1.0-rc1">
  <property name="ivy.jar.dir" value="${basedir}/.ivy">
  <property name="ivy.jar.file" value="${ivy.jar.dir}/ivy.jar">

  <target name="download-ivy" unless="skip.download">
    <mkdir dir="${ivy.jar.dir}">
    <get src="http://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.install.version}/ivy-${ivy.install.version}.jar" dest="${ivy.jar.file}" usetimestamp="true"/>
  </target>

  <target name="install-ivy" depends="download-ivy">
    <path id="ivy.lib.path">
      <fileset dir="${ivy.jar.dir}" includes="*.jar">
    </path>
    <taskdef resource="org/apache/ivy/ant/antlib.xml" uri="antlib:org.apache.ivy.ant" classpathref="ivy.lib.path">
  </target>

  <target name="clean-ivy">
    <delete dir="${ivy.jar.dir}">
  </target>

  <target name="clean-ivy-cache" depends="install-ivy">
    <ivy:cleancache>
  </target>

 </project>
Then in the build.xml I add an:

    <import file="install-ivy.xml">
Then have a target like:

  <target name="resolve" depends="prepare,install-ivy">
    <ivy:retrieve>
  </target>
Then its just a matter of setting up your ivy.xml with your dependencies, which could be something simple like:

<ivy-module version="2.0">
  <info organisation="org.apache" module="hello-ivy">
  <dependencies>
    <dependency org="com.thoughtworks.xstream" name="xstream" rev="1.3.1">
    <dependency org="commons-lang" name="commons-lang" rev="2.4">
    <dependency org="junit" name="junit" rev="4.5">
    <dependency org="org.mockito" name="mockito-all" rev="1.7">
  </dependencies>
</ivy-module>

One of the good things I find is that, I work on a variety of machines, and I don't need to install ivy, my build scripts do it for me as and when.

Tuesday, 31 March 2009

Continuous Integration - Moving beyond the build

So everyone (well I really hope everyone) is now using Continuous Integration of some form or other. However a lot of CI I have seen is purely build, or build and unit-test. This is really under utilising a potentially great resource.

These days developer time is expensive compared to processor cycles. So we need to maximise developer time spent on productive things. Automation can help us do this, and automation starts with CI.

So what can we do to make this a reality?

Firstly consider what tasks do you do repetitively that take up time? Deployments, Integration Tests, Acceptance Tests? What tasks would you do more often but they take too much time? Static Analysis, Performance Tests, Endurance Tests?

But, I hear you say, this takes too much time, we cannot spare that right now.

Well I disagree - the time that you spend now
will pay you back later.

In anything from a few minutes to a few hours you can set up a nightly build, analysis, test cycle could save a whole lot of trouble and which can be incrementally improved to make life easier.

I plan to write some blog posts on how to do this, just need to find the time.