Refactoring tools are fantastic and overrated Digshot: Digg vs. Slashdot
Nov 09

Symlinks and directories, versus EAR files

Java, PHP, Ruby, Tech Add comments

Another post in the realm of dynamic platforms, and this time my thoughts are on deployment.

I have been working on a large web application, that is now in production.

The project before this one was on a large stack (WebSphere) and the deployment was a nightmare.

In development we had simple war’s and developers were all setup with expanded versions so they weren’t wasting time ziping up changes for a simple text change :)

However, the deployment issues were another story. They needed to be ear’d and run through a million checks on this, that, and a bit of the other.

We had to have our build system scripted to handle this all, and there were constant problems.

From that, I am now on a system where there are no such beasts as EARs. You just have good ole files and directories that the server looks too. Development is pretty much the same as deployment (bar a few optimizations that are taken care of via environment).

To jump between releases we can easily change a symlink and we are moved. An issue? we can move right back. No need to deploy/redeploy/undeploy in containers.

Bah I hear you scoff. What about all of the tools for deployment! How mickey mouse is this file based crud!

We have nice scripting via tools like Switchtower, which handles deployment very nicely indeed, and is easy to extend to do you will.

Lighter, and yet simple. Switchtower is still new-ish, so it may not do everything that you need in your deployment world… but it is getting there.

4 Responses to “Symlinks and directories, versus EAR files”

  1. James Strachan Says:

    Here here. Tools should be designed to suit us; we shouldn’t have to jump through hoops to do things the way the tool designer wanted us to use them.

  2. RefuX Says:

    I was recently tasked with helping improve automated deployments on our servers.
    I actually took the opposite route!
    I took all our bat files and (non J2EE) deployments and packaged them all up as seperate OSGi bundles. Now I can just tell a OSGi bundle to ‘update’ and it will gracefully stop and then download its newest version and restart the bundle.

  3. Dmitri Colebatch Says:

    I’m assuming this environment isn’t clustered. If it were to be clustered how would you handle it? I also assume this means you have filesystem access to your servers from your development machines and that you’re not interested in any features such as graceful redeploy (keeping existing sessions on the old version whilst having new sessions go to the new version)?

    Whilst I’m all up for simplicity, what you’re suggesting only handles the most basic of deployment scenarios.

  4. Laure Says:

    Great, what about this one then:

    Enjoy :)

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: What is the number before 3? (just put in the digit)