On Fri, Jul 15, 2011 at 12:38 AM, Anders Hammar <and...@hammar.net> wrote:
> I'm not sure I fully understand, but some general rules:
>
> 1) Keep all configuration outside the jars. If you don't want to use a
> database or jndi, you could always (which I very often recommend) just use a
> properties file read from the classpath. During runtime just make sure the
> properties file exists on the classpath. This type of config file might not
> even be handled in your scm as the configuration for each environment is not
> known during development. Default values (if possible) should be provided by
> the the application.
> 2) If you have other environment specific resources (images or whatever) you
> could handle those the same way. You could bundle those in a jar and put the
> jar on the classpath if you want.
Mark, your developers are kept isolated from production, right?
You don't want them knowing production passwords - which is what is
going to happen if you are storing this information in your maven
project's configuration files and then stored into your local
repository manager.
Generally, we even isolate developers away from QA as this needs to be
a managed environment and its the tester's job to decide when and what
gets loaded onto it.
Developers have access to their local machine instances (DEV) and the
shared INT environment - which ideally is autodeployed from your
continuous build server.
The base copy of all configuration files is set up to use the DEV so
that you can work in your IDE and deploy easily to your local
instances without faffing around with configuring stuff.
All other configurations files are stored in a protected area of your
version control system that only your deployment team has access to.
The deployment team's job is also to copy across the correct files for
the environment in question, and as Anders notes you load these files
from the classpath (and never hard coded file paths)
Ideally you want to automate this step.
Some issues with this process are
* the default DEV settings can get out of sync with the other environments
- A way to alleviate that is to have configuration templates which
only define the keys needed, so that something can compare the
expected keys against the actual keys and check them.
If there are too many keys something has gone wrong because an old
configuration key is no longer in use.
If there are not enough keys something has gone wrong because a
new configuration key has not been configured.
* the default DEV values can be accidentally used in a non-DEV environment.
- You need to remove the developers' time saving steps of having DEV
as the default and force them to configure the system.
Ideally it would be scripted identically as your other
environments as this is a great way to check that those scripts
actually work.
Your deployment plan should also include steps that double check
configuration values are set to their expected values.
And as you note Mark, guidance on this is next to non-existent and a
lot of the steps (like configuration sanity checking, automated
deployment of environment specific configuration files) are
roll-your-own solutions instead of using a tried and tested system.
If consensus can be reached then perhaps this should be written up on
the maven user wiki?
http://docs.codehaus.org/display/MAVENUSER/Home
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
