Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Artifact per Environment Anti-Pattern

DZone's Guide to

The Artifact per Environment Anti-Pattern

· Java Zone ·
Free Resource

Verify, standardize, and correct the Big 4 + more– name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!

The Problem: How to handle environment specific properties is a topic that seems to generate much discussion.
While initially this may seem a trivial problem as requirements grow the complexity of the solutions will also. Here are some of the requirements you might have to tackle:

  • Overriding default properties
  • Dealing with properties that need to kept secret to the development team e.g. production passwords 
  • Properties that need to be changed dynamically (tuned) while the app is running e.g. cache configuration
  • The addition of new environments after the original artifact has been built

I've seen countless approaches to the problem - properties in the jndi tree, in the database, good old property files, pojo's etc. Each has its own pro's and con's and can range from simple implementations to hugely complex frameworks.


Not the Solution

One solution that is often suggested is rebuilding the artifact per environment and "baking" in the environment specific properties. This pattern very standard in Grails ( http://www.grails.org/Environments) and often recommended for Maven ( http://www.sonatype.com/books/maven-book/reference/profiles-sect-tips-tricks.html)

Now I'm sure there are many situations where this works perfectly well - a blunt axe can still chop a tree down!  But, I believe that for many reasons its sub-optimal.. 


The Downsides an Artifact per Environment:


  • Inefficient - the simple fact that do you have to rebuild the artifact for each environment is time consuming and involves repetition of effort
  • Risky - After testing your artifact in your test environment you are then going to deploy a different artefact that was never tested to production
  • Unnecessary Builds - If the properties change after you build the artifact - you need to build it again! 
  • Hard to diagnose problems - did some deploy the test war to production by accident? Get used to having to crack open jar's and war's to check the config.
  • Not compatible with Maven repositories - Maven repositories work best with one version of an artifact per version number - e.g. there's only one Apache commons-collections 3.2.1. An artefact per environment breaks this.

The Alternatives:
So what to do instead? Generally the best way to go is to externalise your properties from the artefact and then have it choose the correct properties at runtime. This is too general an area for one prescriptive approach but hopefully this article has ruled out building an artifact per environment.


Links:
Some ways to load properties from locations dependent on system variables in Spring 
Externalising Grails config

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}