Posts Tagged ‘Ant’

Continuous Integration for Agile Project Managers (Part 1)

March 30, 2010

Any Agile Project Manager worth his salt should be aware of the term ‘Continuous Integration’ (often shortened to ‘CI’). But what is it, and how is it done?

This series of short blog articles aims to answer these two questions, so you can start your next project, or re-configure an existing project, armed with the necessary understanding about this key practice within agile software delivery.


The basic premise of CI is pretty straightforward. An agile team needs a repeatable and reliable method to create a build of the software under development. Why so? Well, if its not already obvious, you may want to revisit the principles behind the Agile Manifesto. Within them you will notice a number of references to ‘working software’, and the foundation of any working software is a stable, tested build.

Recipe for CI

So how does CI help to create this build? Lets list the essential ingredients that we need :

  1. Source Code Control – in a typical agile project, developers turn User Stories into source code, in whatever programming language(s) the project is using. Once their work is at an appropriate level of completeness, they check-in or commit their work to the source code (a.k.a version) control system; for example, Subversion
  2. Build Tool – if the source code needs to be compiled (e.g. Java or C++) then we will need tooling to support that. Modern Integrated Developer Environments (IDE), such as Eclipse or Visual Studio are able to perform this task as developers save source code files. But if we want to build the software independently of an IDE in an automated fashion, say on a server environment, we need an additional tool to do this. Examples of this type of tool are Ant, Maven and Rake and Make. These tools can also package a binary output from the build. For example, with Java projects this might be a JAR or WAR file – the deployable unit that represents the application being developed.
  3. Test Tools – as part of the build process, in addition to compilation and the creation of binary outputs, we should also verify that (at minimum) the unit tests pass. For example, in Java these are often written using the JUnit automated unit testing framework. The tools in (2) often natively support the running of such tests, so they should always be executed during a build. In addition to unit testing, there are numerous other quality checks we can perform and status reports CI can produce. I’ll cover these in detail in a subsequent part to this series.
  4. Schedule or Trigger – we might want to create our build according to a schedule (e.g ‘every afternoon’) or when there is a change in the state of the project source code. In the latter case we can set up a simple rule that triggers a build whenever a developer changes the state of the source code by committing his/her changes, as outlined in (1). This has the effect of ensuring that your teams work is continuously integrated to produce a stable build, and, as you may have guessed, is where this practice gets its name from.
  5. Notifications – the team needs to know when a build fails, so it can respond and fix the issue. There are lots of ways to notify a team these days – instant messaging, Twitter etc, but the most common by far is still email.
  6. Continuous Integration Recipe

    Continuous Integration Recipe

    The tool that wires these five elements together is a Continuous Integration Server. It interacts with the source control system to obtain the latest revision of the code, launches the build tool (which also runs the unit tests) and notifies us of any failures. And it does this according to a schedule or state change based trigger. A CI server often also provides a web-based interface that allows a team to review the status, metrics and data associated with each build.

    CI Server options

    There is a pretty overwhelming choice of available tools in this space. Some are open source, some proprietary. I don’t have time to go into all the available options here unfortunately. However, there is a handy feature comparison matrix available here. Of course, it would be remiss of me not to mention our own hosted service, which allows you to get started with CI in no time at all, without having to be an ‘expert’ user.

    Mike Test Reports

    Test Reports generated by Mike

    In the next part of this series, I’ll delve deeper into how you can use CI to enforce software quality within your team during the various stages of the development process.

New Mike Release with GitHub integration and Functional Testing support

March 18, 2010

We are very pleased to be able announce a new release of our hosted CI platform. The release includes some major enhancements to allow our users to do much more with their builds while at the same time ensuring that they happen within a highly secure, controlled environment.

Here is summary of the new features:

CI support for projects hosted within public or private GitHub repositories that use Ant, Maven or Eclipse.

Each build is now executed in an entirely separated environment, which allows our users to:

  • Start, stop and deploy to embedded containers as part of their build process (e.g. Jetty or Glassfish).
  • Start, stop and deploy to provided (by Mike) instances of Apache Tomcat (v5 and 6) as part of their build process.
  • Run integration and functional tests, using frameworks such as HtmlUnit or JWebUnit against applications deployed to said containers or instances.
  • Fork additional processes as part of a build, such as bash scripts and other non-Java based tooling.
  • Use the full range of available Ant tasks and Maven plug-ins as part of a build.

Security hardening:

  • All network communication within Mike is encrypted using either key or token-based authentication.
  • All outbound network access from a build is transparently proxied and validated.
  • IP protection: all builds run in a clean, repeatable sand-boxed environment and all source code processed by a build is accessed using token-based authentication over encrypted channels. See the security section of our website for further details


  • Support for Maven Ant Tasks (v2.1.0) – Ant-based projects can now use Maven dependency management for their binary artefacts.
  • Gravatar integration for developer email addresses.

Be sure to check out our no-obligation, 14-day trial. You simply need to provide us with your company/project name and an email address. You can also use our sample applications to rapidly get started and experience our platform features. Our prices start from only $10 per month.

Announcing our Pricing Plans

February 12, 2010

We are pleased to announce that our commercial plans are now available! There are three options:

  • Solo plan, which costs $19 per month. This is, at it sounds, targeted at teams (of up to 5) working on a single project.
  • Multi, $49 per month, includes support for Maven builds and up to 5 projects/10 users
  • Plus, $99 per month, with the same build tool support as Multi but up to 20 projects/30 users

We provide a no-obligation, 30-day trial.You simply need to provide us with your company/project name and an email address. All payments will be securely handled via PayPal should you subsequently wish to sign-up with us.

Please take a look at our pricing page for full details.

A chilly chat with the Build Doctor

December 18, 2009

Last week the Mike team travelled to London for the Mike & UPCO Christmas party. Before the festivities started we caught up with the Build Doctor in the Cheshire Cheese pub near the Temple. After a nice pint in the cosy pub,  Adam did a short alfresco interview, in the not so warm Temple. You can see it here. Enjoy!

Eclipse Metadata Redundancy and Build Tools

November 10, 2009

As this recent blog post and subsequent discussion illustrates, the choice of build tool for Java projects can still provoke furious debate. As a long time user of both Maven and Ant, I’d like to think I have a good perspective on the various pros and cons of both of them. In fact, this perspective led to the creation of Kundo, an alternative open source build tool that sought to scratch both mine and others particular build management itches.

To use either Ant or Maven in anger you need a decent level of experience and understanding – particularly in the case of Maven. I’ve always viewed Maven as a ‘platform’ rather than a simple build tool as it aggregates/conflates a great many features. This means that the learning curve can be quite steep. I often encounter less experienced Java developers who wonder why working with these tools is so problematic – why do they need to contact the designated ‘build guy’ (or girl) when things don’t go according to plan?

More Data Than We Need?

lots of data!

Those who are familiar with the build tool domain will be aware of the ‘impedance mismatch’ that can occur between the metadata model used by Eclipse and that used by Ant, and especially Maven. In the case of Maven, this is because a POM file effectively needs to be the ‘master’ for project dependency metadata. Both the maven-eclipse-plugin and m2eclipse are good tools that seek to address this problem but I think its fair to say neither have yet completely eliminated the fundamental underlying issue. With Ant, the metadata synchronisation is simpler, but it still requires awareness from developers and they often have to be comfortable with Ant references and simple types to ensure changes in the IDE do not break the Ant build. Often Ant builds these days use either Ivy or the Maven Ant Tasks for dependency management anyway, so the problem can be much the same as with vanilla Maven in these types of projects. It is often not clear what the canonical metadata format should be and which tool ‘owns’ it.

Before I continue it is important to stress that I am focusing here solely on Eclipse, not alternatives such as NetBeans, IntelliJ etc that seek to address the problem in different ways.

Part of our mission with Mike is to lower the barrier of entry to using Continuous Integration (CI), so we have sought to include features that mean you don’t need to be a build tool guru to use our platform. Our ‘Eclipse build’ feature is a great example of this. It allows developers to simply add an Eclipse project to our hosted CI service without the need for an associated build.xml or pom.xml file. Then, at build time, Mike parses the project metadata and uses this within a vanilla life-cycle that processes resources, compiles production and test code, runs JUnit tests and creates an appropriate artefact. There are some constraints and conventions that need to be applied with this approach – at the time of writing the feature only supports the Dynamic Web project type using Apache Tomcat 5.5 or 6.0 runtimes – but here at Mike HQ we feel it allows you to be up and running with CI in very short order and we will be seeking to extend the range of project types, natures, builders etc that are supported. Of course, should you wish to subsequently own greater control over your CI build you can always add the appropriate Ant or Maven configuration at a later date and Mike will build that too.

From a pure CI perspective, this may seem to contravene the suggested approach in Martin Fowler’s original article – specifically the statement about IDE data being ‘fragile’. However, if all your developers are using a standardised version of Eclipse and apply a sensible approach to modifying the state of a project, many of the supposed issues can be avoided.

Aside from the Maven-specific tools mentioned above, it’s only fair to point out that there are other open source initiatives and projects that seek to address this same problem. In Kundo we sought to provide a ‘pluggable’ dependency management solution with one option allowing the use of Eclipse metadata as the source of your binary dependency locations. For this feature Kundo delegates to ant4eclipse. The aim of the ant4eclipse project is to avoid (or at least to reduce) the redundancy of Eclipse and Ant configurations and it consists of Ant tasks that are able to parse Eclipse metadata. More recently, the headlesseclipse project has emerged which seeks to solve the same problem by using the built-in AntRunner of Eclipse.

Finally, there is the B3 project proposal from the Eclipse community itself which, in their own words, has a goal to “develop a new generation of Eclipse technology to simplify software build and assembly”. I will be closely watching that proposal with interest to see if it finally addresses the build management metadata redundancy/synchronisation issue with Eclipse.

Beta launch week

October 23, 2009

It’s been an exciting week at Mike HQ this week. Announcements for the Beta have gone out on the ServerSide and the JavaLobby. We’ve also had a few enquiries and, of course, sign-ups! People are now building their projects on our platform! It’s a very exciting time for us. We hope our beta users enjoy using the platform and we’re really looking forward to the feedback.

Maven2 support is a feature a number of people have asked us about.  It is something we are working on and we’ll keep you posted as to when we will add it to the Beta programme. It’s a key feature for the platform.

We’ve also started work on the Mike registration and account management application, agreeing the screen-flows, designs and functionality. This should give users a seamless registration process and the ability to add and remove users from their Mike account. We’ve also been extending the coverage of our Selenium tests for Mike and adding them to our nightly build cycle.

Have a good weekend!

Beta launched!

October 20, 2009

I’m very happy to announce that the we are ready to launch the MikeCI private beta. We’re doing a limited private beta for a number of reasons. Firstly, we want feedback on the platform. This is a great chance for people to get on board early and try our service out and let us know what they like or don’t like. We hopefully get great feedback and you get a free CI Server!

We’re also keen to ensure we can handle the stresses and strains of lots of people running build jobs. Doing this under a private beta allows us to add users in a controlled manner and double check everything is working as it should be before we go live. Finally the beta allows us to bed down our support and admin processes before a full launch. We’re not like Google – this beta period is limited to the end of November, so please get in touch soon if you want to sign up.

Announcements will be going out this week on various sites. Please say if you want to take part.