Here’s Wednesday’s links from My Twitter Stream.
- 22:11: [Blog] Is Maven agile? http://bit.ly/bCfKfI
Is Maven agile? Here’s my half-assed reasons why:
Disclaimer: Your Milage May Vary. Maven may not suit your needs. Ditto with Ant. The value of your technical debt may go up as well as down.
(Image via http://www.flickr.com/photos/zenera/)
(see part one of this series here)
(A guest post kindly written by EJ Ciramella)
In this installment, Iâ€™m going to cover the four cheap-fast ways Iâ€™ve seen discussed to generate configuration for your application.
There are a few ways I’ve found or seen discussed over the years for managing the configuration portion of a deployment (local or otherwise). I don’t think one way is the best way for everyone, each company is unique. The decision should be based on what suits your company best, not how many plugins you can configure or how can you change the way business operates (within reason). There are other, more complex ways; like Spring based configuration. This discussion is limited to the cheapest (simplest) way to manage configuration. Below are four very common approaches.
This is the most expensive (with regard to time and space) option of the four. This option assumes that you have very few deployable units and very few stacks to deploy to. This option can be configured via profiles in the POM and leverage values either stored in profiles or in a settings.xml (or a host of other inconvenient ways). After what I’ve seen during my recent stint interviewing and what I’ve seen come across the Maven mailing lists, I think this is no longer an option for most. This becomes painfully obvious when the artifact starts getting beyond 50 MB. This concept fails to scale with the addition of machines or deployment environments.
At a previous employer, this was the initial choice for a first foray into configuration for our deployable units. This regularly took about three hours to finish and each additional machine was painful to manage (all stored in the build user’s settings.xml checked into Perforce), let alone adding additional stacks. To add insult to injury, having to sit through another three-hour build because ONE machine in ONE stack had ONE property tweaked was both painful and embarrassing. This option also fails to scale with the size or complexity of the environments you’re trying to support. Each additional stack could add upwards of 10 minutes each.
This is a step in the right direction. But the configuration is still bound to the artifact you’re attempting to deploy. It seems like a waste to generate a new deployable unit if the configuration for a particular application in a given deployment environment has changed. To a degree, this approach also fails to scale. You’ll end up including more and more configuration.
This is the final evolution I chose. Breaking out the configuration from the actual deployable unit and making the configuration its own artifact (ie pushed to our repository manager) allowed the same version of an application to be instantly redeployed (with the option of just reapplying configuration to an already deployed application) with a configuration change that took merely seconds to build.
In the next installment, Iâ€™m going to cover the configuration storage mechanism for this separate configuration jar approach.
As I write this post I’m sat on the train back from the UKUUG Spring Conference Manchester, getting a fascinating insight into the world of asset finance sales from the passenger sitting opposite me.
Highlights of the conference were:
UKUUG attracts some seriously talented people. It’s a small conference (north of 100 people), but that’s the way I like them.
(A guest post kindly written by EJ Ciramella)
One of the longest running debates I’ve watched in the Maven community over the years, is how to best support different configurations for different deployment environments (where “deployment environment” means a QA environment or staging environment – anything other than a local developer build). Some people argue simplicity over the complexity of some of the other options mentioned below. Others don’t have spare disk or time to burn building up complete and unique deployment artifacts.
In this first installment, Iâ€™m going to cover deploying my favorite deployment tool – Ant.
Packaging and Deployment
I tend to prefer using Ant as a deployment mechanism, forgoing perl or various shells because of the simplicity of the language. Anyone can read and understand a well-written Ant script (Ant is inherently self-documenting). One of the features I love is the “expandproperties” filterchain used in combination with a copy command. If your resources are in directories that mirror where they will live in their final locations, then it’s really easy to manage this with assembly descriptors (where the filtering can happen) and in the deploy script (if you’ll play along and use Ant). There are all kinds of little perks in using Ant, like being able to add a “-Dname=value” on the command line to override a known configuration setting, without having to rebuild your configuration. Here’s a very simple example of how I’ve configured applications in the past in a deploy script:
<copy todir="somelocation"> <fileset dir="templates" /> <filterchain> <expandproperties/> </filterchain> </copy>
It is (or can be) as simple as that.
Assembly descriptors can be a bit trickier. Initially, we used the stanzas to grab lists of wild-carded files, but this (obviously) won’t fail if the descriptor can’t find a file. So we migrated (as much as we reasonably could) to using the individual file listings via the stanzas. We also have three types of assembly descriptors: “dev” for local builds which has filtering set to true; “prod” for deployable artifacts which plucks files directly from the source tree and has filtering turned off; and a “common” component descriptor for grabbing everything that is uniform between dev and prod and requires no processing.
This approach has some pros and cons – obviously one major con is having to list out each file individually – but the giant upside is, if a file is missing because of relocation, the build will fail and you’ll instantly be alerted. Another downside is the fact that the assembly descriptors are essentially the same, with a difference in “outputDirectory” and filtering the only real differences. One of the benefits is that you don’t have to memorize where a template file lives in its final resting place. A cursory glance at the resources directory gives you the exact target location.
Another implied concept here is deploying an exploded WAR/EAR (we don’t need to digitally sign the artifacts as they are consumed internally). While there may be some benefits to startup or load times of the archived file, but being able to slightly alter configuration and redeploy without repackaging is a greater benefit – why build a archive if you don’t have to?
In the next installment, Iâ€™m going to cover the four cheap-fast ways Iâ€™ve seen discussed to generate configuration for your application.
(photo thanks to tacomabibleot)
Want to work with some of the best programmers that one can hire? TWUK are looking for people like me, but with a better accent! It’s all in the ad below.
This is the gig that got me 2 very happy months’ work in San Francisco. And they don’t have a project in Hemel Hempstead any more.