Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Maven best practice for generating artifacts for multiple environments [prod, test, dev] with CI/Hudson support?

I have a project that need to be deployed into multiple environments (prod, test, dev). The main differences mainly consist in configuration properties/files.

My idea was to use profiles and overlays to copy/configure the specialized output. But I'm stuck into if I have to generate multiple artifacts with specialized classifiers (ex: "my-app-1.0-prod.zip/jar", "my-app-1.0-dev.zip/jar") or should I create multiple projects, one project for every environment ?!
Should I use maven-assembly-plugin to generate multiple artifacts for every environment ? Anyway, I'll need to generate all them at once so it seams that the profiles does not fit ... still puzzled :(

Any hints/examples/links will be more than welcomed.

As a side issue, I'm also wondering how to achieve this in a CI Hudson/Bamboo to generate and deploy these generated artifacts for all the environments, to their proper servers (ex: using SCP Hudson plugin) ?

like image 828
user68682 Avatar asked Mar 11 '10 10:03

user68682


3 Answers

I prefer to package configuration files separately from the application. This allows you to run the EXACT same application and supply the configuration at run time. It also allows you to generate configuration files after the fact for an environment you didn't know you would need at build time. e.g. CERT I use the "assembly" tool to zip up each domain's config files into named files.

like image 137
Chris Nava Avatar answered Nov 16 '22 03:11

Chris Nava


I would use the version element (like 1.0-SNAPSHOT, 1.0-UAT, 1.0-PROD) and thus tags/branches at the VCS level in combination with profiles (for environments specific things like machines names, user name passwords, etc), to build the various artifacts.

like image 23
Pascal Thivent Avatar answered Nov 16 '22 03:11

Pascal Thivent


We implemented a m2 plugin to build the final .properties using the following approach:

  • The common, environment-unaware settings are read from common.properties.
  • The specific, environment-aware settings are read from dev.properties, test.properties or production.properties, thus overriding default values if necessary.
  • The final .properties files is written to disk with the Properties instance after reading the files in given order.
  • Such .properties file is what gets bundled depending on the target environment.
like image 22
chous Avatar answered Nov 16 '22 02:11

chous