* Strict separation of config from code
* Stores config in environment variables
* Mentions that grouping properties into groups for environments ('dev', 'test') doesn't scale
I'm a bit confused about this requirement, I store my configuration in .properties files and then use a Maven Profile to select the correct files.
I don't understand why this is a bad practice, in my projects we usually only have a few environments (local, dev, dev2, test, test2, acpt, prod).
Also I'm not sure if I like the idea of using environment variables. Would I pass these variables into the JVM by using '-Denv_var=$MY_ENV_VAR' ?
5) Build, release, run
*Build stage - source code to Build Artifact
*Release stage - Build Artifact + Config
*Impossible to make changes to the code at runtime
From a Java point of view would Building & Releasing be the same ? We usually end up with 1 artifact (jar/war) with everything inside of it.
Also I like to use Managed Beans to be able to tune my application while its running in a test environment, does this violate the 'Impossible to make changes' principle?
*Execute the app as one or more stateless processes
*Twelve-factor processes are stateless and share-nothing
*Any data that needs to persist must be stored in a stateful backing service (Database)
*Sticky sessions are a violation of twelve-factor
I normally develop web applications with Spring MVC and deploy to a single Tomcat. Up until now I have the application running on 1 server at a time per environment.
How doe Java Sessions work across distributed environments ? Don't we need Sessions, how else can we remember if the user has logged in (with cookies?) ?
Is there a framework that will allow our Sessions to be distributed across all deployments?
7) Port binding
*Export services via port binding
*The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service
Does this mean I should be embedding Jetty into my web application instead of deploying into a server like Tomcat?
*Applications must also be able to span multiple processes running on multiple physical machines
I'm pretty lost on this one... normally I tend to use a JMS Message Qeue to distribute my work load. Can anyone elaborate?
*A twelve-factor app never concerns itself with routing or storage of its output stream
*It should not attempt to write to or manage logfiles
*writes to stdout
How does this apply to Java applications using Logging frameworks like Log4j. Do we continue using the libraries but simply send to stdout?