Each day we decide what to do next based on factors like the weather prediction and interesting places to visit, which we often discover while we are traveling. The nights we spend at special motor home parking lots or campgrounds, depending on availability and our needs like electricity or a hot shower. We usually only spend one day at a place, sometimes two if we have to do the laundry or are tired of driving. This all reminds me a lot of agile software development. When we travel we have a general road-map, one or two day iterations, retrospectives in the evening and the presentation you can soon see on our travel blog and Flickr. If necessary we completely adjust our plans and change course. During this vacation we switched from the Mediterranean to the Atlantic coast because of the weather prediction. A drastic change in course but it also gave us the chance to see new interesting areas where we have not been before.

The flexibility also has a price. The unexpected is often positive and a surprise but sometimes also negative and one has to deal regularly with uncertainty and problems. The alternative would be a fully planned and organized vacation, as so many tour operators are offering them for a lot of money. In the past we have rented an apartment somewhere for the length of the vacation and explored the region around it. Sometimes we returned early as the weather turned bad, or we had seen everything and didn’t feel like staying in the apartment, which was not as nice as our own home.

In spite of some nasty problems on the last tour, I prefer agile traveling, just as I still believe in agile software development. It is not always easy and fun but in the end the result is likely to be better.

Bookmark It

We found a working solution in a combination of a custom Ant plugin for Maven, Maven as build tool, shell scripts and Luntbuild. It took us quiet a while to figure it all out and get it right, but now we are deploying multiple versions each night and can also trigger deployments manually. In this post I am going to show how we solved it.

1. Ant Plugin for Maven
We were not able to find existing Maven plugins for the tasks of copying, unpacking and remotely managing applications, so we decided to write our own Ant Plugin for Maven, which allowed us to use tasks like sshexec and scp.
The plugin basically only needs 3 files: an 
ant build script, a mapping document and of course Maven’s POM. The image below shows the Eclipse project for the plugin.

The ant script rollout.build.xml performs tasks like SSH commands and SCP and accepts various parameters, which allow us to use it in a very flexible way. In the code example below, you can see two targets, one for the web applications and one for the daemon processes.

In order to use the ant script, a mapping document has to be created to tell Maven how to use our plugin.

Because we use SSH/SCP, ant-jsch and jsch have to be added as dependencies to the pom.xml of the plugin. Here we also specified the more user-friendly prefix ‘rollout’, so that we can reference our new plugin with rollout:daemon and rollout:webapp. Don’t forget to update settings.xml when using the prefix.

If you want to to execute the script automatically as part of one of the Maven lifecycles, you can add the plugin to the pom.xml of your project as described in the Guide to Developing Ant Plugins. Originally we used the ’site’ lifecycle to create the project sites and deploy the application as well but that slowed the deployment process down too much. Sometime you want to be able to release a new version as fast as possible.

2. Shell scripts for starting/stopping applications
On the test server we are using standard shell scripts to manage the applications. Just as the ant script, these shell scripts accept various parameters, so we can use them for multiple deployments.

3. Luntbuild

In Luntbuild – an open source build automation and management tool – we bring the loose ends together and configure the dynamic parameters for the build and deployment process. The project/scheduler concept of Luntbuild combined with a series of builders make it easy to handle multiple versions of our software.

For the nightly deployment on trunk we use a schedule (screenshot below), which first builds the project (clean install) and then post-build process will setup a database on the test server and deploy all 9 applications.

The builder then uses Maven to execute the deployment goal of our plugin and provides the necessary parameters. As you can see, it is possible to pass parameters from the schedule to the builder and this way it is possible to re-use the builder in many ways. Unfortunately it is not possible to share builders between projects in Luntbuild.

Conclusion

With this workflow we were able to achieve our goal. Deployment is now part of our continuous integration system. Every night each release which is in development is automatically being deployed to our test servers and if necessary we can manually start deployments during the day. All of this saved a lot of time and trouble. It is a very flexible and expandable solutions but the flexibility also added some complexity.

What is missing now are the setup and configuration steps for the test systems and databases. At the moment there are still some manual steps necessary to get a new deployment environment ready.

Bookmark It

Also many talks were quiet full, which according to my experience doesn’t contribute to deep discussions and exchange of thoughts. In large groups typically some and often the same people stand out and dominate the discussion with their opinion, while in a smaller group it is usually more balanced.

So my conclusion is, that also here less is more. A smaller conference might make it more difficult to find sponsors but on the other hand costs would also be much lower. The alternative could be to expand the conference in space and time but then costs would go up. Personally I would rather have a small conference each quarter than one or two large ones per year. 50-60 seems to be a good number of participants for open space conferences.

Bookmark It

The participants were just as diverse and that made it special compared to other conferences. There were developers, project managers, product owners, consultants and people from various management positions, all involved in active discussions and exchange of experiences.

Geographically we didn’t quiet reach all of Europe – four people came from Belgium, one from Germany, one from India and the rest from the Netherlands. Harish from India, who is studying in Edinburgh (Scotland) used the occasion to interview some of us for his theses on Agile software development.

Click here to see a slideshow with some of my photo’s of Agile Open Europe 2008.

Upcoming conferences:
Agile 2008, 4 – 18 August, Toronto, Canada
XP Days Benelux 2008, November 20 – 21, Eindhoven, The Netherlands
CITCON Europe 2008, October 3 & 4, Amsterdam

Bookmark It

Jeffrey Fredrick and Paul Julius, on behalf of the Open Information
Foundation, are pleased to announce CITCON Europe 2007 will be held in
Brussels on October 19 & 20. CITCON is free to attend.
CITCON (Continuous Integration and Testing Conference) brings together
people from every corner of the software development industry to discuss
Continuous Integration and the type of Testing that goes along with it.
They just wrapped up CITCON Sydney at the end of July. Everyone really
enjoyed themselves and learned a lot. It was the largest CITCON event,
yet. They are hoping to make CITCON Brussels even larger.
If you would like to register for CITCON, please visit the website.
http://citconf.com/brussels2007
http://citconf.com/brussels2007/register.php
If you have any questions, please feel free to contact CITCON at info at
citconf dot com. I hope to everyone can make it to CITCON Brussels in
October!

As developer and Scrum Master I have been more and more involved with continuous integration and automated testing this year. I registered for the conference as I feel that it would be good for me to learn more about this area. It will also be my first Open Space conference.

Bookmark It

Next, they went on showing us the Ruby On Rails (ROR) and Grails frameworks and of course demonstrated the fast creation of a simple working web-application (those famous 10 minute demos). If you want to know more about it, just follow the links, read the introduction and watch the screencasts.

Both Grails and Rails (when used with JRuby) allow integration with Java and a Java infrastructure. Charles for example used the rome library in Rails to generate an RSS feed and the next version of the GlassFish application server will offer special support for deployment of Rails applications. So the idea is, why not combine the best of both worlds (Grails & Java or Rails & Java).

As Groovy is a dynamic language written for the JVM and shares a lot of similarities with Java, I think it might be more suitable for Java teams and environments than Ruby. Grails itself is based on solid java components like Spring, hibernate, quartz, sitemesh, embedded jetty and hsqldb (80% of grails is written in Java) and offers various java related plugins (e.g. for DWR, Wicket, xFire,…). The 0.6 release of Grails (available as release candidate) will offer integrated support for Spring Webflow and the 1.0 release is due in October.

All in all it has been an inspiring afternoon and no matter if you favor Ruby, Grooy, Grails or Rails, these are exiting developments and if you can, learn something new and give it a try. I started to learn Ruby & ROR a while ago but never really had a chance to use it practically. With Groovy & Grails I think it might be different as the demand for lean and agile java development is growing.

More photos on Flickr

Bookmark It

For quite a while, I was trying to ignore the increasing buzz about Wicket, convincing myself that I don’t need yet another MVC framework (there are too many of them anyway), but somewhere between the Javalobby articles, the InfoQ article and the O’ReillyNet article – my resolve cracked and I took a closer look. (…)

It looked interesting and so I decided to try and migrate a selected few JSP screens of an existing Spring MVC + Spring WebFlow application to Wicket. This went much better than I expected and two months later (not full time) – I completed migrating the entire app to Wicket and it is now ready for a new release as a 100% JSP free application. (…)

So is Wicket the one true MVC framework that a lot of us have been hunting for? At the moment, I tend to think so. (…)

read the full article

It all sounds so familiar. Spring MVC, Spring WebFlow, XML configuration files, JSP with various tag libraries and custom tags, JSTL, Acegi, an unmaintainable collection of Javascript files and libraries, SiteMesh decorators, Velocity, web-designers who mess up JSP files and so on. Web development like this is error prune and not really suitable for an agile development process.

Wicket sounds very interesting and promising. I should give it a try but I guess I can not convince management to give us some extra weeks to convert the web-application we’ve been working on from Spring MVC to Wicket.

Bookmark It