Build & Deploy for different environment

[HL Shen]

Not sure if this is the best forum to this question, but it's build & deployment related question...

When you deploy to production, do you build for two environments using different properties files and deploy both?
Or do you simple sync the files from production to offsite then change the configuration files?
Any input or is there any best practice on this?

Thanks in advance!

[Martijn Verburg]

It's generally considered best practice to have separate configuration files per environment or to have filterable configuration files, e.g. Have ${} replacement in Maven or @@ replacement in Ant). Typically you would build your artifact (jar/whatever) and then run an environmentalisation phase/target.

e.g. ant -Denv=production update_configuration_files

That way your environment free code (JAR/classes) remains separate from your code that you need to environmentalise.

Hope that made sense!

[Peter Johnson]

Martijn's recommendation is right-on if you own the production site and/or you know the site's configuration settings.

A slight variation can be done in the event that you don't know the final site's configuration, such as, for example, you have many customers to which you ship your app. In that case, one thing you can do is place all site-specific configuration information into a single properties file. Then have the customer change the properties to match his site, and then provide an script which is run to install/deploy the app and update the configuration files. You can always hide the ant call behind a shell script named 'install'. You could even forgo the properties file and have the ant script query the user about the information. I use this mechanism often at work when I want to pre-packge one of my apps for my colleagues but have no idea what their system might look like (it might not even be set up yet!).

I hope that makes sense and that it helps.

[Tim Holloway]

Actually, I prefer to build ONE unit for all environments and control the details by injecting configuration information. You can do this easily using JNDI and the Context xml configuration in Tomcat for simple stuff, or keep more complex infomation in an external file or database and inject the location of that information.

The advantages of this are that I don't have to juggle 2 different types of builds and if something goes wrong in production, I don''t have to worry about build differences on the test system hiding the problems with the production code.