Link Details

This approach violates the open closed principle. It is much easier to do this by just using loading the correct env property file and running THE SAME target rather than creating different targets for each env.

Not really. The article is not about declaring properties, is about executing actions. What you've just described doesn't work in practice. You are saying: "All the environments should execute the same actions". Oh no, that's a big mistake.

Also, when you integrate a build file into your CI server, having specific tasks for each environment offers more flexibility and makes your life easier.

Of course it works in practice; I've done it this way for years...

So, what happens when one environment requires action A and another environment requires action B? How do you perform different tasks based on different environments? According to you, you only need one target: "build", and all the decisions are made and executed inside that target. But, the more environments you have, the more smelly the "build" target gets.

Having only one build target doesn't allow you to react to changes, for example, reduce public exposure of targets. You are not isolating actions into separate targets and you are breaking the principle of “least astonishment”, other developers don't know how to taget different environments because they don't see the targets, instead, they have to ask you.

I can see some anti-patterns in your approach. Responsibilities should be distributed more uniformly and isolating the effect of changes. The example I provided can improve your build file structure and help other developers maintain it.

I'm not saying you are wring of course, and I quote the article posted: "There are different ways to target multiple environments".

If you are executing different build actions for different environments, that is part of your problem. Talk about violating the principle of 'least astonishment'! That is the anti-pattern right there.

Typically, different environments require different runtime configurations, not different build actions. The end result of those builds should all be the same: a deployable build artifact (e.g. WAR, RAR, JAR, EAR).

There is only ONE package target and it does the same thing every time.

I've been doing this a long time and every crappy build script that I end up maintaining looks just like the one that you are describing.

I'd MUCH rather do:

ant package -Denv=dev

than

ant dev-package

In your case, every time a new environment is spun up, someone has to touch the build script. In my case, the build script NEVER changes when a new environment is added. OCP, in a nutshell.

I'm guessing you are using a lot of if/then conditions inside your build target. I've seen this done before, the problem is that you end up having a massive build file with spaghetti markup that's impossible to maintain.

Based on what you are saying, I get the impression that:

1) You assume a deployable artifact is a WAR file.
2) You don't use Linux packages and repositories,
3) You don't use tools such as Puppet and you install, upgrade and roll back your applications manually.
4) You don't have a proper deployment strategy.
5) You are not a sys admin :)

It's easy to say "my way or the highway". Why don't you post an example here http://codepad.org and let others decide if your way is the right way or the smelly way.

> ant package -Denv=dev

You are building an RPM on your local machine? Why?

You're guessing wrong. There are NO conditional statements in ANY of my build scripts.

Our build scripts are templatized. The same scripts are used as the foundation for dozens of projects. Cluttering them up with environment specific targets (which would not apply to all projects) would eliminate their utility as templates.

Enough talking, show at least one example.