I recently had a chance to go through the principles of the 12-Factor App as listed on [12factor.net](http://12factor.net/).  It's written by some of the fine folk at Heroku.  The principles describe the best practices they see for how to get a modern web app deployed properly.  It's a short read.  This summary is even shorter.



##### 1. Codebase

- Always in src ctrl
- One codebase per app (many repos = distributed system)
- A deploy = instance of app running

##### 2. Dependencies

- All app and system dependencies explicitly declared
- Do not dep on implicit existence of system tools (eg, ImageMagick)
- Required sys tools vendored into app

##### 3. Config

- Strict separation between code and config
- Config stored in env vars

##### 4. Backing Services

- Should be loosely coupled, swappable
- Changes in services (eg, db) should not require code change

##### 5. Build, release, run

- Strict separation: build (binary), release (binary + env config), run (exec runtime)
- Ordered -- can't make change upstream
- Every release has unique id

##### 6. Processes

- Independent, stateless, share nothing
- Sharing happens in backing service (eg, db)
- No sticky sessions w/ process affinity

##### 7. Port Binding

- Can talk a protocol (eg, HTTP) by binding comm to a port
- Allows an app to become a backing service for another app via a url
- What does the alternative look like here?  Seems like a given.

##### 8. Concurrency

- Process is first-class citizen patterned after unix service daemons
- Process can multiplex internally (eg, threads or something like node.js)
- Scaling becomes a simple addition of the same process

##### 9. Disposability

- Startups are fast
- Requests are short
- Shutdowns are graceful; requests can finish; jobs returned to queue

##### 10. Dev/Prod Parity

- Time from dev to prod deploy should be short (eg, hrs)
- Devs who wrote the code should be around to op the code
- Toolchains and tech stacks should be as similar as possible
- Backing servies should be the same, even if adapters supposedly abstract implementations

##### 11. Logs

- Logs are treated as streams, simply written by an app to stdout
- Let log storage, collating, and analysis be done in the env or or w/ other tools
- Logs should provide visibility to how an app works over time

##### 12. Admin Processes

- Run as one-off processes in REPL
- Env shares same code and config as long-running processes

If you have the extra little time required, I encourage you to check out [12factor.net](http://12factor.net/) and draw some of your own conclusions.

What other insights do you have on these principles?

"12-Factor App" Summary

Development on JEE projects can be a real pain sometime.  1/2 of this (sometimes in literal minutes) is because of the need to spin up the server in order to run your code.  This server startup time can be a killer of one's development momentum. 

True to its mantra, IntelliJ IDEA delivers some goodness is making this pain a little more pleasurable -- if that's possible.



Development on JEE projects can be a real pain sometime.  1/2 of this (sometimes in literal minutes) is because of the need to spin up the server in order to run your code.  This server startup time can be a killer of one's development momentum.  If one is trying to make a change to code and then follow through and check the resulting differences, it can be much like running downstairs in one's house to fetch something, forgetting what that something was upon arrival.

It seems that the solutions to this problem are varied.  For me, it has meant: - Coding webapps in interpreted languages
- Trying IDE-based hotdeploy schemes
- Trying 3rd-party plugins like JavaRebel.

I have had problems with all 3 solutions:
- These are fun, but not what my employer uses
- I haven't found an IDE yet that hotdeploys to my liking.  It's always extremely hard to tell if an IDE has really done its job and if what the browser is giving back to me is the new version. Eclipse has tried to give a visual indicator with its 'Published'/'Republish' verbage in its Servers view, but it seems that this indicator is often wrong.
- I haven't had hardly any luck with JavaRebel.  Pre-version 1.0, it seemed buggy.  Then, I had problems integrating it with my IDE's build/deploy process.  Since the version 1.0 release, I haven't tried it again, but I hear it's still buggy.

As imperfect as the solutions are, it seems to me that the current best solution to the Java webapp hotdeploy is still the IDE-based hotdeploy scheme.  As my favorite IDE is IntelliJ IDEA, here's a little 1-2-3 on how to get hotdeploy working in IntelliJ 8 (as of Milestone 1, Diana):

<h3>Select two important options</h3>

Go to Settings > Compiler, and set "Deploy web applications to server after compilation" to "Never"

<a href="https://picasaweb.google.com/lh/photo/qOoybG2F413C8IkbKljbug"><img src="https://lh5.ggpht.com/trent.jake/SNgOk1bJ1cI/AAAAAAAAENs/DTZhP4ZvYBk/s800/compileropt.png" /></a>

Go to Settings > Debugger, and set "Reload classes after compilation" to "Always" and optionally check "Reload classes in background".

<h3>Compile after a code change</h3>

Now, every time you make a change to compiled code (e.g., .java files), make sure you re-compile.  The shortcut is Ctrl-Shift-F9.

And that's it!  Pleasurable development was meant to be fast and simple.

I'm a little unclear as to the essentialness, but as a general rule, I also set another option in the deployment settings for static file hotdeploy:

Go to Settings > Project Settings > your web module > Java EE Build Settings and check "Build on frame deactivation" and check "Build Web resources only"

<a href="https://picasaweb.google.com/lh/photo/hsw-VeKzduwMGCANP4p5xg"><img src="https://lh4.ggpht.com/trent.jake/SNgSOwB4qyI/AAAAAAAAEOI/d07_gHC89nI/s400/projsettings.png" /></a>

I haven't tested the utter-most limits of this hotdeploy.  I'm not really sure at their limitations, but I would guess that changes to method signatures or changes to descriptor files would require a server restart.  I am, however, unsure.  How about you?

Besides just the handy hotdeploy, one should also keep in mind that other things can help startup time: viva los smaller projects!  But, for anyone wanting to enjoy a behemoth, enjoy Napi.

Development on JEE projects can be a real pain sometime.  1/2 of this (sometimes in literal minutes) is because of the need to spin up the server in order t