+
+Los recursos se pueden conectar y desconectar a voluntad. Por ejemplo, si la base de datos funciona mal debido a un problema en el hardware, el administrador de la aplicación puede cambiar a un nuevo servidor de bases de datos que haya sido restaurado de un backup reciente. La base de datos actual de producción se puede desconectar, y conectar una nueva base de datos sin tener que cambiar nada en el código.
diff --git a/content/es/build-release-run.md b/content/es/build-release-run.md
new file mode 100644
index 000000000..c37f0adee
--- /dev/null
+++ b/content/es/build-release-run.md
@@ -0,0 +1,18 @@
+## V. Construir, distribuir, ejecutar
+### Separar completamente la etapa de construcción de la etapa de ejecución
+
+El [código base](./codebase) se transforma en un despliegue (que no es de desarrollo) al completar las siguientes tres etapas:
+
+* La *etapa de construcción* es una transformación que convierte un repositorio de código en un paquete ejecutable llamado *construcción* (una "build"). En la etapa de construcción se traen todas las [dependencias](./dependencies) y se compilan los binarios y las herramientas usando una versión concreta del código correspondiente a un commit especificado por el proceso de despliegue.
+* En la *fase de distribución* se usa la construcción creada en la fase de construcción y se combina con la [configuración](./config) del despliegue actual. Por tanto, la *distribución* resultante contiene tanto la construcción como la configuración y está lista para ejecutarse inmediatamente en el entorno de ejecución.
+* La *fase de ejecución* (también conocida como "runtime") ejecuta la aplicación en el entorno de ejecución, lanzando un conjunto de [procesos](./processes) de una distribución concreta de la aplicación.
+
+
+
+**Las aplicaciones "twelve-factor" hacen una separación completa de las fases de construcción, de distribución y de ejecución.** Por ejemplo, es imposible hacer cambios en el código en la fase de ejecución, porque no hay una manera de propagar dichos cambios a la fase de construcción.
+
+Las herramientas de despliegue ofrecen, normalmente, herramientas de gestión de distribuciones (releases). La capacidad de volver a una versión anterior es especialmente útil. Por ejemplo, la herramienta de despliegues [Capistrano](https://github.com/capistrano/capistrano/wiki) almacena distribuciones en un subdirectorio llamado `releases`, donde la distribución actual es un enlace simbólico al directorio de la distribución actual. Su mandato `rollback` hace fácil y rápidamente el trabajo de volver a la versión anterior.
+
+Cada distribución debería tener siempre un identificador único de distribución, como por ejemplo una marca de tiempo (timestamp) de la distribución (`2011-04-06-20:32:17`) o un número incremental (como `v100`). Las distribuciones son como un libro de contabilidad, al que solo se le pueden agregar registros y no pueden ser modificados una vez son creados. Cualquier cambio debe crear una nueva distribución.
+
+Cada vez que un desarrollador despliega código nuevo se crea una construcción nueva de la aplicación. La fase de ejecución, en cambio, puede suceder automáticamente, por ejemplo, cuando se reinicia un servidor, o cuando un proceso termina inesperadamente siendo reiniciado por el gestor de procesos. Por tanto, la fase de ejecución debería mantenerse lo más estática posible, ya que evita que una aplicación en ejecución pueda causar una interrupción inesperada, en mitad de la noche, cuando no hay desarrolladores a mano. La fase de construcción puede ser más compleja, ya que los errores siempre están en la mente de un desarrollador que dirige un despliegue.
diff --git a/content/es/codebase.md b/content/es/codebase.md
new file mode 100644
index 000000000..e0d6ec784
--- /dev/null
+++ b/content/es/codebase.md
@@ -0,0 +1,17 @@
+## I. Código base (Codebase)
+### Un código base sobre el que hacer el control de versiones y multiples despliegues
+
+Una aplicación "twelve-factor" se gestiona siempre con un sistema de control de versiones, como [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/), o [Subversion](http://subversion.apache.org/). A la copia de la base de datos de seguimiento de versiones se le conoce como un *repositorio de código*, a menudo abreviado como *repo de código* o simplemente *repo*.
+
+El *código base* es cualquier repositorio (en un sistema de control de versiones centralizado como Subversion), o cualquier conjunto de repositorios que comparten un commit raíz (en un sistema de control de versiones descentralizado como Git).
+
+
+
+Siempre hay una relación uno a uno entre el código base y la aplicación:
+
+* Si hay multiples códigos base, no es una aplicación -- es un sistema distribuido. Cada componente en un sistema distribuido es una aplicación, y cada uno, individualmente, puede cumplir los requisitos de una aplicación "twelve-factor".
+* Compartir código en varias aplicaciones se considera una violación de la metodología "twelve factor". La solución en este caso es separar el código compartido en librerías que pueden estar enlazadas mediante un [gestor de dependencias](./dependencies).
+
+El código base de la aplicación es único, sin embargo, puede haber tantos despliegues de la aplicación como sean necesarios. Un *despliegue* es una instancia de la aplicación que está en ejecución. Normalmente, se ejecuta en un entorno de producción, y uno o varios entornos de pruebas. Además, cada desarrollador tiene una instancia en su propio entorno de desarrollo, los cuales se consideran también como despliegues.
+
+El código base es el mismo en todos los despliegues, aunque pueden ser diferentes versiones en cada despliegue. Por ejemplo, un desarrollador tiene algunos commits sin desplegar en preproducción; preproducción tiene algunos commits que no están desplegados en producción. Pero todos ellos comparten el mismo código base, de este modo todos son identificables como diferentes despliegues de la misma aplicación.
diff --git a/content/es/concurrency.md b/content/es/concurrency.md
new file mode 100644
index 000000000..334c7d752
--- /dev/null
+++ b/content/es/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. Concurrencia
+### Escalar mediante el modelo de procesos
+
+Todo programa de ordenador, al ejecutarse, se encuentra representado en memoria por uno o más procesos. Las aplicaciones web se pueden ejecutar de diferentes formas desde el punto de vista del modelo de procesos que usan. Por ejemplo, los procesos PHP se ejecutan como procesos pesados (o simplemente procesos), hijos del proceso Apache, creándolos bajo demanda a causa de la cantidad de peticiones si es necesario. Los procesos Java funcionan de forma distinta, la Máquina Virtual de Java (JVM) proporciona un conjunto de procesos que reservan al principio una gran cantidad de recursos del sistema (CPU y memoria), gestionando la concurrencia internamente mediante procesos ligeros (threads). En ambos casos, los procesos en ejecución son prácticamente transparentes para los desarrolladores de la aplicación.
+
+
+
+**En las aplicaciones "twelve-factor", los procesos son ciudadanos de primera clase.** Los procesos de las aplicaciones "twelve-factor" se inspiran en [el modelo de procesos de unix para ejecutar demonios](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Usando este modelo, el desarrollador puede distribuir la ejecución de su aplicación para gestionar diversas cargas de trabajo asignando cada tipo de trabajo a un *tipo de proceso*. Por ejemplo, las peticiones HTTP se pueden procesar con un proceso y las tareas con mucha carga de trabajo con hilos.
+
+Esto no exime a los procesos de gestionar su propia división interna mediante threads en la ejecución de la máquina virtual o mediante un modelo asíncrono o por eventos con herramientas como [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/), o [Node.js](http://nodejs.org/). No obstante, una máquina virtual aislada tiene una capacidad de crecimiento limitada, así que la aplicación debe ser capaz de dividirse en multiples procesos que se puedan ejecutar en múltiples máquinas físicas.
+
+El modelo de procesos muestra todo su potencial cuando llega el momento de escalar. La [naturaleza "share-nothing", divide horizontalmente los procesos de las aplicaciones "twelve-factor"](./processes) y se traduce en un aumento de la concurrencia como una operación simple y fiable. El conjunto de tipos de procesos y el número de procesos de cada tipo es conocido como *juego de procesos*.
+
+Los procesos de las aplicaciones "twelve-factor" [nunca deberían ser demonios](http://dustin.github.com/2010/02/28/running-processes.html) ni escribir ficheros de tipo PID. En su lugar, se debería confiar en un gestor de procesos del sistema operativo (como [Upstart](http://upstart.ubuntu.com/), un gestor de procesos distribuido en una plataforma en la nube, o una herramienta como [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) en desarrollo) para gestionar [los historiales](./logs), responder a procesos que terminen inesperadamente, y gestionar los reinicios y apagados provocados por los usuarios.
diff --git a/content/es/config.md b/content/es/config.md
new file mode 100644
index 000000000..9849720b3
--- /dev/null
+++ b/content/es/config.md
@@ -0,0 +1,22 @@
+## III. Configuración
+### Guardar la configuración en el entorno
+
+La configuración de una aplicación es todo lo que puede variar entre [despliegues](./codebase) (entornos de preproducción, producción, desarrollo, etc), lo cual incluye:
+
+* Recursos que manejan la base de datos, Memcached, y otros ["backing services"](./backing-services)
+* Credenciales para servicios externos tales como Amazon S3 o Twitter
+* Valores de despliegue como por ejemplo el nombre canónico del equipo para el despliegue
+
+A veces las aplicaciones guardan configuraciones como constantes en el código, lo que conduce a una violación de la metodología "twelve-factor", que requiere una **estricta separación de la configuración y el código**. La configuración varía sustancialmente en cada despliegue, el código no.
+
+La prueba de fuego para saber si una aplicación tiene toda su configuración correctamente separada del código es comprobar que el código base puede convertirse en código abierto en cualquier momento, sin comprometer las credenciales.
+
+Hay que resaltar que la definición de "configuración" **no** incluye las configuraciones internas de la aplicación, como `config/routes.rb` en Rails, o como [se conectan los módulos](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) en [Spring](http://spring.io/). Este tipo de configuraciones no varían entre despliegues, y es por eso que están mejor en el código.
+
+Otra estrategia de configuración es el uso de ficheros de configuración que no se guardan en el control de versiones, como ocurre con el `config/database.yml` de Rails. Esto supone una gran mejora con respecto a las constantes que se guardan en el repositorio, aunque todavía tiene ciertas debilidades: es fácil guardar un fichero de configuración en el repo por error; se tiende a desperdigar los ficheros de configuración en diferentes sitios y con distintos formatos, siendo más difícil la tarea de ver y gestionar toda la configuración en un solo sitio. Además, el formato tiende a ser específico del lenguaje o del framework.
+
+**Las aplicaciones "twelve-factor" almacenan la configuración en *variables de entorno*** (abreviadas normalmente como *env vars* o *env*). Las variables de entorno se modifican fácilmente entre despliegues sin realizar cambios en el código; a diferencia de los ficheros de configuración, en los que existe una pequeña posibilidad de que se guarden en el repositorio de código accidentalmente; y a diferencia de los ficheros de configuración personalizados u otros mecanismos de configuración, como los System Properties de Java, son un estándar independiente del lenguaje y del sistema operativo.
+
+Otro aspecto de la gestión de la configuración es la clasificación. A veces, las aplicaciones clasifican las configuraciones en grupos identificados (a menudo llamados "entornos" o "environments") identificando después despliegues específicos, como ocurre en Rails con los entornos `development`, `test`, y `production`. Este método no escala de una manera limpia: según se van creando despliegues de la aplicación, se van necesitando nuevos entornos, tales como `staging` o `qa`. Según va creciendo el proyecto, los desarrolladores van añadiendo sus propios entornos especiales como `joes-staging`, resultando en una explosión de combinaciones de configuraciones que hacen muy frágil la gestión de despliegues de la aplicación.
+
+En una aplicación "twelve-factor", las variables de entorno son controles granulares, cada una de ellas completamente ortogonales a las otras. Nunca se agrupan juntas como "entornos", pero en su lugar se gestionan independientemente para cada despliegue. Este es un modelo que escala con facilidad según la aplicación se amplía, naturalmente, en más despliegues a lo largo de su vida.
diff --git a/content/es/dependencies.md b/content/es/dependencies.md
new file mode 100644
index 000000000..b6435da0c
--- /dev/null
+++ b/content/es/dependencies.md
@@ -0,0 +1,12 @@
+## II. Dependencias
+### Declarar y aislar explícitamente las dependencias
+
+La mayoría de los lenguajes de programación tienen un sistema de gestión de paquetes para distribuir sus librerías, como [CPAN](http://www.cpan.org/) en Perl o [Rubygems](http://rubygems.org/) en Ruby. Las librerías instaladas a través de estos sistemas se pueden instalar en el sistema (también conocido como "site packages") o limitarse al directorio que contiene la aplicación (también conocido como "vendoring" o "bundling").
+
+**Una aplicación "twelve-factor" no depende nunca de la existencia explícita de paquetes instalados en el sistema.** Declara todas sus dependencias, completamente y explícitamente, mediante un manifiesto de *declaración de dependencias*. Además, usa herramientas de *aislamiento de dependencias* durante la ejecución para asegurar que las dependencias, implícitamente, no afectan al resto del sistema. La especificación de dependencias completa y explícita se aplica de la misma manera tanto en producción como en desarrollo.
+
+Por ejemplo, la [gema Bundler](http://gembundler.com/) de Ruby tiene el formato de su manifiesto `Gemfile` para declarar sus dependencias y `bundle exec` para aislar sus dependencias. En Python existen dos herramientas independientes para estas tareas -- [Pip](http://www.pip-installer.org/en/latest/) se usa para la declaración de dependencias y [Virtualenv](http://www.virtualenv.org/en/latest/) para el aislamiento. Incluso C tiene [Autoconf](http://www.gnu.org/s/autoconf/) para la declaración de sus dependencias, y el enlace estático proporciona aislamiento de sus dependencias. No importa qué conjunto de herramientas se use, la declaración y el aislamiento de dependencias se deben usar siempre juntas, usar solo una o la otra no es suficiente para satisfacer las condiciones de "twelve-factor".
+
+Uno de los beneficios de la declaración explícita de dependencias es que simplifica la configuración para los nuevos desarrolladores de la aplicación. Cualquier desarrollador que se incorpore al equipo debe poder probar el código base de la aplicación en su máquina de desarrollo. Tan solo debe tener instalados el entorno de ejecución del lenguaje y el gestor de dependencias como prerequisitos. Lo cual permitirá configurar todo lo necesario para ejecutar el código de la aplicación con un *mandato para construir*. Por ejemplo, el mandato para construir en Ruby/Bundler es `bundle install`, mientras que en Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) es `lein deps`.
+
+Las aplicaciones "Twelve-factor" tampoco dependen de la existencia de ninguna herramienta en el sistema. Por ejemplo, ejecutar mandatos como `ImageMagick` o `curl`. Aunque estas herramientas pueden existir en muchos, o incluso en la mayoría de los sistemas, no existen garantías de que vayan a existir en todos los sistemas donde la aplicación pueda ser ejecutada en un futuro, ni de que las versiones futuras de un sistema vayan a ser compatibles con la aplicación. Si la aplicación necesita ejecutar una herramienta del sistema, dicha herramienta debería estar incluida dentro de la aplicación.
diff --git a/content/es/dev-prod-parity.md b/content/es/dev-prod-parity.md
new file mode 100644
index 000000000..7821774b9
--- /dev/null
+++ b/content/es/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Igualdad entre desarrollo y producción
+### Mantener desarrollo, preproducción y producción tan parecidos como sea posible
+
+Históricamente, han existido dos tipos de entorno muy diferenciados: desarrollo (donde un desarrollador puede editar en vivo en un [despliegue](./codebase) local de la aplicación) y producción (un despliegue en el que la aplicación está en ejecución disponible para que lo usen los usuarios). Estas diferencias se pueden clasificar en tres tipos:
+
+* **Diferencias de tiempo**: Un desarrollador puede estar trabajando en un código durante días, semanas o incluso meses antes de que llegue a producción.
+* **Diferencias de personal**: Los desarrolladores escriben el código y los ingenieros de operaciones lo despliegan.
+* **Diferencias de herramientas**: Los desarrolladores pueden usar una pila como Nginx, SQLite y OS X, mientras que en producción se usa Apache, MySQL y Linux.
+
+** Las aplicaciones "twelve-factor" están diseñadas para hacer [despliegues continuos](http://www.avc.com/a_vc/2011/02/continuous-deployment.html) que reducen las diferencias entre los entornos de desarrollo y producción.** Teniendo en cuenta las tres diferencias descritas anteriormente:
+
+* Reducir las diferencias de tiempo: Un desarrollador puede escribir código y tenerlo desplegado en tan solo unas horas, o incluso, minutos más tarde.
+* Reducir las diferencias de personal: Los desarrolladores que escriben el código están muy involucrados en el despliegue y observan su comportamiento en producción.
+* Reducir las diferencias de herramientas: tratar de hacer que desarrollo y producción sean tan parecidos como sea posible.
+
+Resumiendo lo anterior en una tabla:
+
+| + | Aplicaciones tradicionales | +Aplicaciones "twelve-factor" | +
|---|---|---|
| Tiempo entre despliegues | +Semanas | +Horas | +
| Desarrolladores vs Ingenieros de operaciones | +Diferentes personas | +Mismas personas | +
| Entorno de desarrollo vs entorno de producción | +Divergentes | +Lo más parecidos posibles | +
| Tipo | +Lenguaje | +Librería | +Adaptador | +
|---|---|---|---|
| Base de datos | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Colas | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Caché | +Ruby/Rails | +ActiveSupport::Cache | +Memoria, sistema de ficheros, Memcached | +
+
+Les resources peuvent être attachées et détachées à volonté à des déploiements. Par exemple, si la base de données de l'application pose problème pour des raisons matérielles, l'administrateur de l'application peut vouloir lancer un nouveau serveur de base de données restauré à partir d'une sauvegarde récente. L'application courante pourrait être détachée de l'ancienne, puis rattachée à la nouvelle — le tout sans changement dans le code.
diff --git a/content/fr/build-release-run.md b/content/fr/build-release-run.md
new file mode 100644
index 000000000..587678acb
--- /dev/null
+++ b/content/fr/build-release-run.md
@@ -0,0 +1,19 @@
+## V. Assemblez, publiez, exécutez
+### Séparez strictement les étapes d'assemblage et d'exécution
+
+Une [base de code](./codebase) est transformée en un déploiement (non-développement) à travers les étapes suivantes :
+
+* L'*étapes d'assemblage* (ou "build") est une transformation qui convertit un dépôt de code en un paquet autonome exécutable appelé l'assemblage (ou "build"). En utilisant une version du code référencée par un commit spécifié lors du processus de déploiement, l'étape d'assemblage va chercher toutes les [dépendances externes](./dependencies) et compile les fichiers binaires et les ressources.
+* L'*étape de publication * (ou "release") prend l'assemblage produit à l'étape précédente et le combine avec la [configuration](./config) de déploiement courante. La release résultante contient à la fois l'assemblage et la configuration, et elle est prête pour une exécution immédiate dans l'environnement d'exécution.
+* L'*étape d'exécution* (ou "runtime") fait fonctionner l'application dans l'environnement d'exécution, en lançant un ensemble de [processus](./processes) de l'application associée à la release considérée.
+
+
+
+**Les applications 12 facteurs ont une séparation stricte entre les étapes d'assemblage, de publication et d'exécution.** Par exemple, il est impossible de faire des changements dans le code au moment de son exécution, car il n'y a pas moyen de propager ces changements vers l'étape de build.
+
+Les outils de déploiement offrent généralement des outils de gestion de release, permettant notamment de revenir à une release antérieure. Par exemple, l'outil de déploiement [Capistrano](https://github.com/capistrano/capistrano/wiki) stocke les releases dans un sous-répertoire appelé `releases`, où la release courante est un lien symbolique vers le répertoire de release courante. Sa commande `rollback` permet de facilement revenir à une release précédente.
+
+Chaque release devrait toujours avoir un identifiant unique, comme un horodatage (timestamp) de la release (tel que `2011-04-06-20:32:17`) ou un nombre incrémental (tel que `v100`). Les liste des releases est accessible en écriture uniquement, et il n'est pas possible de modifier une release une fois qu'elle a été réalisée. Tout changement doit créer une nouvelle release.
+
+Les assemblages sont initiées par le développeur de l'application dès que du nouveau code est déployé. Son exécution, au contraire, peut avoir lieu automatiquement en cas d'un reboot du serveur, ou du crash d'un processus qui est relancé par le gestionnaire de processus. De ce fait, l'étape d'exécution doit se limiter à un nombre minimal de parties mobiles, car les problèmes qui empêchent une application de fonctionner peuvent entrainer des dysfonctionnements au milieu de la nuit alors qu'aucun développeur ne sera là pour les corriger. L'étape d'assemblage peut être plus complexe, car les erreurs pourront toujours être résolues par le développeur qui réalise le déploiement.
+
diff --git a/content/fr/codebase.md b/content/fr/codebase.md
new file mode 100644
index 000000000..56030f7d5
--- /dev/null
+++ b/content/fr/codebase.md
@@ -0,0 +1,18 @@
+## I. Base de code
+### Une base de code suivie avec un système de contrôle de version, plusieurs déploiements
+
+Une application 12 facteurs est toujours suivie dans un système de contrôle de version, tel que [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/), ou [Subversion](http://subversion.apache.org/). Une copie de la base de données de suivi des révisions est appelée *dépôt de code*, souvent raccourci en *dépôt*. Le terme anglais *code repository*, raccourci en *repository* et *repo* est également utilisé.
+
+Une *base de code* correspond à chaque dépôt (dans un système de contrôle de version centralisé tel que Subversion), ou tout ensemble de dépôts qui partage un commit racine (dans un système de contrôle de version décentralisé comme Git).
+
+
+
+Il y a toujours un rapport direct entre la base de code et l'application :
+
+* S'il y a plusieurs bases de code, ce n'est pas une application, c'est un système distribué. Chaque composant du système distribué est une application, et chacun peut individuellement respecter la méthodologie 12 facteurs.
+* Plusieurs applications partageant le même code est une violation des 12 facteurs. La solution dans ce cas est de factoriser le code partagé dans des bibliothèques qui peuvent être intégrées via un [gestionnaire de dépendances](./dependencies).
+
+Il y a seulement une base de code par application, mais il y aura plusieurs déploiements de l'application. Un *déploiement* est une instance en fonctionnement de l'application. C'est, par exemple, le site en production, ou bien un ou plusieurs sites de validation. En plus de cela, chaque développeur a une copie de l'application qui fonctionne dans son environnement local de développement, ce qui compte également comme un déploiement.
+
+La base de code est la même à travers tous les déploiements, bien que différentes versions puissent être actives dans chaque déploiement. Par exemple, un développeur a des commits qui ne sont pas encore déployés dans l'environnement de validation. L'environnement de validation a des commits qui ne sont pas encore déployés en production. Par contre, ils partagent tous la même base de code, ce qui les identifie comme étant des déploiements différents d'une même application.
+
diff --git a/content/fr/concurrency.md b/content/fr/concurrency.md
new file mode 100644
index 000000000..0b9123d8d
--- /dev/null
+++ b/content/fr/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. Concurrence
+### Grossissez à l'aide du modèle de processus
+
+Tout programme informatique, lorsqu'il s'exécute, est représenté par un ou plusieurs processus. Les applications web ont adopté différentes approches d'exécution de processus. Par exemple, les processus PHP s'exécutent comme des processus fils d'Apache, démarrés à la demande lorsque c'est requis par le volume de requêtes. Les processus Java ont adopté l'approche inverse, avec une machine virtuelle qui fournit un super-processus massif qui réserve un gros bloc de ressources système (processeur et mémoire) au démarrage, et la concurrence est gérée en interne à l'aide de threads. Dans les deux cas, les processus qui tournent sont à peine visibles aux développeurs de l'application.
+
+
+
+**Dans une application 12 facteurs, les processus sont des élèves modèles**. Les processus dans une application 12 facteurs s'inspirent fortement du [modèle de processus unix pour faire fonctionner les daemon (en)](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). En utilisant ce modèle, les développeurs peuvent structurer l'application pour gérer différents types de charge en assignant chaque type de travail à un *type de processus*. Par exemple, les requêtes HTTP peuvent être gérées par un processus web, et les tâches d'arrière plan ayant une longue durée d'exécution peuvent être des processus dits "worker".
+
+Chaque processus peut malgré tout et individuellement, gérer son propre multiplexage interne, avec des threads à l'intérieur de la machine virtuelle d'exécution, ou à l'aide du modèle d'évènements asynchrone que l'on retrouve dans des outils comme [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/), ou [Node.js](http://nodejs.org/). Mais une machine virtuelle a individuellement une taille limitée (grandissement vertical), donc l'application doit également pouvoir déclencher plusieurs processus qui tournent sur plusieurs machines physiques.
+
+Le modèle de processus prend de l'envergure dès qu'il est question de grossir. La [nature sans partage, avec une partition horizontale des processus des applications 12 facteurs](./processes) signifie qu'ajouter plus de concurrence est une opération simple et fiable. La liste des types de processus et le nombre de processus de chaque type est appelée *formation de processus*.
+
+Les processus des applications 12 facteurs ne devraient [jamais être des daemons (en)](http://dustin.github.com/2010/02/28/running-processes.html) ou écrire des fichiers PID. A la place, utilisez le gestionnaire de processus du système d'exploitation (tel qu'[Upstart](http://upstart.ubuntu.com/), un gestionnaire de processus distribué sur une plateforme cloud, ou un outil comme [Foreman (en)](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) durant le développement) pour gérer les [flux de sortie](./logs), répondre à un processus qui plante, et gérer les redémarrages et les arrêts initiés par les utilisateurs.
diff --git a/content/fr/config.md b/content/fr/config.md
new file mode 100644
index 000000000..94fe08163
--- /dev/null
+++ b/content/fr/config.md
@@ -0,0 +1,22 @@
+## III. Configuration
+### Stockez la configuration dans l'environnement
+
+La *configuration* d'une application est tout ce qui est susceptible de varier entre des [déploiements](./codebase) (validation, production, environnement de développement, etc). Cela inclut :
+
+* Les ressources gérées par la base de données, Memcached, ou tout autre [service de stockage](./backing-services)
+* Les identifiants pour des services externes, tel qu'Amazon S3 ou Twitter
+* Les valeurs spécifiques au déploiement, tel que son nom d'hôte canonique
+
+Les applications stockent parfois la configuration avec des constantes dans le code. C'est une violation des 12 facteurs, qui requiert une **stricte séparation de la configuration et du code**. La configuration peut varier substantiellement à travers les déploiements, alors que ce n'est pas le cas du code.
+
+Un bon moyen de tester si une application a correctement séparé son code, c'est de se demander si l'application pourrait être rendu open-source à tout instant, sans compromettre d'identifiants.
+
+Notez que cette définition de "configuration" n'inclut **pas** la configuration interne de l'application, tel que `config/routes.rb` avec Rails, ou comment [les modules du noyau sont connectés (en)](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) dans [Spring](http://spring.io/). Ce type de configuration ne varie pas à travers les déploiements, et est ainsi mieux réalisé dans le code.
+
+Une autre approche de la configuration, c'est d'utiliser des fichiers de configuration qui ne sont pas inclus dans le système de contrôle de version, comme par exemple `config/database.yml` de Rails. C'est une amélioration considérable par rapport à l'utilisation de constantes qui sont versionnées dans le dépôt de code, mais a toujours des faiblesses : il est facile d'ajouter par inadvertance un fichier de configuration dans le dépôt. Il y a une tendance à ce que les fichiers de configuration soient dispersés à différents endroits et dans différents formats, rendant ainsi difficile de voir et gérer la configuration à un unique endroit. De plus, ces formats ont tendances à être spécifiques à un langage ou un framework.
+
+**Les applications 12 facteurs stockent la configuration dans des *variables d'environnement*** (souvent raccourcies en *variables d'env*, ou *env*). Les variables d'environnement sont faciles à changer entre des déploiements sans changer le moindre code ; contrairement aux fichiers de configuration, il y a peu de chance pour qu'elles soient ajoutées au dépôt de code accidentellement ; et contrairement aux fichiers de configuration personnalisés, ou tout autre mécanisme de configuration comme les propriétés système Java, ce sont des standards agnostiques du langage ou du système d'exploitation.
+
+Un autre aspect de la gestion de configuration est le groupage. Parfois les applications regroupent la configuration dans des groupes nommés (souvent appelés les "environnements"), nommés ainsi d'après des déploiements spécifiques, comme les environnements `development`, `test`, et `production` de Rails. Cette méthode ne permet pas de grossir proprement : lorsque l'on ajoute de nouveaux déploiement à l'application, de nouveaux noms d'environnement sont nécessaires, comme `validation` ou `qa`. Quand le projet grossit encore plus, les développeurs vont avoir tendance à ajouter leur propres environnement particuliers, comme `joes-validation`, ce qui entraine une explosion combinatoire de la configuration qui rend la gestion des déploiement de l'application très fragile.
+
+Dans une application 12 facteurs, les variables d'environnement permettent un contrôle granulaire, chacune complètement orthogonale aux autres variables d'environnement. Elles ne sont jamais groupées ensemble en "environnements", mais sont plutôt gérées indépendamment pour chaque déploiement. C'est un modèle qui permet de grossir verticalement en souplesse, lorsque l'application grossit naturellement en un plus grand nombre de déploiements au cours de sa vie.
diff --git a/content/fr/dependencies.md b/content/fr/dependencies.md
new file mode 100644
index 000000000..548b9903d
--- /dev/null
+++ b/content/fr/dependencies.md
@@ -0,0 +1,12 @@
+## II. Dépendances
+### Déclarez explicitement et isolez les dépendances
+
+La plupart des langages de programmation offrent des systèmes pour créer des paquets à partir de bibliothèques afin de les distribuer, tel que [CPAN](http://www.cpan.org/) pour Perl ou [Rubygems](http://rubygems.org/) pour Ruby. Les bibliothèques installées à travers un système de packaging peuvent être installées à travers tout le système, ou bien limitées au répertoire contenant l'application (que l'on appelle les "vendor" ou "bundles").
+
+**Une application 12 facteurs ne dépend jamais de l'existence implicite de packages au niveau du système**. Elle déclare toutes ses dépendances, complètement et exactement, à travers un manifeste de *déclaration de dépendances*. De plus, elle utilise un outil d'isolation des dépendances durant l'exécution afin d'assurer qu'aucune dépendances implicite ne s'introduise depuis le système environnant. Les spécifications complètes et explicites sont appliquées uniformément en développement comme en production.
+
+Par exemple, [Gem Bundler](http://gembundler.com/) pour Ruby fournit le format de manifeste `Gemfile` pour la déclaration des dépendances, ainsi que la commande `bundle exec` pour l'isolation des dépendances. En python, il y a deux outils séparés pour ces étapes -- [Pip](http://www.pip-installer.org/en/latest/) est utilisé pour la déclaration et [Virtualenv](http://www.virtualenv.org/en/latest/) pour l'isolation. Même le C dispose d'[Autoconf](http://www.gnu.org/s/autoconf/) pour les déclarations de dépendances, et la liaison statique peut fournir l'isolation des dépendances. Peu importe la chaine d'outils, la déclaration et l'isolation des dépendances doivent toujours être utilisées ensemble -- seulement l'un ou l'autre ne suffit pas à satisfaire les 12 facteurs.
+
+Un des bénéfices de la déclaration explicite des dépendances est que cela simplifie la mise en place pour les développeurs qui découvrent l'application. Les nouveaux développeurs peuvent jeter un oeil à la base de code de l'application sur leur machine de développement, en ayant besoin uniquement d'avoir de quoi exécuter le langage ainsi que le gestionnaire de dépendances installé en pré-requis. Ils pourront mettre en place tout ce qui est nécessaire pour faire fonctionner le code de l'application de manière déterministe grâce à une *commande d'assemblage* (commande de build). Par exemple, la commande d'assemblage pour Ruby/Bundler est `bundle install`, alors que pour Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) c'est `lein deps`.
+
+Les applications 12 facteurs ne s'appuient pas sur l'existence implicite d'outils système, comme par exemple ImageMagick ou `curl`. Bien que ces outils puissent exister sur beaucoup voire la plupart des systèmes d'exploitations, il n'y a pas de garantie qu'ils existeront sur tous les systèmes où l'application sera exécutée à l'avenir, ou si la version disponible sur un système futur sera compatible avec l'application. Si l'application dépend d'un outil système, cet outil doit être distribué avec l'application.
diff --git a/content/fr/dev-prod-parity.md b/content/fr/dev-prod-parity.md
new file mode 100644
index 000000000..1d9f85bbb
--- /dev/null
+++ b/content/fr/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Parité dev/prod
+### Gardez le développement, la validation et la production aussi proches que possible
+
+Historiquement, il y a eu un fossé conséquent entre le développement (un développeur qui fait des modifications sur un [déploiement](./codebase) local de l'application) et la production (un déploiement de l'application accessible aux utilisateurs finaux). Ce fossé se manifeste de trois manières :
+
+* **Le fossé temporel** : un développeur peut travailler sur du code qui peut prendre des jours, des semaines ou des mois avant d'aller en production
+* **Le fossé des personnes** : les développeurs écrivent le code, et d'autres personnes le déploient.
+* **Le fossé des outils** : les développeurs peuvent utiliser une pile comme Nginx, SQLite, et OS X, alors que le déploiement de production utilise Apache, MySQL, et Linux.
+
+**Les applications 12 facteurs sont conçues pour le [déploiement continu (en)](http://www.avc.com/a_vc/2011/02/continuous-deployment.html) en gardant un fossé étroit entre le développement et la production.** Si l'on regarde les trois fossés décrits plus haut :
+
+* Réduire le fossé temporel : un développeur peut écrire du code et le déployer quelques heures ou même juste quelques minutes plus tard.
+* Réduire le fossé des personnes : les personnes qui écrivent le code sont impliquées dans son déploiement et pour surveiller son comportement en production
+* Réduire le fossé des outils : réduire, autant que possible, les différences entre le développement et la production
+
+Si l'on résume cela en un tableau :
+
+| + | Application traditionnelle | +Application 12 facteurs | +
|---|---|---|
| Temps entre les déploiements | +Semaines | +heures | +
| Auteurs du code et ceux qui le déploient | +Des personnes différentes | +Les mêmes personnes | +
| L'environnement de développement et celui de production | +Divergents | +Aussi similaires que possible | +
| Type | +Langage | +Librarie | +Adaptateurs | +
|---|---|---|---|
| Base de données | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| File de messages | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Cache | +Ruby/Rails | +ActiveSupport::Cache | +Mémoire, système de fichiers, Memcached | +
+
+Le risorse possono essere collegate e scollegate da un deploy a piacimento. Ad esempio, supponiamo che il database dell'applicazione si comporti in modo anomalo per problemi hardware. L'amministratore potrebbe decidere di voler configurare un altro server di database ripreso da un recente backup. Il vecchio database verrebbe scollegato, quello nuovo connesso -- senza modifiche al codice.
\ No newline at end of file
diff --git a/content/it/build-release-run.md b/content/it/build-release-run.md
new file mode 100644
index 000000000..abe85269d
--- /dev/null
+++ b/content/it/build-release-run.md
@@ -0,0 +1,18 @@
+## V. Build, release, esecuzione
+### Separare in modo netto lo stadio di build dall'esecuzione
+
+Una [codebase](./codebase) viene "trasformata" in deploy attraverso tre fasi:
+
+* la fase di *build*, che converte il codice del repo in una build "eseguibile". Usando una certa versione del codice, ad una specifica commit, nella fase di build vengono compilati i binari con gli asset appropriati includendo anche le eventuali dipendenze;
+* la fase di *release* prende la build prodotta nella fase precedente e la combina con l'attuale insieme di impostazioni di configurazione del deploy specifico. La *release* risultante contiene sia la build che le impostazioni;
+* la fase di *esecuzione* (conosciuta anche come "runtime") vede l'applicazione in esecuzione nell'ambiente di destinazione, attraverso l'avvio di processi della release scelta;
+
+
+
+**Un'app twelve-factor definisce una separazione netta tra build, release ed esecuzione.** Ad esempio, è impossibile effettuare dei cambiamenti del codice a runtime, dato che non c'è modo di propagare queste modifiche all'"indietro", verso la fase di build.
+
+I tool di deploy offrono tipicamente dei tool di gestione delle release, in particolare alcuni dedicati ad un rollback verso una release precedente. Ad esempio, [Capistrano](https://github.com/capistrano/capistrano/wiki) memorizza le varie release in una sotto-directory chiamata `releases`, in cui la release attuale non è che un symlink verso la directory della release attuale. Il comando di rollback permette di tornare indietro ad una certa release velocemente.
+
+Ogni release dovrebbe inoltre possedere un ID univoco di rilascio, come ad esempio un timestamp (es. `2011-04-06-20:32:17`) o un numero incrementale (es. `v100`). In un certo senso, la creazione di una release è una procedura "a senso unico" e una certa release non può essere modificata dopo la sua creazione. Qualsiasi cambiamento deve quindi prevedere una nuova release.
+
+Una fase di build è sempre avviata da uno sviluppatore, non appena il codice viene modificato. Al contrario, l'esecuzione può essere anche gestita in modo automatico (si pensi al riavvio del server oppure ad un crash con successivo riavvio del processo). Ad ogni modo, una volta in esecuzione, la regola aurea è di evitare il più possibile (se non del tutto) modifiche che potrebbero rompere qualche equilibrio. Magari nel bel mezzo della notte, quando non c'è nessuno disponibile. La fase di build può essere sicuramente più "faticosa", comunque, visto che possono verificarsi degli errori da risolvere prima di proseguire.
\ No newline at end of file
diff --git a/content/it/codebase.md b/content/it/codebase.md
new file mode 100644
index 000000000..e4f2c4bf3
--- /dev/null
+++ b/content/it/codebase.md
@@ -0,0 +1,17 @@
+## I. Codebase
+### Una sola codebase sotto controllo di versione, tanti deploy
+
+Un'app conforme alla metodologia twelve-factor è sempre sotto un sistema di controllo di versione, sia essa [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/), o [Subversion](http://subversion.apache.org/). Una copia della codebase è detta *code repository*, oppure più in breve *code repo* o *repo*.
+
+Una *codebase* è quindi un singolo repository (in un sistema centralizzato come Subversion), oppure un set di repo che condividono una root commit (in un sistema di controllo decentralizzato come Git).
+
+
+
+C'è sempre una relazione uno-ad-uno tra codebase ed applicazione:
+
+* Se ci sono più codebase, non si parla più di applicazione ma di sistema distribuito. Ogni componente in un sistema distribuito è un'applicazione, ed ognuna di queste applicazioni può individualmente aderire alla metodologia twelve-factor.
+* Se più applicazioni condividono lo stesso codice si ha una violazione del twelve-factor. La soluzione è, ovviamente, quella di sistemare il codice in modo adeguato, in modo tale da essere incluso eventualmente dove necessario tramite un [dependency manager](./dependencies).
+
+Quindi: una sola codebase per applicazione, ma ci saranno comunque tanti deploy della stessa app. Per *deploy* si intende un'istanza dell'applicazione. Può essere il software in produzione, oppure una delle varie istanze in staging. Ancora, un deploy può essere la copia posseduta dal singolo sviluppatore nel suo ambiente locale.
+
+La codebase rimane comunque sempre la stessa su tutti i deploy, anche se potrebbero essere attive diverse versioni nello stesso istante. Si pensi ad esempio ad uno sviluppatore che possiede dei commit in più che non ha ancora mandato in staging. Nonostante questo, comunque, rimane la condivisione della stessa codebase, nonostante la possibilità di avere più deploy della stessa app.
\ No newline at end of file
diff --git a/content/it/concurrency.md b/content/it/concurrency.md
new file mode 100644
index 000000000..79598ec21
--- /dev/null
+++ b/content/it/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. Concorrenza
+### Scalare attraverso il process model
+
+Ogni software, una volta avviato, è rappresentato da uno o più processi. Le web application in particolare hanno assunto nel tempo una gran varietà di forme e di tipologie di esecuzione, in tal senso. Ad esempio, i processi PHP vengono eseguiti come sotto-processi figli di Apache, avviati su richiesta quando necessari in base al volume di richieste. Java invece gestisce le cose nella maniera opposta, tramite un superprocesso unico che usa una grande quantità di risorse sul server (CPU e memoria) dall'avvio, con una concorrenza gestita "internamente" tramite i threads. In entrambi i casi, comunque, i processi non sono esplicitamente visibili allo sviluppatore.
+
+
+
+**In un'applicazione twelve-factor, i processi sono "first class citizen"**. La visione del concetto di processo prende spunto dal [concetto, in unix, dedicato all'esecuzione di demoni di servizi](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Attraverso l'uso di questo modello, lo sviluppatore può realizzare la propria applicazione in modo tale da farle gestire senza problemi diversi livelli di carico di lavoro, assegnando ogni tipo di lavoro ad un tipo di processo ben definito. Ad esempio, le richieste HTTP possono essere gestite da un web process, mentre dei compiti più lunghi (in background) possono essere gestiti da un altro processo separato.
+
+Questo non esclude che un certo processo, individualmente, possa gestire in modo autonomo ed interno il multiplexing, tramite threading, all'interno della VM in esecuzione, o magari un modello asincrono o basato su eventi come quello di [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/), o [Node.js](http://nodejs.org/). Tuttavia, tutto questo può non bastare: l'applicazione deve essere anche adatta all'esecuzione su più macchine fisiche.
+
+Il modello di processo così come presentato rende il massimo quando arriva il momento di scalare. La [natura orizzontalmente partizionabile (e non soggetta a condivisioni) di un "processo twelve-factor"](./processes) permette di gestire la concorrenza in modo semplice ed affidabile. L'array dei tipi di processo ed il numero di processi presenti per ogni tipo è conosciuto come *process formation* (formazione di processi).
+
+I processi di un'app twelve-factor non dovrebbero [essere soggetti a daemonizing](http://dustin.github.com/2010/02/28/running-processes.html), o scrivere file PID. Al contrario, facendo affidamento sul process manager del sistema operativo (come [Upstart](http://upstart.ubuntu.com/), un process manager distribuito su piattaforma cloud, o tool come [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) durante lo sviluppo) per gestire [gli stream in output](./logs), rispondere adeguatamente a crash di processi e gestire riavvii e shutdown.
diff --git a/content/it/config.md b/content/it/config.md
new file mode 100644
index 000000000..2ef8dc89e
--- /dev/null
+++ b/content/it/config.md
@@ -0,0 +1,22 @@
+## III. Configurazione
+### Memorizza le informazioni di configurazione nell'ambiente
+
+La "configurazione" di un'applicazione è tutto quello che può variare da un [deploy](./codebase) all'altro (staging, production, ambienti di sviluppo). Ad esempio:
+
+* Valori da usare per connettersi ad un database, Memcached, oppure altri [backing service](./backing-services);
+* Credenziali per servizi esterni, come Amazon S3 o Twitter;
+* Valori eventualmente definiti per i singoli deploy, come l'hostname;
+
+Molto spesso, queste informazioni vengono memorizzate come costanti nel codice: la cosa viola la metodologia twelve-factor, che richiede una **separazione ben definita delle impostazioni di configurazione dal codice**. Le impostazioni possono infatti variare da un deploy all'altro: il codice, invece, no.
+
+Il codice dell'applicazione, infatti, potrebbe essere reso open-source in ogni momento: un buon motivo per separare le due cose.
+
+Nota che comunque la definizione di "configurazione" **non** include eventuali configurazione interne dell'applicazione, come `config/routes.rb` in Rails, o come [i moduli di codice sono connessi](http://static.springsource.org/spring/docs/2.5.x/reference/beans.html) in [Spring](http://www.springsource.org/). Questo tipo di configurazione non varia da deploy a deploy: come giusto che sia, quindi, rimane nel codice.
+
+Un ottimo approccio al "rispetto" di questo principio consiste nell'usare dei file di configurazione non coinvolti dal version control, come ad esempio `config/database.yml` in Rails. Stiamo parlando di un miglioramento enorme rispetto all'uso di costanti nel codice, ma c'è da dire la cosa ha il suo lato negativo: basta poco per sbagliarsi ed includere nel repo il file di configurazione che, invece, non dovrebbe essere lì. C'è una certa tendenza, infatti, a non avere tutti i file di configurazione necessari nello stesso posto. Inoltre, i vari formati tendono ad essere collegati ad un certo linguaggio/framework.
+
+**L'applicazione che rispetta la metodologia twelve-factor memorizza tutte le impostazioni in *variabili d'ambiente*** (spesso dette *env vars* o *env*). Le variabili d'ambiente sono molto semplici da cambiare di deploy in deploy senza dover toccare il codice direttamente. Inoltre, a differenza dei file di configurazione classici, c'è una probabilità molto bassa di venire inclusi nel repo. Infine, questi file sono indipendenti sia dal linguaggio che dal sistema operativo utilizzato.
+
+Un altro aspetto del config management è il raggruppamento. A volte, infatti, alcune applicazioni prevedono la memorizzazione delle impostazioni in gruppi (chiamati spesso "ambienti") dal nome ben preciso: "development", "test" e "production", ad esempio. Questo metodo non scala correttamente, se ci pensi: potrebbero essere necessari nuovi ambienti, come "staging" e "qa". Oppure, i vari sviluppatori potrebbero aver bisogno di creare i propri ambienti "speciali", come "joes-staging" e così via. Il risultato? Una quantità di combinazioni ingestibile e disordinata.
+
+In una buona twelve-factor app, le variabili di ambiente sono controllate in modo più "granulare", in modo totalmente ortogonale alle altre. Non sono mai raggruppate e classificate sotto "ambienti" specifici, ma vengono gestite in modo totalmente indipendente per ogni deploy. Il prodotto finale ne risente positivamente in termini di scalabilità.
\ No newline at end of file
diff --git a/content/it/dependencies.md b/content/it/dependencies.md
new file mode 100644
index 000000000..8b86314d2
--- /dev/null
+++ b/content/it/dependencies.md
@@ -0,0 +1,12 @@
+## II. Dipendenze
+### Dipendenze dichiarate ed isolate
+
+Molti linguaggi di programmazione offrono dei sistemi di packaging per la distribuzione delle proprie librerie, come [CPAN](http://www.cpan.org/) per Perl o [Rubygems](http://rubygems.org/) per Ruby. Le librerie installate attraverso questi sistemi, inoltre, possono essere identificate come "system-wide" (attive a livello di sistema), oppure posizionate nella directory della singola applicazione (in questo caso si parla di "vendoring" o "bundling").
+
+**Un'applicazione che aderisce alla twelve-factor non si basa mai sull'esistenza implicita di librerie system-wide**. Le dipendenze vengono tutte dichiarate, tramite un manifest dedicato. Inoltre, viene contemplato anche l'uso di un tool di *isolamento delle dipendenze* durante l'esecuzione, in modo tale da assicurarsi che non ci siano delle "dipendenze implicite" che creino interferenze nel sistema in cui ci si trova. La specifica completa ed esplicita delle dipendenze si applica in modo uniforme: sia in production che in sviluppo.
+
+Ad esempio, [Gem Bundler](http://gembundler.com/) per Ruby offre il supporto di un file-manifesto `Gemfile` da usare per la dichiarazione delle dipendenze e `bundle exec` per il loro isolamento. In Python invece troviamo altri due tool per questi scopi -- [Pip](http://www.pip-installer.org/en/latest/) viene usato per la dichiarazione e [Virtualenv](http://www.virtualenv.org/en/latest/) per l'isolamento. Anche C ha [Autoconf](http://www.gnu.org/s/autoconf/) per la dichiarazione di dipendenze, mentre lo static linking si occupa dell'isolamento. Non importa quale sia il toolchain usato, le operazioni di dichiarazione ed isolamento vanno sempre effettuate. In caso contrario, l'applicazione non aderisce più alla metodologia.
+
+Un altro importante beneficio di una dichiarazione esplicita delle dipendenze sta nel fatto che semplifica di molto la configurazione iniziale per gli sviluppatori appena entrati a lavorare al progetto. Il nuovo arrivato non dovrà fare altro che effettuare un check out della codebase nella propria macchina di sviluppo, occupandosi di dover installare solo ed esclusivamente le dipendenze, appunto, dichiarate. Molto spesso è inoltre presente un *build command* che permette di automatizzare il processo. Per Ruby/Bundler si usa `bundle install`, mentre per Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) c'è `lein deps`.
+
+Ogni applicazione che aderisce alla metodologia twelve-factor, inoltre, non si basa mai sull'esistenza di un qualsiasi tool di sistema. Alcuni esempi sono *ImageMagick* o *curl*. Nonostante questi software esistano già su buona parte dei sistemi in circolazione, non è comunque detto che siano presenti su tutti quelli su cui girerà l'applicazione in futuro. Se l'app non può fare a meno di questo tool, si dovrebbe prendere in considerazione l'idea di "vendorizzarlo" nell'applicazione stessa.
\ No newline at end of file
diff --git a/content/it/dev-prod-parity.md b/content/it/dev-prod-parity.md
new file mode 100644
index 000000000..33b422395
--- /dev/null
+++ b/content/it/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Parità tra Sviluppo e Produzione
+### Mantieni lo sviluppo, staging e produzione simili il più possibile
+
+Storicamente, ci sono sempre state differenze sostanziali tra gli ambienti di sviluppo (lo sviluppatore che effettua delle modifiche live ad un [deploy](./codebase) in locale) e quello di produzione (un deploy in esecuzione raggiungibile dagli utenti finali). Differenze (o gap) che si possono raggruppare in tre categorie:
+
+* **Tempo:** uno sviluppatore può lavorare sul codice per giorni, settimane o mesi prima di poter andare in produzione;
+* **Personale**: gli sviluppatori scrivono il codice, gli ops effettuano il deploy;
+* **Strumenti**: gli sviluppatori potrebbero usare uno stack quale Nginx, SQLite ed OS X, mentre in produzione per il deploy verrebbero installati Apache, MySQL e Linux.
+
+**Un'applicazione twelve-factor è progettata per il [rilascio continuo](http://www.avc.com/a_vc/2011/02/continuous-deployment.html), tenendo così queste differenze al minimo possibile.** A proposito di queste tre tipologie di differenze appena viste:
+
+* Rendi la differenze temporali minime: cerca di scrivere (o far scrivere) del codice da rilasciare nel giro di poche ore, se non minuti;
+* Rendi le differenze a livello di personale minime: fai in modo che gli sviluppatori siano coinvolti anche nella fase di deploy, per permettere loro di osservare il comportamento di ciò che hanno scritto anche in produzione;
+* Rendi le differenze a livello di strumenti minime: mantieni gli ambienti di lavoro il più simile possibile;
+
+Riassumendo tutto in una tabella:
+
+| + | App Tradizionale | +App Twelve-factor | +
|---|---|---|
| Tempo tra i Deploy | +Settimane | +Ore | +
| Sviluppatori e Ops | +Sono diversi | +Sono gli stessi | +
| Sviluppo e Produzione | +Divergenti | +Il più simili possibile | +
| Tipologia | +Linguaggio | +Libreria | +Adattatore | +
|---|---|---|---|
| Database | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Code | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Cache | +Ruby/Rails | +ActiveSupport::Cache | +Memory, filesystem, Memcached | +
+
+リソースは自由にデプロイにアタッチしたり、デプロイからデタッチしたりできる。例えば、ハードウェアの問題によってアプリケーションのデータベースの動作がおかしい場合、アプリケーションの管理者は最新のバックアップから新しいデータベースサーバーを立ち上げる。そして現在の本番データベースをデタッチし、新しいデータベースをアタッチする -- コードを一切変更せずに。
+
diff --git a/content/ja/build-release-run.md b/content/ja/build-release-run.md
new file mode 100644
index 000000000..19cdd5406
--- /dev/null
+++ b/content/ja/build-release-run.md
@@ -0,0 +1,18 @@
+## V. ビルド、リリース、実行
+### ビルド、リリース、実行の3つのステージを厳密に分離する
+
+[コードベース](./codebase)は3つのステージを経て、（開発環境ではない）デプロイへと変換される。
+
+* *ビルドステージ* は、コードリポジトリを *ビルド* と呼ばれる実行可能な塊へと変える変換である。デプロイプロセスで指定したコミットのコードで指定されたバージョンを使って、ビルドステージは[依存関係](./dependencies)を取得してローカル環境に配置し、バイナリやアセットファイルをコンパイルする。
+* *リリースステージ* は、ビルドステージで生成されたビルドを受け取り、それをデプロイの現在の[設定](./config)と結合する。出来上がる *リリース* にはビルドと設定の両方が含まれ、実行環境の中ですぐにでも実行できるよう準備が整う。
+* *実行ステージ* （ランタイムとも呼ばれる）は、選択されたリリースに対して、アプリケーションのいくつかの[プロセス](./processes)を起動することで、アプリケーションを実行環境の中で実行する。
+
+
+
+**Twelve-Factor Appは、ビルド、リリース、実行の3つのステージを厳密に分離する。** 例えば、実行ステージにあるコードを変更してもその変更をビルドステージに伝える方法がないため、コードを実行中に変更することはあり得ない。
+
+デプロイツールは通常、リリース管理ツールを提供する。中でも注目すべきは、以前のリリースにロールバックする機能である。例えばデプロイツールの[Capistrano](https://github.com/capistrano/capistrano/wiki)は、リリースを`releases`という名前のサブディレクトリに格納し、現在のリリースは現在のリリースのディレクトリへのシンボリックリンクとなる。Capistranoの`rollback`コマンドを使うと、簡単かつ即座に以前のリリースにロールバックできる。
+
+すべてのリリースは常に一意のリリースIDを持つべきである。リリースIDの例としては、リリースのタイムスタンプ（例：`2011-04-06-20:32:17`）や連番（例：`v100`）がある。リリースは追記専用の台帳であり、一度作られたリリースは変更することができない。変更する場合は新しいリリースを作らなければならない。
+
+ビルドステージは、新しいコードがデプロイされるときに必ずアプリケーションの開発者によって開始される。一方実行ステージは、サーバーの再起動時や、クラッシュしたプロセスがプロセスマネージャーによって再起動された時に自動で開始される。このため、実行ステージはできるだけ可変部分を持たないようにするべきである。なぜなら、アプリケーションの実行を妨げるような問題が起きると、開発者が待機していない真夜中にアプリケーションが壊れる結果になるためである。ビルドステージはもっと複雑でも構わない。なぜなら、ビルドステージのエラーは常にデプロイを実行している開発者の目の前で発生するためである。
diff --git a/content/ja/codebase.md b/content/ja/codebase.md
new file mode 100644
index 000000000..5bc86cb93
--- /dev/null
+++ b/content/ja/codebase.md
@@ -0,0 +1,17 @@
+## I. コードベース
+### バージョン管理されている1つのコードベースと複数のデプロイ
+
+Twelve-Factor Appは[Git](http://git-scm.com/)や[Mercurial](http://mercurial.selenic.com/)、[Subversion](http://subversion.apache.org/)などのバージョン管理システムで常に変更を追跡している。リビジョン追跡データベースのコピーは *コードリポジトリ* と言われ、単に *リポジトリ* とも言われる。
+
+*コードベース* は、単一のリポジトリ（Subversionのような集中バージョン管理システムの場合）またはルートコミットを共有する複数のリポジトリ（Gitのような分散バージョン管理システムの場合）である。
+
+
+
+コードベースとアプリケーションの間には、常に1対1の関係がある。
+
+* もし複数のコードベースがある場合、それはアプリケーションではない -- それは分散システムである。分散システムのそれぞれのコンポーネントがアプリケーションであり、個別にTwelve-Factorに適合することができる。
+* 同じコードを共有する複数のアプリケーションは、Twelve-Factorに違反している。その場合の解決策は、共通のコードをライブラリに分解し、そのライブラリを[依存関係管理ツール](./dependencies)で組み込むようにすることである。
+
+アプリケーションごとにただ1つのコードベースが存在するが、アプリケーションのデプロイは複数存在する。 *デプロイ* はアプリケーションの実行中のインスタンスである。これは通常1つの本番サイトと、1つ以上のステージングサイトである。さらにすべての開発者はローカル開発環境で動作するアプリケーションのコピーを持っており、それらもデプロイと見なせる。
+
+デプロイごとに異なるバージョンがアクティブであるかもしれないが、コードベースはすべてのデプロイを通して同一である。例えば、開発者はステージング環境にまだデプロイされていないコミットを抱えているし、ステージング環境には本番環境にデプロイされていないコミットが含まれている。しかし、これらのデプロイはすべて同一のコードベースを共有しているため、同一のアプリケーションの異なるデプロイであると認識できる。
diff --git a/content/ja/concurrency.md b/content/ja/concurrency.md
new file mode 100644
index 000000000..8daf90366
--- /dev/null
+++ b/content/ja/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. 並行性
+### プロセスモデルによってスケールアウトする
+
+すべてのコンピュータープログラムは、一度実行されると、1つ以上のプロセスとして表される。Webアプリケーションでは様々なプロセス実行形態がとられてきた。例えば、PHPのプロセスはApacheの子プロセスとして実行され、リクエスト量に応じて起動される。Javaプロセスは反対の方法をとる。JVMが1つの巨大な親プロセスを提供し、起動時にシステムリソース（CPUやメモリ）の大きなブロックを確保し、スレッドを使って内部的に並行性を管理する。どちらの場合でも、実行されるプロセスはアプリケーションの開発者にはほとんど見えない。
+
+
+
+**Twelve-Factor Appではプロセスは第一級市民である。** Twelve-Factor Appにおけるプロセスの考え方は、[サービスのデーモンを実行するためのUnixプロセスモデル](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/)から大きなヒントを得ている。このモデルを使い、個々のワークロードの種類を *プロセスタイプ* に割り当てることで、開発者はアプリケーションが多様なワークロードを扱えるように設計することができる。例えば、HTTPリクエストはWebプロセスによって処理し、時間のかかるバックグラウンドタスクはワーカープロセスによって処理することができる。
+
+このモデルは、ランタイムVM内のスレッドや、[EventMachine](http://rubyeventmachine.com/)、[Twisted](http://twistedmatrix.com/trac/)、[Node.js](http://nodejs.org/)などの非同期イベントモデルによって、個々のプロセスがプロセス内部で多重化することを禁止するわけではない。しかし個々のVMはそれほど大きくなる（垂直にスケールする）ことができないため、アプリケーションは複数の物理マシンで動作する複数のプロセスへと拡大できなければならない。
+
+このプロセスモデルが真価を発揮するのは、スケールアウトが必要になったときである。[シェアードナッシングで水平分割可能なTwelve-Factor Appプロセスの性質](./processes)は、並行性を高める操作が単純かつ確実なものであることを意味する。プロセスタイプとそれぞれのタイプのプロセス数の配列は、 *プロセスフォーメーション* と言われる。
+
+Twelve-Factor Appのプロセスは[決してデーモン化するべきではないし](http://dustin.github.com/2010/02/28/running-processes.html)、PIDファイルを書き出すべきではない。その代わりに、OSのプロセスマネージャー（例：[Upstart](http://upstart.ubuntu.com/)、クラウドプラットフォームの分散プロセスマネージャー、あるいは開発環境における[Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html)のようなツール）を頼ることで、[出力ストリーム](./logs)を管理し、プロセスのクラッシュに対応し、ユーザーによる再起動やシャットダウンを処理すべきである。
diff --git a/content/ja/config.md b/content/ja/config.md
new file mode 100644
index 000000000..6c8e43c32
--- /dev/null
+++ b/content/ja/config.md
@@ -0,0 +1,22 @@
+## III. 設定
+### 設定を環境変数に格納する
+
+アプリケーションの *設定* は、[デプロイ](./codebase)（ステージング、本番、開発環境など）の間で異なり得る唯一のものである。設定には以下のものが含まれる。
+
+* データベース、Memcached、他の[バックエンドサービス](./backing-services)などのリソースへのハンドル
+* Amazon S3やTwitterなどの外部サービスの認証情報
+* デプロイされたホストの正規化されたホスト名など、デプロイごとの値
+
+アプリケーションは時に設定を定数としてコード内に格納する。これはTwelve-Factorに違反している。Twelve-Factorは **設定をコードから厳密に分離すること** を要求する。設定はデプロイごとに大きく異なるが、コードはそうではない。
+
+アプリケーションがすべての設定をコードの外部に正しく分離できているかどうかの簡単なテストは、認証情報を漏洩させることなく、コードベースを今すぐにでもオープンソースにすることができるかどうかである。
+
+なお、この“設定”の定義には、アプリケーション内部の設定は **含まない** ことに注意する。内部の設定とは、Railsにおける`config/routes.rb`や、[Spring](http://spring.io/)において[コードモジュールがどう接続されるか](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html)などの設定を指す。この種の設定はデプロイの間で変わらないため、コードの内部で行うべきである。
+
+設定に対するもう1つのアプローチは、バージョン管理システムにチェックインされない設定ファイルを使う方法である。例として、Railsにおける`config/database.yml`がある。この方法は、リポジトリにチェックインされる定数を使うことに比べると非常に大きな進歩であるが、まだ弱点がある。設定ファイルが誤ってリポジトリにチェックインされやすいことと、設定ファイルが異なる場所に異なるフォーマットで散乱し、すべての設定を一つの場所で見たり管理したりすることが難しくなりがちであることである。その上、これらのフォーマットは言語やフレームワークに固有のものになりがちである。
+
+**Twelve-Factor Appは設定を *環境変数* に格納する。** 環境変数は、コードを変更することなくデプロイごとに簡単に変更できる。設定ファイルとは異なり、誤ってリポジトリにチェックインされる可能性はほとんどない。また、独自形式の設定ファイルやJava System Propertiesなど他の設定の仕組みとは異なり、環境変数は言語やOSに依存しない標準である。
+
+設定管理のもう1つの側面はグルーピングである。アプリケーションは設定を名前付きのグループ（しばしば“環境”と呼ばれる）にまとめることがある。グループは、Railsにおける`development`、`test`、`production`環境のように、デプロイの名前を取って名付けられる。この方法はうまくスケールしない。アプリケーションのデプロイが増えるにつれて、新しい環境名（`staging`や`qa`）が必要になる。さらにプロジェクトが拡大すると、開発者は`joes-staging`のような自分用の環境を追加する。結果として設定が組み合わせ的に爆発し、アプリケーションのデプロイの管理が非常に不安定になる。
+
+Twelve-Factor Appの場合、環境変数は粒度の細かい管理であり、それぞれの環境変数は互いに直交している。環境変数は“環境”としてまとめられることはないが、代わりにデプロイごとに独立して管理される。これは、アプリケーションのライフサイクルに渡って、アプリケーションが多くのデプロイへと自然に拡大していくにつれて、スムーズにスケールアップするモデルである。
diff --git a/content/ja/dependencies.md b/content/ja/dependencies.md
new file mode 100644
index 000000000..2bc89dc1b
--- /dev/null
+++ b/content/ja/dependencies.md
@@ -0,0 +1,12 @@
+## II. 依存関係
+### 依存関係を明示的に宣言し分離する
+
+ほとんどのプログラミング言語は、サポートライブラリを配布するためのパッケージ管理システムを提供している。例えば、Perlにおける[CPAN](http://www.cpan.org/)やRubyにおける[Rubygems](http://rubygems.org/)などである。パッケージ管理システムでインストールされるライブラリは、システム全体（“site packages”と言われる）にインストールされる場合と、アプリケーションを含むディレクトリのスコープ（“vendoring”または“bundling”と言われる）にインストールされる場合がある。
+
+**Twelve-Factor Appは、システム全体にインストールされるパッケージが暗黙的に存在することに決して依存しない。** すべての依存関係を *依存関係宣言* マニフェストで完全かつ厳密に宣言する。さらに、実行時には *依存関係分離* ツールを使って、取り囲んでいるシステムから暗黙の依存関係が“漏れ出ない”ことを保証する。完全かつ明示的な依存関係の指定は、本番環境と開発環境の両方に対して同様に適用される。
+
+例えば、Rubyで使われる[Gem Bundler](http://gembundler.com/) は、依存関係宣言のためのマニフェストのフォーマットである`Gemfile`と依存関係分離のための`bundle exec`を提供している。Pythonではこれらのステップで2つの別々のツールが使われる -- [Pip](http://www.pip-installer.org/en/latest/)が宣言のために使われ、[Virtualenv](http://www.virtualenv.org/en/latest/)が分離のために使われる。C言語でも[Autoconf](http://www.gnu.org/s/autoconf/)で依存関係を宣言し、静的リンクで依存関係を分離することができる。ツールが何であれ、依存関係の宣言と分離は常に一緒に使わなければならない -- どちらか片方だけではTwelve-Factorを満足するのに不十分である。
+
+明示的に依存関係を宣言する利点の1つは、アプリケーションに新しい開発者が加わった際のセットアップを単純化できることである。新しい開発者は、言語のランタイムと依存関係管理ツールさえインストールされていれば、アプリケーションのコードベースを自分の開発マシンにチェックアウトすることができる。開発者は決められた *ビルドコマンド* で、アプリケーションのコードを実行するために必要なすべてのものをセットアップできる。例えば、Ruby/Bundlerのビルドコマンドは`bundle install`であり、Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme)では`lein deps`である。
+
+また、Twelve-Factor Appは、いかなるシステムツールの暗黙的な存在にも依存しない。例として、アプリケーションからImageMagickや`curl`を使う場合がある。これらのツールはほとんどのシステムに存在するだろうが、アプリケーションが将来に渡って実行され得るすべてのシステムに存在するかどうか、あるいは将来のシステムでこのアプリケーションと互換性のあるバージョンが見つかるかどうかについては何の保証もない。アプリケーションがシステムツールを必要とするならば、そのツールをアプリケーションに組み込むべきである。
diff --git a/content/ja/dev-prod-parity.md b/content/ja/dev-prod-parity.md
new file mode 100644
index 000000000..eda082101
--- /dev/null
+++ b/content/ja/dev-prod-parity.md
@@ -0,0 +1,78 @@
+## X. 開発/本番一致
+### 開発、ステージング、本番環境をできるだけ一致させた状態を保つ
+
+歴史的に、開発環境（開発者が直接変更するアプリケーションのローカル[デプロイ](./codebase)）と本番環境（エンドユーザーからアクセスされるアプリケーションの実行中デプロイ）の間には大きなギャップがあった。これらのギャップは3つの領域で現れる。
+
+* **時間のギャップ**: 開発者が編集したコードが本番に反映されるまで数日、数週間、時には数ヶ月かかることがある。
+* **人材のギャップ**: 開発者が書いたコードを、インフラエンジニアがデプロイする。
+* **ツールのギャップ**: 本番デプロイではApache、MySQL、Linuxを使うのに、開発者がNginx、SQLite、OS Xのようなスタックを使うことがある。
+
+**Twelve-Factor Appでは、[継続的デプロイ](http://www.avc.com/a_vc/2011/02/continuous-deployment.html)しやすいよう開発環境と本番環境のギャップを小さく保つ。** 上で述べた3つのギャップを見る。
+
+* 時間のギャップを小さくする: 開発者が書いたコードは数時間後、さらには数分後にはデプロイされる。
+* 人材のギャップを小さくする: コードを書いた開発者はそのコードのデプロイに深く関わり、そのコードの本番環境での挙動をモニタリングする。
+* ツールのギャップを小さくする: 開発環境と本番環境をできるだけ一致させた状態を保つ。
+
+上で述べたことを表にまとめる。
+
+| + | 伝統的なアプリケーション | +Twelve-Factor App | +
|---|---|---|
| デプロイの間隔 | +数週間 | +数時間 | +
| コードを書く人とデプロイする人 | +異なる人 | +同じ人 | +
| 開発環境と本番環境 | +異なる | +できるだけ一致 | +
| 種類 | +言語 | +ライブラリ | +アダプター | +
|---|---|---|---|
| データベース | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| キュー | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| キャッシュ | +Ruby/Rails | +ActiveSupport::Cache | +メモリ, ファイルシステム, Memcached | +
+
+리소스는 자유롭게 배포에 연결되거나 분리될 수 있습니다. 예를 들어, 애플리케이션의 데이터베이스가 하드웨어 이슈로 작용이 이상한 경우, 애플리케이션의 관리자는 최신 백업에서 새로운 데이터베이스 서버를 시작시킬 것입니다. 그리고 코드를 전혀 수정하지 않고 현재 운영에 사용하고 있는 데이터베이스를 분리하고 새로운 데이터베이스를 연결할 수 있습니다.
\ No newline at end of file
diff --git a/content/ko/build-release-run.md b/content/ko/build-release-run.md
new file mode 100644
index 000000000..60347e180
--- /dev/null
+++ b/content/ko/build-release-run.md
@@ -0,0 +1,19 @@
+## V. 빌드, 릴리즈, 실행
+### 철저하게 분리된 빌드와 실행 단계
+
+[코드베이스](./codebase)는 3 단계를 거쳐 (개발용이 아닌) 배포로 변환됩니다.
+
+* *빌드 단계*는 코드 저장소를 코드 저장소를 *빌드*라는 실행 가능한 번들로 변환시키는 단계입니다. 빌드 단계에서는 커밋된 코드 중 배포 프로세스에서 지정된 버전을 사용하며, [종속성](./dependencies)를 가져와 바이너리와 에셋들을 컴파일합니다.
+* *릴리즈 단계*에서는 빌드 단계에서 만들어진 빌드와 배포의 현재 [설정](./config)을 결합 합니다. 완성된 *릴리즈*는 빌드와 설정을 모두 포함하며 실행 환경에서 바로 실행될 수 있다도록 준비됩니다.
+* *실행 단계*(런타임이라고도 하는)에서는 선택된 릴리즈에 대한 애플리케이션 [프로세스](./processes)의 집합을 시작하여, 애플리케이션을 실행 환경에서 돌아가도록 합니다.
+
+
+
+
+**Twelve-Factor App은 빌드, 릴리즈, 실행 단계를 엄격하게 서로 분리합니다.** 예를 들어, 실행 단계에서 코드를 변경할 수는 없습니다. 변경을 실행 단계보다 앞에 있는 빌드 단계로 전달할 수 있는 방법이 없기 때문입니다.
+
+배포 도구는 일반적으로 릴리즈 관리 도구를 제공합니다. 특히 주목할만한 점은 이전 릴리즈로 되돌릴 수 있는 롤백 기능입니다. 예를 들어, [Capistrano](https://github.com/capistrano/capistrano/wiki)는 배포 툴은 릴리즈를 `releases`라는 하위 디렉토리에 저장시키고, 현재 릴리즈는 현재 릴리즈 디렉토리로 심볼릭 링크로 연결합니다. 이 툴의 `rollback` 명령어는 이전 버전으로 쉽고 빠르게 이전 릴리즈로 롤백할 수 있도록 해줍니다.
+
+모든 릴리즈는 항상 유니크한 릴리즈 아이디를 지녀야 합니다. 예를 들어, 릴리즈의 타임 스템프(예: 2011-04-06-20:32:17)나 증가하는 번호(예: v100, v101)가 있습니다. 릴리즈는 추가만 될 수 있으며, 한번 만들어진 릴리즈는 변경될 수 없습니다. 모든 변경은 새로운 릴리즈를 만들어야 합니다.
+
+빌드는 새로운 코드가 배포 될 때마다 개발자에 의해 시작됩니다. 반면, 실행 단계는 서버가 재부팅되거나 충돌이 발생한 프로세스가 프로세스 매니저에 의해 재시작 되었을 때 자동으로 실행될 수 있습니다. 따라서 대응할 수 있는 개발자가 없는 한밤중에 문제가 발생하는 것을 방지하기 위해, 실행 단계는 최대한 변화가 적어야합니다. 빌드 단계는 좀 더 복잡해져도 괜찮습니다. 항상 배포를 진행하고 있는 개발자의 눈 앞에서 에러가 발생하기 때문입니다.
diff --git a/content/ko/codebase.md b/content/ko/codebase.md
new file mode 100644
index 000000000..fc4e4ae17
--- /dev/null
+++ b/content/ko/codebase.md
@@ -0,0 +1,17 @@
+## I. 코드베이스
+### 버전 관리되는 하나의 코드베이스와 다양한 배포
+
+Twelve-Factor 앱은 항상 [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/), [Subversion](http://subversion.apache.org/) 같은 버전 컨트롤 시스템을 사용하여 변화를 추적하며, 버전 추적 데이터베이스의 사본을 *코드 저장소*, 줄여서 *저장소*라고 부른다.
+
+*코드베이스*는 단일 저장소(Subversion 같은 중앙 집중식 버전 관리 시스템의 경우) 일수도 있고, 루트 커밋을 공유하는 여러 저장소(Git 같은 분산 버전 관리 시스템)일수도 있다.
+
+
+
+코드베이스와 앱 사이에는 항상 1대1 관계가 성립된다.
+
+* 코드베이스가 여러개 있는 경우, 앱이 아니라 분산 시스템으로 봐야한다. 분산 시스템의 개별 구성요소가 앱이 되며, 개별 앱이 Twelve-Factor를 따른다.
+* 여러개 앱이 동일한 코드를 공유한다면 Twelve-Factor를 위반하는것이다. 이를 해결하려면 공유하는 코드를 라이브러리화 시키고, 해당 라이브러리를 [종속성 매니저](/dependencies)로 관리한다.
+
+앱의 코드베이스는 한개여야 하지만, 앱 배포는 여러개가 될수 있다. *배포*는 앱의 실행중인 인스턴스를 가리킨다. 보통 운영 사이트와 여러 스테이징 사이트가 여기에 해당한다. 모든 개발자는 자신의 로컬 개발 환경에 실행되는 앱을 가지고 있는데, 이것 역시 하나의 배포로 볼 수 있다.
+
+배포마다 다른 버전이 활성화 될수 있지만, 코드베이스 자체는 모든 배포에 대해 동일하다. 예를 들어, 개발자는 아직 스테이징 환경에 배포하지 않은 커밋이 있을 수 있으며, 스테이징 환경에는 아직 운영 환경에 배포되지 않은 커밋이 있을 수 있다. 하지만 이 모든 것들이 같은 코드베이스를 공유하고, 같은 앱의 다른 배포라고 할 수 있다.
\ No newline at end of file
diff --git a/content/ko/concurrency.md b/content/ko/concurrency.md
new file mode 100644
index 000000000..2603057f8
--- /dev/null
+++ b/content/ko/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. 동시성(Concurrency)
+### 프로세스 모델을 통한 확장
+
+모든 컴퓨터 프로그램은 실행되면 하나 이상의 프로세스로 표현됩니다. 웹 애플리케이션은 다양한 프로세스 실행 형태를 취해왔습니다. 예를 들어, PHP 프로세스는 Apache의 자식 프로세스로 실행되며, request의 양에 따라 필요한 만큼 시작됩니다. 자바 프로세스들은 반대 방향에서의 접근법을 취합니다. JVM은, 시작될 때 큰 시스템 리소스(CPU와 메모리) 블록을 예약하는 하나의 거대한 부모 프로세스를 제공하고, 내부 쓰레드를 통해 동시성(concurrency)을 관리합니다. 두 경우 모두 실행되는 프로세스는 애플리케이션 개발자에게 최소한으로 노출됩니다.
+
+
+
+**Twelve-Factor App에서 프로세스들은 일급 시민입니다.** Twelve-Factor App에서의 프로세스는 [서비스 데몬들을 실행하기 위한 유닉스 프로세스 모델](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/)에서 큰 힌트를 얻었습니다. 이 모델을 사용하면 개발자는 애플리케이션이 작업을 적절한 *프로세스 타입*에 할당함으로서 다양한 작업 부하를 처리할 수 있도록 설계할 수 있습니다. 예를 들어, HTTP 요청은 웹 프로세스가 처리하며, 오래 걸리는 백그라운드 작업은 worker 프로세스가 처리하도록 할 수 있습니다.
+
+이는 런타임 VM 내부의 쓰레드나 [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/), [Node.js](http://nodejs.org/)에서 구성된 것 처럼 async/evented 모델처럼 개별 프로세스가 내부적으로 동시에 처리하는 것을 금지하는 것은 아닙니다. 하지만 개별 VM이 너무 커질 수 있습니다.(수직 확장) 따라서 애플리케이션은 여러개의 물리적인 머신에서 돌아가는 여러개의 프로세스로 넓게 퍼질 수 있어야만 합니다.
+
+프로세스 모델이 진정으로 빛나는 것은 수평적으로 확장하는 경우입니다. [아무것도 공유하지 않고, 수평으로 분할할 수 있는 Twelve-Factor App 프로세스의 성질](.processes)은 동시성을 높이는 것은 간단하고 안정적인 작업이라는 것을 의미 합니다. 프로세스의 타입과 각 타입별 프로세스의 갯수의 배치를 *프로세스 포메이션*이라고 합니다.
+
+Twelve-Factor App 프로세스는 [절대 데몬화해서는 안되며](http://dustin.github.com/2010/02/28/running-processes.html) PID 파일을 작성해서는 안됩니다. 대신, OS의 프로세스 관리자(예: [Upstart](http://upstart.ubuntu.com/))나 클라우드 플랫폼의 분산 프로세스 매니저, 혹은 [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) 같은 툴에 의존하여 [아웃풋 스트림](./logs)을 관리하고, 충돌이 발생한 프로세스에 대응하고, 재시작과 종료를 처리해야 합니다.
diff --git a/content/ko/config.md b/content/ko/config.md
new file mode 100644
index 000000000..3bedff6d3
--- /dev/null
+++ b/content/ko/config.md
@@ -0,0 +1,22 @@
+## III. 설정
+### 환경(environment)에 저장된 설정
+
+애플리케이션의 *설정*은 [배포](./codebase) (staging, production, 개발 환경 등) 마다 달라질 수 있는 모든 것들입니다. 설정에는 다음이 포함됩니다.
+
+* 데이터베이스, memcached 등 [백엔드 서비스](./backing-services)들의 리소스 핸들
+* Amazon S3 이나 트위터 등의 외부 서비스 인증 정보
+* 배포된 호스트의 정규화된 호스트 이름(canonical hostname)처럼 각 배포마다 달라지는 값
+
+애플리케이션은 종종 설정을 상수로 코드에 저장합니다. 이것은 Twelve-Factor를 위반하며, Twelve-Factor는 **설정을 코드에서 엄격하게 분리하는 것**을 요구합니다. 설정은 배치마다 크게 다르지만, 코드는 그렇지 않습니다.
+
+애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 테스트는 어떠한 인증정보도 유출시키지 않고 코드베이스가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것입니다.
+
+이 "설정"의 정의는 애플리케이션 내부 설정을 *포함하지 않는다는 점*에 유의해야 합니다. Rails의 `config/routes.rb`이나 [Spring](http://spring.io/)의 ["어떻게 코드 모듈이 연결되는 가](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html)과 같은 설정들은 배치 사이에서 변하지 않기 때문에 코드의 내부에 있는 것이 가장 좋습니다.
+
+설정에 대한 또 다른 접근방식은 Rails의 `config/database.yaml`처럼 버전 관리 시스템에 등록되지 않은 설정 파일을 이용하는 것입니다. 이 방법은 코드 저장소에 등록된 상수를 사용하는 것에 비하면 매우 큰 발전이지만, 설정 파일이 여러 위치에 여러 포맷으로 흝어지고 모든 설정을 한 곳에서 확인하고 관리하기 어렵게 만드는 경향이 있습니다. 게다가, 이러한 형식들은 언어와 프레임워크을 따라가는 경향이 있습니다.
+
+**Twelve-Factor App은 설정을 *환경 변수*** (envvars나 env라고도 불림)에 저장합니다. 환경 변수는 코드 변경 없이 쉽게 배포 때마다 쉽게 변경할 수 있습니다. 설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮습니다. 또한, 커스텀 설정 파일이나 Java System Property와 같은 다른 설정 매커니즘과 달리 언어나 OS에 의존하지 않는 표준입니다.
+
+설정 관리의 다른 측면은 그룹핑입니다. 종종 애플리케이션은 설정을 명명된 그룹("environments"라고도 함)으로 구성하기도 합니다. 해당 그룹은 Rails의 'development', 'test', 'production' environments처럼, 배포의 이름을 따서 명명됩니다. 이 방법은 깔끔하게 확장하기 어렵습니다. 응용 프로그램의 배포가 증가함에 따라, 'staging'이라던가 'qa'같은 새로운 그룹의 이름이 필요하게 됩니다. 프로젝트가 성장함에 따라, 개발자은 자기 자신의 그룹를 추가하게 됩니다. 결과적으로 설정이 각 그룹의 조합으로 폭발하게 되고, 애플리케이션의 배포를 불안정하게 만듭니다.
+
+Twelve-Factor App에서 환경 변수는 매우 정교한 관리이며, 각각의 환경변수는 서로 직교합니다. 환경 변수는 "environments"로 절대 그룹으로 묶이지 않지만, 대신 각 배포마다 독립적으로 관리됩니다. 이 모델은 애플리케이션의 수명주기를 거치는 동안 더 많은 배포로 원활하게 확장해 나갈 수 있습니다.
diff --git a/content/ko/dependencies.md b/content/ko/dependencies.md
new file mode 100644
index 000000000..66ffb5e2b
--- /dev/null
+++ b/content/ko/dependencies.md
@@ -0,0 +1,12 @@
+## II. 종속성
+### 명시적으로 선언되고 분리된 종속성
+
+대부분의 프로그래밍 언어는 라이브러리 배포를 위한 패키징 시스템을 제공하고 있습니다. Perl의 [CPAN](http://www.cpan.org/) 이나 Ruby의 [Rubygems](http://rubygems.org/)가 그 예입니다. 라이브러리는 패키징 시스템을 통해 시스템 전체(site pakages)나 애플리케이션을 포함한 디렉토리(vendoring 혹은 bundling)에 설치될 수 있습니다.
+
+**Twelve-Factor App은 전체 시스템에 특정 패키지가 암묵적으로 존재하는 것에 절대 의존하지 않습니다.** *종속선 선언* mainifest를 이용하여 모든 종속성을 완전하고 엄격하게 선언합니다. 더나아가, *종속성 분리* 툴을 사용하여 실행되는 동안 둘러싼 시스템으로 암묵적인 종속성 "유출"이 발생하지 않는 것을 보장합니다. 이런 완전하고 명시적인 종속성의 명시는 개발과 서비스 모두에게 동일하게 적용됩니다.
+
+예를 들어, 루비에서 사용되는 [Gem Bundler](http://gembundler.com/)는 종속성 선언을 위해 `Gemfile` manifest 포맷을 지원하며, 종속성 분리를 위해 `bundle exec`를 지원합니다. 파이썬에는 이를 지원하기 위한 2가지 도구가 있습니다. [Pip](http://www.pip-installer.org/en/latest/)은 종속성 선언을 위해 사용되며, [Virtualenv](http://www.virtualenv.org/en/latest/)는 종속성 분리를 위해 사용됩니다. 심지어 C에도 종속성 분리를 위해 [Autoconf](http://www.gnu.org/s/autoconf/)가 있으며, static link를 활용해 종속선 분리도 가능합니다. 어떤 툴체인을 사용하든, 종속석 선언과 분리는 항상 같이 사용되어야 합니다. 하나만 사용하는 것은 Twelve-Factor에 만족하는 데 불충분합니다.
+
+명시적인 종속성 선언의 장점 중 하나는 애플리케이션 개발에 새로 참가하게 된 개발자가 설치를 간단하게 할 수 있다는 점입니다. 새로 참가한 개발자는 애플리케이션의 코드베이스를 개발 머신에 체크아웃 하고, 언어의 런타임과 종속성 매니저만 미리 설치하면 됩니다. 개발자는 정해져있는 *빌드 명령어*만 입력하면 응용 프로그램의 코드를 실행하는 데 필요한 모든 것을 설치할 수 있습니다. 예를 들어, Ruby의 빌드 명령어는 `bundle install`이며, Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme)에서는 `lein deps`입니다.
+
+Twelve-Factor App은 어떠한 시스템 도구에도 암시적으로 의존하지 않습니다. 예를 들어, ImageMagick이나 `curl`을 사용하는 경우가 있습니다. 이러한 툴들은 대부분의 시스템에 존재하지만, 모든 시스템에 존재하는 것이 보장되는 것은 아닙니다. 미래의 시스템에서는 존재하지 않을 수 있으며, 호환되는 버전이 있으라는 보장도 없습니다. 애플리케이션에게 시스템 도구가 필요하다면, 그 도구를 애플리케이션과 통합해야 합니다.
\ No newline at end of file
diff --git a/content/ko/dev-prod-parity.md b/content/ko/dev-prod-parity.md
new file mode 100644
index 000000000..0fb1be33a
--- /dev/null
+++ b/content/ko/dev-prod-parity.md
@@ -0,0 +1,78 @@
+## X. dev/prod 일치
+### development, staging, production 환경을 최대한 비슷하게 유지
+
+역사적으로, 개발 환경(애플리케이션의 개발자가 직접 수정하는 로컬의 [배포](./codebase))과 production 환경(최종 사용자가 접근하게 되는 실행 중인 배포) 사이에는 큰 차이가 있었습니다. 이러한 차이는 3가지 영역에 걸처 나타납니다.
+
+* **시간의 차이**: 개발자가 작업한 코드는 production에 반영되기까지 며칠, 몇주, 때로는 몇개월이 걸릴 수 있습니다.
+* **담당자의 차이**: 개발자는 작성한 코드를 시스템 엔지니어가 배포합니다.
+* **툴의 차이**: production 배포는 아파치, MySQL, 리눅스를 사용하는데, 개발자는 Nginx, SQLite, OS X를 사용할 수 있습니다.
+
+**Twelve Factor App은 개발 환경과 production 환경의 차이를 작게 유지하여 [지속적인 배포](http://www.avc.com/a_vc/2011/02/continuous-deployment.html)가 가능하도록 디자인 되었습니다. 위에서 언급한 3가지 차이에 대한 대응책은 아래와 같습니다.
+
+* 시간의 차이을 최소화: 개발자가 작성한 코드는 몇 시간, 심지어 몇 분 후에 배포됩니다.
+* 담당자의 차이를 최소화: 코드를 작성한 개발자들이 배포와 production에서의 모니터링에 깊게 관여합니다.
+* 툴의 차이를 최소화: 개발과 production 환경을 최대한 비슷하게 유지합니다.
+
+위의 내용을 표로 요약하면 아래와 같습니다.
+Summarizing the above into a table:
+
+| + | 전통적인 애플리케이션 | +Twelve-Factor App | +
|---|---|---|
| 배포 간의 간격 | +몇 주 | +몇 시간 | +
| 코드 작성자와 코드 배포자 | +다른 사람 | +같은 사람 | +
| 개발 환경과 production 환경 | +불일치함 | +최대한 유사함 | +
| Type | +Language | +Library | +Adapters | +
|---|---|---|---|
| Database | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Queue | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Cache | +Ruby/Rails | +ActiveSupport::Cache | +Memory, filesystem, Memcached | +
+
+Zasoby mogą być dołączane i odłączane jeśli zajdzie taka potrzeba. W momencie gdy baza danych aplikacji z powodu usterek sprzętowych nie działa poprawnie, administrator może przełączyć bazę danych aplikacji na nowy serwer odtworzoną z ostatniego zapisu przywracania danych. Obecna produkcyjna baza może więc zostać przełączona bez żadnych zmian w kodzie aplikacji.
+
diff --git a/content/pl/build-release-run.md b/content/pl/build-release-run.md
new file mode 100644
index 000000000..30d950da9
--- /dev/null
+++ b/content/pl/build-release-run.md
@@ -0,0 +1,18 @@
+## V. Buduj, publikuj, uruchamiaj
+### Oddzielaj etap budowania od uruchamiania
+
+[Codebase](./codebase) jest przetwarzany we wdrożenie w trzech etapach (poza lokalnym środowiskiem).
+
+* Podczas *etapu budowania* kod z repozytorium konwertowany jest do wykonywalnej paczki tzw. *buildu*. Używając wersji kodu zdefiniowanej przez commit w procesie deploymentu, w tym etapie pobiera i dołącza się do projektu [zależności](./dependencies) oraz kompiluje niezbędne zasoby.
+* Podczas *etapu publikacji* aplikacji używany jest build stworzony w poprzednim etapie i konfigurowany na podstawie [ustawień](./config) obecnego wdrożenia. Stworzony w ten sposób *release* zawiera zbudowane źródło kodu, jego konfigurację i jest gotowy do uruchomienia w wybranym środowisku.
+* *Etap uruchamiania* (znany również jako "runtime") startuje aplikację w środowisku wykonawczym przez uruchomienie zestawu [procesów](./processes) w oparciu o wcześniej przygotowany release.
+
+
+
+**Aplikacja 12factor ściśle rozgranicza etapy budowy, publikacji i uruchomiania** Kiedy aplikacja została już uruchomiona, nie można zmienić jej kodu w inny sposób niż zbudować ją na nowo na podstawie wcześniej naniesionych zmian.
+
+Narzędzia do obsługi wdrożeń zazwyczaj oferują moduły do zarządzania releasami, w tym możliwość do powrotu do poprzedniej wersji (rollback). Np. narzędzie [Capistrano](https://github.com/capistrano/capistrano/wiki) przechowuje releasy w podkatalogu `releases`, gdzie obecna wersja opublikowanej aplikacji jest symlinkowana do jednej z wersji przechowywanej w katalogu Capistrano. Komenda `rollback` pozwala na szybką zmianę wersji opublikowanej aplikacji na jedną z poprzednich.
+
+Każdy release powinien zawsze posiadać unikalny identyfikator, jak np. data publikacji aplikacji (taka jak `2011-04-06-20:32:17`) lub inkrementowany numer (np. `v100`). Do rejestru opublikowanych wersji aplikacji można jedynie dodawać jej nowe wersje, jego zawartość nie może być zmieniana w żaden inny sposób.
+
+Aplikacja może zostać zbudowana gdy developer zdecyduje o wdrożeniu zmian do kodu. Uruchomienie aplikacji może natomiast nastąpić automatycznie po restarcie serwera lub jednego z procesów aplikacji po błędzie krytycznym. Dlatego też etap uruchamiania aplikacji powinien być jak najbardziej jednolity minimalizując równocześnie ryzyko wystąpienia problemów ze startem aplikacji - mogą one spowodować zaprzestanie działania aplikacji np. w nocy, kiedy to nie ma żadnego developera "pod ręką". Etap budowy aplikacji może być bardziej złożony, ponieważ ewentualne błędy są zawsze widoczne dla developera, który nadzoruje ten proces.
diff --git a/content/pl/codebase.md b/content/pl/codebase.md
new file mode 100644
index 000000000..8586f044f
--- /dev/null
+++ b/content/pl/codebase.md
@@ -0,0 +1,17 @@
+## I. Codebase
+### Jedno źródło kodu śledzone systemem kontroli wersji, wiele wdrożeń
+
+Aplikacja 12factor napisana jest zawsze zarządzania w systemie kontroli wersji takim jak [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/), czy [Subversion](http://subversion.apache.org/). Miejsce, w którym trzymany i rewizjonowany jest kod nazywane jest *repozytorium kodu źródłowego*, często skracane do samego *code repo*, albo po prostu *repo*.
+
+*Codebase* (baza kodu) jest więc niczym innym jak pojedynczym repo (w przypadku zcentralizowanego systemu kontroli wersji jak Subversion), albo zestawem repozytoriów, które współdzielą tzw. root commit. (w przypadku zdecentralizowanego systemu jak Git).
+
+
+
+Aplikacja powinna zawsze odzwierciedlać bazowy kod:
+
+* Jeśli istnieje wiele źródeł, z których pobierany jest kod, nie można mówić o aplikacji, a systemie rozproszonym. Każdy komponent w systemie rozproszonym będzie wtedy aplikacją i każdy z osobna może spełniać wszystkie zasady 12factor.
+* Jeśli wiele aplikacji dzieli ten sami kod, mamy do czynienia z naruszeniem 12factor. Wyjściem z tej sytuacji może być wyizolowanie współdzielonego kodu do bibliotek, które będą dodane do aplikacji przez tzw. [dependency manager](./dependencies).
+
+Aplikacja może posiadać tylko jeden codebase, jednocześnie mając wiele wdrożeń. *Deploy* (z ang. wdrożenie) jest działającą instancją aplikacji. Zazwyczaj mówi się o wersji produkcyjnej i jednej lub więcej przedprodukcyjnych. Ponadto każdy developer pracujący nad aplikacją posiada jej kopię działającą w swoim lokalnym środowisku developerskim, co również kwalifikuje się jako osobne wdrożenie.
+
+Codebase jest taki sam dla wszystkich wdrożeń aplikacji, jednak poszczególne wdrożenia aplikacji mogą korzystać z jego różnych wersji. Dla przykładu, developer pracujący nad aplikacją może nanieść zmiany, które nie znajdą się jeszcze w wersji produkcyjnej. Obie wersje dzielą jednak ten sam codebase, przez co kwalifikują się jako osobne wdrożenia tej samej aplikacji.
diff --git a/content/pl/concurrency.md b/content/pl/concurrency.md
new file mode 100644
index 000000000..8e3714ea8
--- /dev/null
+++ b/content/pl/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. Współbieżność
+### Skaluj przez odpowiednio dobrane procesy
+
+Każdy program komputerowy od momentu uruchomienia jest reprezentowany przez jeden lub więcej procesów. Aplikacje internetowe mogą być uruchamiane w różnorodny sposób. Dla przykładu - procesy PHP uruchamiane są na żądanie (w zależności od potrzeby obsługi odpowiednio dużej liczby zapytań) się jako podrzędne procesy Apache'a. W Javie procesy obsługiwane są zupełnie inaczej, z JVM zapewniającym jeden nadrzędny proces, który rezerwuje zasoby systemu (CPU oraz pamięć) na starcie oraz współbieżnością zarządzaną wewnętrznie i opartą na wątkach. Dla developerów aplikacji różnica jednak nie będzie szczególnie odczuwalna.
+
+
+
+**W aplikacji 12factor, procesy są typem pierwszoklasowym** Zachowanie tych procesów jest mocno wzorowane na [modelu procesów unixowych dla usług działających w wewnątrz systemu operacyjnego](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Używając tego modelu programista może zaprojektować aplikację by radziła sobie z różnorodnym obciążeniem przez przypisywanie każdej czynności do *typu procesu*. Przykłady to m.in obsługa procesów sieciowych przez HTTP oraz długotrwałe działanie zadań w tle opierających się na procesach roboczych.
+
+Mimo tego procesy wciąż mogą się zwielokrotnić przez wątki w środowisku maszyny wirtualnej lub w asynchronicznym modelu wydarzeń, którego implementację możemy znaleźć wśród narzędzi takich jak [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/), albo [Node.js](http://nodejs.org/). Należy pamiętać, że pojedyncza maszyna wirtualna może z czasem wymagać coraz więcej zasobów (skala pionowa), dlatego aplikacja musi być również w stanie pracować w oparciu o wiele procesów działających na wielu fizycznych maszynach.
+
+Największa zaleta modelu procesów objawia się w momencie skalowania. [Niezależność oraz dzielenie się na podprocesy](./processes) umożliwia proste i bezproblemowe dodawanie wiekszej liczby równolegle działajacych procesów. Tablica typów procesów i liczba procesów nazywana jest ich *formacją*.
+
+Procesy aplikacji 12factor [nigdy nie powinny być uruchamiane w tle](http://dustin.github.com/2010/02/28/running-processes.html) i nie mogą zapisywać plików PID. Zamiast tego opierają się na narzędziach systemu operacyjnego: do zarządzania procesami (np. [Upstart](http://upstart.ubuntu.com/), do zarządzania rozproszonymi procesami w chmurze, lub [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) w developmencie) do zarządzania [stumieniami wyjściowymi](./logs), do obsługi zatrzymanych procesów, restartu i zakończenia działań zainicjowanych przez użytkownika.
diff --git a/content/pl/config.md b/content/pl/config.md
new file mode 100644
index 000000000..1425579b3
--- /dev/null
+++ b/content/pl/config.md
@@ -0,0 +1,22 @@
+## III. Konfiguracja
+### Przechowuj konfigurację w środowisku
+
+*Konfiguracja* to jedyny element, który może się różnić pomiędzy [wdrożeniami](./codebase) aplikacji (staging, produkcja, środowisko developerskie, etc). W jej skład wchodzą:
+
+* Ustawienia połączeń do baz danych, Memcached, i innych [usług wspierających](./backing-services)
+* Dane uwierzytelniające zewnętrznych usług takich jak Amazon S3 czy Twitter
+* Wartości różne dla każdego wdrożenia, jak np. kanoniczna nazwa hosta
+
+Aplikacja czasem przechowuje konfigurację jako stałe wartości w kodzie źródłowym. Niestety jest to złamanie zasady 12factor wg której konfiguracja jest **ściśle oddzielona od kodu aplikacji**.
+
+Dowodem na to, czy aplikacja posiada swoją konfigurację oddzieloną od kodu jest to, czy można ją udostępnić na zasadach open source bez równoczesnego udostępniania np. danych uwierzytelniających.
+
+Należy pamiętać, że definicja "konfiguracji" **nie** dotyczy wewnętrznych ustawień aplikacji takich jak np. plik `config/routes.rb` w Railsach lub to jak [są połączone moduły kodu](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) w [Springu](http://spring.io/). Konfiguracja tego typu nie zmienia się pomiędzy wdrożeniami co sprawia, że najbardziej odpowiednim miejscem do jej przechowywania jest kod aplikacji.
+
+Innym podejściem do konfiguacji jest korzystanie z plików, które nie znajdują się w repozytorium i nie są wersjonowane, jak np. `config/database.yml` w Railsach. Jest to duże usprawnienie względem używania stałych wartości, które są zapisywane w repozytorium. Minusem tego rozwiązania jest możliwość przypadkowego umieszczenia pliku konfiguracyjnego w repo. Ponadto można spotkać się z tendencją do rozrzucania takich plików w różnych katalogach i różnych formatach, co czyni je trudnymi do znalezienia i zarządzania z jednego miejsca.
+
+**Aplikacja 12factor przechowuje konfigurację w *zmiennych środowiskowych*** (czasem nazywane z języka angielskiego *env vars* lub *env*). W tej sytuacji można łatwo modyfikować zmienne środowiskowe pomiędzy wdrożeniami bez zmiany kodu aplikacji. W odróżnieniu do plików konfiguracyjnych istnieje mała szansa by zostały umieszczone przypadkowo w repozytorium. Ich kolejną zaletą jest to, że nie są powiązane z językiem programowania, frameworkiem, jak np. Java System Properties, czy też systemem operacyjnym.
+
+Kolejnym zagadnieniem zarządzania konfiguracją jest jej grupowanie. Czasem aplikacje gromadzą konfigurację w grupach (czasem nazywane "środowiskami") nazywanych od nazwy wdrożenia, takie jak `development`, `test`, czy `produkcja` w Railsach. Ten sposób organizacji jest niestety nieskalowalny. Im więcej różnych wdrożeń, tym większa potrzeba nazw, jak np. `staging` czy `qa`. Wraz z rozwojem projektu programiści mogą dodawać swoje specjalne konfiguracje, jak `staging-józefa`. Efektem tego mogą być niezliczone kombinacje nazw plików konfiguracyjnych, co utrudniać będzie zarządzanie wdrożonymi aplikacji.
+
+W aplikacji 12factor zmienne środowiskowe służą do precyzyjnej kontroli poszczególnych ustawień, posiadając różne, nie mylące się ze sobą nazwy. Nigdy nie są zgrupowane w "środowiskach", tylko niezależnie ustawiane dla każdego wdrożenia. Taki model konfiguracji skaluje się bez problemu, nawet jeśli aplikacja będzie potrzebowała w przyszłości więcej zróżnicowanych wdrożeń.
diff --git a/content/pl/dependencies.md b/content/pl/dependencies.md
new file mode 100644
index 000000000..a0cebd86e
--- /dev/null
+++ b/content/pl/dependencies.md
@@ -0,0 +1,12 @@
+## II. Dependencies
+### Jawnie zadeklaruj i wydziel zależności
+
+Większość języków programowania oferuje narzędzia do dystrybucji dodatkowych bibliotek, takie jak [CPAN](http://www.cpan.org/) dla Perla lub [Rubygems](http://rubygems.org/) dla języka Ruby. Biblioteki zainstalowane w ten sposób mogą być dostępne dla całego systemu (określane jako "site packages") lub zakres ich działania może być ograniczony dla pojedynczego projektu lub aplikacji (określane jako "vendoring" lub "bundling").
+
+**Aplikacja 12factor nigdy nie jest zależna od bibliotek zainstalowanych dla całego systemu.** Wszystkie zależności są dokładnie określone przez dokument zawierający ich kompletną listę (*dependency declaration manifest*). Ponadto taka aplikacja korzysta z narzędzia służącego do izolacji tych zależności podczas działania aplikacji. W ten sposób ma się pewność, że np. jakaś biblioteka nie jest przypadkiem jedną z tych zainstalowanych w zewnętrznym środowisku, w którym działa aplikacja. Inaczej podobna sytuacja mogłaby uniemożliwiać poprawne działanie aplikacji w innym środowisku, gdzie takiej biblioteki by brakowało. Pełna i dokładna specyfikacja bibliotek używanych przez aplikację jest identyczna dla zarówno środowiska developerskiego jak i produkcyjnego.
+
+Np. [Gem Bundler](http://gembundler.com/) dla Ruby'ego używa pliku `Gemfile` dla deklaracji bibliotek z których korzysta aplikacja oraz komendę `bundle exec` do izolacji tych zależności. W Pythonie istnieją dwa oddzielne narzędzia dla tych zadań -- [Pip](http://www.pip-installer.org/en/latest/) jest używany do deklaracji oraz [Virtualenv](http://www.virtualenv.org/en/latest/) do izolacji. Nawet język C posiada narzędzie [Autoconf](http://www.gnu.org/s/autoconf/) do deklaracji zależności, a statyczne wiązania mogą zapewnić izolację zalenożności. Bez względu na użyte narzędzia, deklaracja i izolacja zależności muszą być zawsze stosowane razem. Użycie tylko jednej z nich nie jest wystarczające by spełnić wymogi 12factor.
+
+Jedną z niewątpliwych korzyści deklaracji zależności jest uproszczenie początkowej konfiguracji aplikacji dla developera. Nowy programista może pobrać kod źródłowy z repozytorium. Następnie, posiadając wcześniej skonfigurowane środowisko danego języka i narzędzie do zarządzania jego bibliotekami, jest w stanie zainstalować wszystkie moduły i biblioteki potrzebne dla działania aplikacji przy pomocy jednej komendy. Taką komendą np. dla Ruby'ego/Bundlera jest `bundle install`, a dla Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) jest to `lein deps`.
+
+Aplikacje zgodne z 12factor również nie są zależne od systemowych narzędzi. Wśród przykładów można wymienić ImageMagick czy też `curl`. Pomimo, że narzędzia te mogą być dostępne na wielu lub nawet większości systemów, nie ma gwarancji, że będą istniały na wszystkich środowiskach, w których będzie uruchamiana aplikacja w przyszłości lub że ich wersja będzie kompatybilna. Jeśli aplikacja korzysta z jakiegokolwiek systemowego narzędzia, powinno być ono osobno do niej dołąćzone.
diff --git a/content/pl/dev-prod-parity.md b/content/pl/dev-prod-parity.md
new file mode 100644
index 000000000..c1d53da17
--- /dev/null
+++ b/content/pl/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Jednolitość środowisk
+### Utrzymuj środowisko developerskie, stagingowe i produkcyjne tak podobne jak tylko możliwe
+
+Z doświadczenia wiadomo, że od zawsze istniały różnice pomiędzy środowiskiem developerskim (developer pracujący nad swoją lokalną wersją [kodu](./codebase) aplikacji) a produkcyjnym (działająca aplikacja dostępna dla użytkowników. Ze względu na ich charakter, możemy wymienić trzy rodzaje różnic:
+
+* **Różnica czasowa:** Developer może pracować nad kodem przez dni, tygodnie, miesiące zanim ostatecznie pojawi się on w wersji produkcyjnej.
+* **Różnica odpowiedzialności**: Developer tworzy kod aplikacji, natomiast kto inny wdraża go do na produkcję.
+* **Różnica narzędzi**: Developer może używać narzędzi takich jak Nginx, SQLite i systemu OS X, natomiast wersja produkcyjna będzie opierać się na Apache, MySQL i systemie Linux.
+
+**Aplikacja 12factor jest zaprojektowana tak by można ją było [bez przerwy wdrażać na produkcję](http://www.avc.com/a_vc/2011/02/continuous-deployment.html) minimalizując różnice pomiędzy środowiskami.** Mając na uwadze powyższe różnice, można sobie z nimi radzić na różne sposoby:
+
+* Zmniejsz czas deploymentu: czas wdrożenia kodu napisanego przez developera powinien być mierzony w godzinach, a nawet w minutach.
+* Przenieś odpowiedzialność: developer piszący kod powinien być zaangażowany we wdrożenia aplikacji na produkcję.
+* Stosuj ten sam zestaw narzędzi: utrzymuj wszystkie środowiska w których działa aplikacja tak podobne jak to możliwe.
+
+Podsumowując w formie tabeli:
+
+| + | Tradycyjna aplikacja | +Aplikacja 12factor | +
|---|---|---|
| Czas pomiędzy wdrożeniami | +Tygodnie | +Godziny | +
| Tworzenie kodu vs wdrażanie kodu | +Różne osoby | +Te same osoby | +
| Środowisko developerskie vs produkcyjne | +Mocno różniące się | +Jak najbardziej zbliżone | +
| Typ | +Język | +Biblioteka | +Adaptery | +
|---|---|---|---|
| Baza danych | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Kolejka | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Cache | +Ruby/Rails | +ActiveSupport::Cache | +Pamięć, system plików, Memcached | +
+
+Recursos podem ser anexados e desanexados a deploys à vontade. Por exemplo, se o banco de dados do app não está funcionando corretamente devido a um problema de hardware, o administrador do app pode subir um novo servidor de banco de dados restaurado de um backup recente. O atual banco de produção por ser desanexado, e o novo banco anexado -- tudo sem nenhuma mudança no código.
diff --git a/content/pt_br/build-release-run.md b/content/pt_br/build-release-run.md
new file mode 100644
index 000000000..f15750074
--- /dev/null
+++ b/content/pt_br/build-release-run.md
@@ -0,0 +1,18 @@
+## V. Construa, lance, execute
+### Separe estritamente os estágios de construção e execução
+
+Uma [base de código](./codebase) é transformada num deploy (de não-desenvolvimento) através de três estágios:
+
+* O *estágio de construção* é uma transformação que converte um repositório de código em um pacote executável conhecido como *construção*. Usando uma versão do código de um commit especificado pelo processo de desenvolvimento, o estágio de construção obtém e fornece [dependências](./dependencies) e compila binários e ativos.
+* O *estágio de lançamento* pega a construção produzida pelo estágio de construção e a combina com a atual [configuração](./config) do deploy. O *lançamento* resultante contém tanto a construção quanto a configuração e está pronta para execução imediata no ambiente de execução.
+* O *estágio de execução* roda o app no ambiente de execução, através do início de alguns dos [processos](./processes) do app com um determinado lançamento.
+
+
+
+**O app doze-fatores usa separação estrita entre os estágios de construção, lançamento e execução.** Por exemplo, é impossível alterar código em tempo de execução, já que não há meios de se propagar tais mudanças de volta ao estágio de construção.
+
+Ferramentas para deploy tipicamente oferecem ferramentas de gestão de lançamento, mais notadamente a habilidade de se reverter à um lançamento prévio. Por exemplo, a ferramenta de deploy [Capistrano](https://github.com/capistrano/capistrano/wiki) armazena lançamentos em um subdiretório chamado `releases`, onde o lançamento atual é um link simbólico para o diretório da lançamento atual. Seu comando `rollback` torna fácil reverter para um lançamento prévio.
+
+Cada lançamento deve sempre ter um identificador de lançamento único, tal qual o timestamp do lançamento (como `2011-04-06-20:32:17`) ou um número incremental (como `v100`). Lançamentos são livro-razões onde apenas se acrescenta informações, ou seja, uma vez criado o lançamento não pode ser alterado. Qualquer mudança deve gerar um novo lançamento.
+
+Construções são iniciadas pelos desenvolvedores do app sempre que novos códigos entram no deploy. A execução de um executável, todavia, pode acontecer automaticamente em casos como o reinício do servidor, ou um processo travado sendo reiniciado pelo gerenciador de processos. Assim, no estágio de execução deve haver quanto menos partes móveis quanto possível, já que problemas que previnem um app de rodar pode causá-lo a travar no meio da noite quando não há desenvolvedores por perto. O estágio de construção pode ser mais complexo, já que os erros estão sempre à vista do desenvolvedor que está cuidando do deploy.
diff --git a/content/pt_br/codebase.md b/content/pt_br/codebase.md
new file mode 100644
index 000000000..e326c7e34
--- /dev/null
+++ b/content/pt_br/codebase.md
@@ -0,0 +1,18 @@
+## I. Base de Código
+### Uma base de código com rastreamento utilizando controle de revisão, muitos deploys
+
+Uma aplicação 12 fatores é sempre rastreada em um sistema de controle de versão, como [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/), ou [Subversion](http://subversion.apache.org/). Uma cópia da base de dados do rastreamento de revisões é conhecido como *repositório de código*, normalmente abreviado como *repositório* ou *repo*.
+
+Uma *base de código* é um único repo (em um sistema de controle de versão centralizado como Subversion), ou uma série de repositórios que compartilham um registro raiz.
+
+
+
+Existe sempre uma correlação um-para-um entre a base de código e a aplicação:
+
+* Se existem várias bases de código, isto não é uma app -- é um sistema distribuído. Cada componente do sistema é uma app, e cada uma pode individualmente ser compatível com os 12 fatores.
+* Multiplas apps compartilhando uma base de código é uma violação dos 12 fatores. A solução aqui é dividir o código compartilhado entre bibliotecas que podem ser incluídas através do [gerenciador de dependências](/dependencies).
+
+Existe apenas uma base de código por aplicação, mas existirão vários deploys da mesma. Um *deploy* é uma instância executando a aplicação. Isto é tipicamente um local de produção, e um ou mais locais de testes. Adicionalmente, todo desenvolvedor tem uma cópia da aplicação rodando em seu ambiente local de desenvolvimento, cada um desses pode ser qualificado como um deploy.
+
+A base de código é a mesma através de todos os deploys, entretando diferentes versões podem estar ativas em cada deploy. Por exemplo, um desenvolvedor tem alguns registros ainda não deployados no ambiente de teste, o ambiente de teste ainda tem registros não deployados em produção. Mas todos esses ambientes compartilham a mesma base de código, tornando-os identificáveis como diferentes deploys do mesmo app.
+
diff --git a/content/pt_br/concurrency.md b/content/pt_br/concurrency.md
new file mode 100644
index 000000000..efeb71e9d
--- /dev/null
+++ b/content/pt_br/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. Concorrência
+### Escale através do processo modelo
+
+Qualquer programa de computador, uma vez executado, está representado por um ou mais processos. Aplicações web têm tomado uma variedade de formas de processo de execução. Por exemplo, processos PHP rodam como processos filhos do Apache, iniciados sob demanda conforme necessário por volume de requisições. Processos Java tomam o caminho inverso, com a JVM proporcionando um processo uber maciço que reserva um grande bloco de recursos do sistema (CPU e memória) na inicialização, com concorrência gerenciada internamente via threads. Em ambos os casos, o(s) processo(os) executando é apenas minimamente visível para o desenvolvedores da aplicação.
+
+
+
+**Na aplicação doze-fatores, processos são cidadãos de primeira classe.** Processos na aplicação doze-fatores utilizam fortes sugestões do modelo de processos UNIX para execução de serviços daemon, o desenvolvedor pode arquitetar a aplicação dele para lidar com diversas cargas de trabalho, atribuindo a cada tipo de trabalho a um *tipo de processo*. Por exemplo, solicitações HTTP podem ser manipuladas para um processo web, e tarefas background de longa duração podem ser manipuladas por um processo trabalhador.
+
+Isto não exclui processos individuais da manipulação de sua própria multiplexação interna, por threads dentro do runtime da VM, ou o modelo async/evented encontrado em ferramentas como [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/), ou [Node.js](http://nodejs.org/). Mas uma VM individual pode aumentar (escala vertical), de modo que a aplicação deve ser capaz de abranger processos em execução em várias máquinas físicas.
+
+O modelo de processo realmente brilha quando chega a hora de escalar. O [compartilhar-nada, natureza horizontal particionada de um processo da aplicação doze-fatores](./processes) significa que a adição de mais simultaneidade é uma operação simples e de confiança. A matriz de tipos de processo e número de processos de cada tipo é conhecida como o *processo de formação*.
+
+Processos de uma app doze-fatores [nunca deveriam daemonizar](http://dustin.github.com/2010/02/28/running-processes.html) ou escrever arquivos PID. Em vez disso, confiar no gerente de processo do sistema operacional (como [Upstart](http://upstart.ubuntu.com/), um gerenciador de processos distribuídos em uma plataforma de nuvem, ou uma ferramenta como [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) em desenvolvimento) para gerenciar [fluxos de saída](./logs), responder a processos travados, e lidar com reinícios e desligamentos iniciados pelo usuário.
diff --git a/content/pt_br/config.md b/content/pt_br/config.md
new file mode 100644
index 000000000..2b4f861b9
--- /dev/null
+++ b/content/pt_br/config.md
@@ -0,0 +1,22 @@
+## III. Configurações
+### Armazene as configurações no ambiente
+
+A *configuração* de uma aplicação é tudo o que é provável variar entre [deploys](/codebase) (homologação, produção, ambientes de desenvolvimento, etc). Isto inclui:
+
+* Recursos para a base de dados, Memcached, e outros [serviços de apoio](/backing-services)
+* Credenciais para serviços externos como Amazon S3 ou Twitter
+* Valores por deploy como o nome canônico do host para o deploy
+
+Aplicações as vezes armazenam as configurações no código como constantes. Isto é uma violação do doze-fatores, o que exige uma **estrita separação da configuração a partir do código**. Configuração varia substancialmente entre deploys, código não.
+
+A prova de fogo para saber se uma aplicação tem todas as configurações corretamente consignadas fora do código é saber se a base de código poderia ter seu código aberto ao público a qualquer momento, sem comprometer as credenciais.
+
+Note que esta definição de "configuração" **não** inclui configuração interna da aplicação, como `config/routes.rb` em Rails, ou como [módulos de códigos são conectados](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) em [Spring](http://spring.io/). Este tipo de configuração não varia entre deploys, e por isso é melhor que seja feito no código.
+
+Outra abordagem para configuração é o uso de arquivos de configuração que não são versionados no controle de versão, como `config/database.yml` em Rails. Isto é uma grande melhoria sobre o uso de constantes que são versionadas no repositório do código, mas ainda tem pontos fracos: é fácil de colocar por engano um arquivo de configuração no repositório; há uma tendência para que os arquivos de configuração sejam espelhados em diferentes lugares e diferentes formatos, tornando-se difícil de ver e gerenciar todas as configurações em um só lugar. Além disso estes formatos tendem a ser específicos da linguagem ou framework.
+
+**A aplicação doze-fatores armazena configuração em *variáveis de ambiente*** (muitas vezes abreviadas para *env vars* ou *env*). Env vars são fáceis de mudar entre deploys sem alterar qualquer código. ao contrário de arquivos de configuração, há pouca chance de serem colocados acidentalmente no repositório do código; e ao contrário dos arquivos de configuração personalizados, ou outros mecanismos de configuração como Propriedades do Sistema Java, eles são por padrão agnósticos a linguagem e ao SO.
+
+Outro aspecto do gerenciamento de configuração é o agrupamento. Às vezes, aplicações de configuração em batch dentro de grupos nomeados (muitas vezes chamados de ambientes) em homenagem a deploys específicos, tais como os ambientes `development`, `test`, e `production` em Rails. Este método não escala de forma limpa: quanto mais deploys da aplicação são criados, novos nomes de ambiente são necessários, tais como `staging` ou `qa`. A medida que o projeto cresce ainda mais, desenvolvedores podem adicionar seus próprios ambientes especiais como `joes-staging`, resultando em uma explosão combinatória de configurações que torna o gerenciamento de deploys da aplicação muito frágil.
+
+Em uma aplicação doze-fatores, env vars são controles granulares, cada um totalmente ortogonal às outras env vars. Elas nunca são agrupadas como "environments", mas em vez disso são gerenciadas independentemente para cada deploy. Este é um modelo que escala sem problemas à medida que o app naturalmente se expande em muitos deploys durante seu ciclo de vida.
diff --git a/content/pt_br/dependencies.md b/content/pt_br/dependencies.md
new file mode 100644
index 000000000..21ddbdb16
--- /dev/null
+++ b/content/pt_br/dependencies.md
@@ -0,0 +1,11 @@
+## II. Dependências
+### Declare e isole explicitamente as dependências
+
+A maioria das linguagens de programação oferecem um sistema de pacotes para a distribuição de bibliotecas de apoio, como o [CPAN](http://www.cpan.org/) para Perl ou [Rubygems](http://rubygems.org/) para Ruby. Bibliotecas instaladas por meio de um sistema de pacotes podem ser instaladas em todo o sistema (conhecidas como "site packages") ou com escopo dentro do diretório contendo a aplicação (conhecidas como "vendoring" ou "building").
+
+**Uma aplicação doze-fatores nunca confia na existência implícita de pacotes em todo o sistema.** Ela declara todas as dependências, completa e exatamente, por meio de um manifesto de *declaração de dependência*. Além disso, ela usa uma ferramenta de *isolamento de dependência* durante a execução para garantir que não há dependências implícitas "vazamento" a partir do sistema circundante. A completa e explícita especificação de dependências é aplicada de maneira uniforme tanto para produção quanto para desenvolvimento.
+
+Por exemplo, [Gem Bundler](http://gembundler.com/) para Ruby oferece o formato de manifesto `Gemfile` para declaração de dependência e `bundle exec` para isolamento das mesmas. Em Python existem duas ferramentas separadas para estas etapas -- [Pip](http://www.pip-installer.org/en/latest/) é utilizado para declaração e [Virtualenv](http://www.virtualenv.org/en/latest/) para isolamento. Mesmo C tem [Autoconf](http://www.gnu.org/s/autoconf/) para declaração de dependência, e vinculação estática pode fornecer o isolamento. Não importa qual o conjunto de ferramentas, declaração de dependência e isolamento devem ser sempre usados juntos -- apenas um ou o outro não é suficiente para satisfazer doze-fatores.
+Um dos beneficios da declaração de dependência explícita é que simplifica a configuração da aplicação para novos desenvolvedores. O novo desenvolvedor pode verificar a base de código do aplicativo em sua máquina de desenvolvimento, exigindo apenas runtime da linguagem e gerenciador de dependência instalado como pré-requisitos. Eles serão capazes de configurar tudo o que é necessário para rodar o código da aplicação com um determinístico *comando de build*. Por exemplo, o comando de build para Ruby/Bundler é `bundle install`, enquanto que para Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) é `lein deps`.
+
+Aplicações doze-fatores também não contam com a existência implícita de todas as ferramentas do sistema. Exemplos incluem executar algum comando externo como do ImageMagick ou `curl`. Embora possam existir essas ferramentas em muitos ou mesmo na maioria dos sistemas, não há garantia de que eles vão existir em todos os sistemas em que a aplicação pode rodar no futuro, ou se a versão encontrada em um futuro sistema será compatível com a aplicação. Se a aplicação precisa executar alguma ferramenta do sistema, essa ferramenta deve ser vendorizada na aplicação.
diff --git a/content/pt_br/dev-prod-parity.md b/content/pt_br/dev-prod-parity.md
new file mode 100644
index 000000000..ac774902c
--- /dev/null
+++ b/content/pt_br/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Paridade entre desenv/produção
+### Mantenha o desenvolvimento, homologação e produção o mais similares possível
+
+Historicamente, houveram lacunas substanciais entre desenvolvimento (um desenvolvedor editando código num [deploy](./codebase) local do app) e produção (um deploy acessado pelos usuários finais). Essas lacunas se manifestam em três áreas:
+
+* **A lacuna do tempo:** Um desenvolvedor pode trabalhar em código que demora dias, semanas ou até meses para ir para produção.
+* **A lacuna de pessoal:** Desenvolvedores escrevem código, engenheiros de operação fazem o deploy dele.
+* **A lacuna de ferramentas:** Desenvolvedores podem estar usando um conjunto como Nginx, SQLite, e OS X, enquanto o app em produção usa Apache, MySQL, e Linux.
+
+**O App doze-fatores é projetado para [implantação contínua](http://www.avc.com/a_vc/2011/02/continuous-deployment.html) deixando a lacuna entre desenvolvimento e produção pequena.** Olhando às três lacunas descritas acima:
+
+* Diminua a lacuna de tempo: um desenvolvedor pode escrever código e ter o deploy feito em horas ou até mesmo minutos depois.
+* Diminua a lacuna de pessoal: desenvolvedores que escrevem código estão proximamente envolvidos em realizar o deploy e acompanhar seu comportamento em produção.
+* Diminua a lacuna de ferramentas: mantenha desenvolvimento e produção o mais similares possível.
+
+Resumindo o acima em uma tabela:
+
+| + | App tradicional | +App doze-fatores | +
|---|---|---|
| Tempo entre deploys | +Semanas | +Horas | +
| Autores de código vs deployers | +Pessoas diferentes | +Mesmas pessoas | +
| Ambientes de desenv vs produção | +Divergente | +O mais similar possível | +
| Tipo | +Linguagem | +Biblioteca | +Adaptadores | +
|---|---|---|---|
| Banco de dados | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Fila | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Cache | +Ruby/Rails | +ActiveSupport::Cache | +Memory, sistema de arquivos, Memcached | +
+
+Ресурсы можно по необходимости подключать к развёртыванию и отключать от развёртывания. Например, если база данных приложения функционирует некорректно из-за аппаратных проблем, администратор может запустить новый сервер базы данных, восстановленный из последней резервной копии. Текущая рабочая база данных может быть отключена, а новая база данных подключена -- всё это без каких-либо изменений кода.
diff --git a/content/ru/build-release-run.md b/content/ru/build-release-run.md
new file mode 100644
index 000000000..5c08d6993
--- /dev/null
+++ b/content/ru/build-release-run.md
@@ -0,0 +1,18 @@
+## V. Сборка, релиз, выполнение
+### Строго разделяйте стадии сборки и выполнения
+
+[Кодовая база](./codebase) трансформируется в развёртывание (не учитывая развёртывание для разработки) за три этапа:
+
+* *Этап сборки* -- это трансформация, которая преобразует репозиторий кода в исполняемый пакет, называемый *сборка*. Используя версию кода по указанному процессом развёртывания коммиту, этап сборки загружает сторонние [зависимости](./dependencies) и компилирует двоичные файлы и ресурсы (assets).
+* *Этап релиза* принимает сборку, полученную на этапе сборки, и объединяет её с текущей [конфигурацией](./config) развёртывания. Полученный *релиз* содержит сборку и конфигурацию и готов к немедленному запуску в среде выполнения.
+* *Этап выполнения* (также известный как "runtime") запускает приложение в среде выполнения путём запуска некоторого набора [процессов](./processes) приложения из определённого релиза.
+
+
+
+**Приложение двенадцати факторов использует строгое разделение между этапами сборки, релиза и выполнения.** Например, невозможно внести изменения в код во время выполнения, так как нет способа распространить эти изменения обратно на этап сборки.
+
+Инструменты развертывания, как правило, представляют собой инструменты управления релизами, и что немаловажно, дают возможность отката к предыдущему релизу. Например инструмент развертывания [Capistrano](https://github.com/capistrano/capistrano/wiki) сохраняет релизы в подкаталогах каталога с именем `releases`, где текущий релиз является символической ссылкой на каталог текущего релиза. Команда Capistrano `rollback` даёт возможность быстро откатится к предыдущему релизу.
+
+Каждый релиз должен иметь уникальный идентификатор, такой как отметка времени релиза (например `2015-04-06-15:42:17`) или увеличивающееся число (например `v100`). Релизы могут только добавляться и каждый релиз невозможно изменить после его создания. Любые изменения обязаны создавать новый релиз.
+
+Сборка инициируется разработчиком приложения всякий раз, когда разворачивается новый код. Запуск этапа выполнения, напротив, может происходить автоматически в таких случаях, как перезагрузка сервера, или перезапуск упавшего процесса менеджером процессов. Таким образом, этап выполнения должен быть как можно более технически простым, так как проблемы, которые могут помешать приложению запуститься могут возникнуть в середине ночи, когда нет доступных разработчиков. Этап сборки может быть более сложным, так как возможные ошибки всегда видимы разработчику, который запустил развёртывание.
diff --git a/content/ru/codebase.md b/content/ru/codebase.md
new file mode 100644
index 000000000..439820d8a
--- /dev/null
+++ b/content/ru/codebase.md
@@ -0,0 +1,17 @@
+## I. Кодовая база
+### Одна кодовая база, отслеживаемая в системе контроля версий, -- множество развертываний
+
+Приложение двенадцати факторов всегда отслеживается в системе контроля версий, такой как [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/) или [Subversion](http://subversion.apache.org/). Копия базы данных отслеживаемых версий называется *репозиторием кода (code repository)*, что часто сокращается до *code repo* или просто до *репозиторий (repo)*
+
+*Кодовая база* -- это один репозиторий (в централизованных системах контроля версий, как Subversion) или множество репозиториев, имеющих общие начальные коммиты (в децентрализованных системах контроля версий, как Git).
+
+
+
+Всегда есть однозначное соответствие между кодовой базой и приложением:
+
+* Если есть несколько кодовых баз, то это не приложение — это распределенная система. Каждый компонент в распределенной системе является приложением и каждый компонент может индивидуально соответствовать двенадцати факторам.
+* Факт того, что несколько приложений совместно используют тот же самый код, является нарушением двенадцати факторов. Решением в данной ситуации является выделение общего кода в библиотеки, которые могут быть подключены через [менеджер зависимостей](./dependencies).
+
+Существует только одна кодовая база для каждого приложения, но может быть множество развёртываний одного и того же приложения. *Развёрнутым приложением (deploy)* является запущенный экземпляр приложения. Как правило, это рабочее развёртывание сайта и одно или несколько промежуточных развёртываний сайта. Кроме того каждый разработчик имеет копию приложения, запущенного в его локальном окружении разработки, каждая из которых также квалифицируется как развёрнутое приложение (deploy).
+
+Кодовая база обязана быть единой для всех развёртываний, однако разные версии одной кодовой базы могут выполняться в каждом из развертываний. Например разработчик может иметь некоторые изменения которые еще не добавлены в промежуточное развёртывание; промежуточное развёртывание может иметь некоторые изменения, которые еще не добавлены в рабочее развёртывание. Однако, все эти развёртывания используют одну и ту же кодовую базу, таким образом можно их идентифицировать как разные развертывания одного и того же приложения.
diff --git a/content/ru/concurrency.md b/content/ru/concurrency.md
new file mode 100644
index 000000000..226da62e4
--- /dev/null
+++ b/content/ru/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. Параллелизм
+### Масштабируйте приложение с помощью процессов
+
+Любая компьютерная программа после запуска представляет собой один или несколько работающих процессов. Исторически веб-приложения принимали различные формы выполнения процессов. К примеру, PHP-процессы выполнятся как дочерние процессы Apache и запускаются по требованию в необходимом для обслуживания поступивших запросов количестве. Java-процессы используют противоположный подход, JVM представляет собой один монолитный мета-процесс, который резервирует большой объем системных ресурсов (процессор и память) при запуске и управляет параллельностью внутри себя с помощью нитей исполнения (threads). В обоих случаях запущенные процессы лишь минимально видны для разработчика приложения.
+
+
+
+**В приложении двенадцати факторов процессы являются сущностями первого класса.** Процессы в приложении двенадцати факторов взяли сильные стороны из [модели процессов Unix для запуска демонов](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). С помощью этой модели разработчик может спроектировать своё приложение таким образом, что для обработки различной рабочей нагрузки необходимо назначить каждому типу работы своего *типа процесса*. Например, HTTP-запросы могут быть обработаны веб-процессом, а длительные фоновые задачи обработаны рабочим процессом.
+
+Это не исключает возможность использования внутреннего мультиплексирования для индивидуальных процессов через потоки выполнения виртуальной машины или асинхронные/событийные модели в инструментах таких, как [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/) и [Node.js](http://nodejs.org/). Но каждая индивидуальная виртуальная машина может масштабироваться только ограничено (вертикальное масштабирование), поэтому приложение должно иметь возможность быть запущенным как несколько процессов на различных физических машинах.
+
+Модель, построенная на процессах, действительно сияет, когда приходит время масштабирования. [Отсутствие разделяемых данных и горизонтальное разделение процессов приложения двенадцати факторов](./processes) означает, что добавление большего параллелизма является простой и надёжной операцией. Массив процессов различного типа и количество процессов каждого типа называются *формированием процессов (process formation)*.
+
+Процессы приложения двенадцати факторов [никогда не должны демонизироваться](http://dustin.github.com/2010/02/28/running-processes.html) и записывать PID файлы. Вместо этого они должны полагаться на менеджер процессов операционной системы (например, [Upstart](http://upstart.ubuntu.com/), распределенный менеджер процессов на облачной платформе, или инструмент как [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) в процессе разработки) для управления [потоком вывода](./logs), реагирования на падения процесса и обработки инициированных пользователем перезагрузки или завершения работы.
diff --git a/content/ru/config.md b/content/ru/config.md
new file mode 100644
index 000000000..2a413ad94
--- /dev/null
+++ b/content/ru/config.md
@@ -0,0 +1,22 @@
+## III. Конфигурация
+### Сохраняйте конфигурацию в среде выполнения
+
+*Конфигурация* приложения -- это все, что может меняться между [развёртываниями](./codebase) (среда разработки, промежуточное и рабочее развёртывание). Это включает в себя:
+
+* Идентификаторы подключения к ресурсам типа базы данных, кэш-памяти и другим [сторонним службам](./backing-services)
+* Регистрационные данные для подключения к внешним сервисам, например, к Amazon S3 или Twitter
+* Значения зависимые от среды развёртывания такие, как каноническое имя хоста
+
+Иногда приложения хранят конфигурации как константы в коде. Это нарушение методологии двенадцати факторов, которая требует **строгого разделения конфигурации и кода**. Конфигурация может существенно различаться между развертываниями, код не должен различаться.
+
+Лакмусовой бумажкой того, правильно ли разделены конфигурация и код приложения, является факт того, что кодовая база приложения может быть в любой момент открыта в свободный доступ без компрометации каких-либо приватных данных.
+
+Обратите внимание, что это определение "конфигурации" **не** включает внутренние конфигурации приложения, например такие как 'config/routes.rb' в Rails, или того как [основные модули будут связаны](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) в [Spring](http://spring.io/). Этот тип конфигурации не меняется между развёртываниями и поэтому лучше всего держать его в коде.
+
+Другим подходом к конфигурации является использование конфигурационных файлов, которые не сохраняются в систему контроля версия, например 'config/database.yml' в Rails. Это огромное улучшение перед использованием констант, которые сохраняются в коде, но по-прежнему и у этого метода есть недостатки: легко по ошибке сохранить конфигурационный файл в репозиторий; существует тенденция когда конфигурационные файлы разбросаны в разных местах и в разных форматах, из за этого становится трудно просматривать и управлять всеми настройками в одном месте. Кроме того форматы этих файлов, как правило, специфичны для конкретного языка или фреймворка.
+
+**Приложение двенадцати факторов хранит конфигурацию в *переменных окружения*** (часто сокращается до *env vars* или *env*). Переменные окружения легко изменить между развертываниями, не изменяя код; в отличие от файлов конфигурации, менее вероятно случайно сохранить их в репозиторий кода; и в отличие от пользовательских конфигурационных файлов или других механизмов конфигурации, таких как Java System Properties, они являются независимым от языка и операционной системы стандартом.
+
+Другим подходом к управлению конфигурациями является группировка. Иногда приложения группируют конфигурации в именованные группы (часто называемые "окружениями") названые по названию конкретного развертывания, например как `development`, `test` и `production` окружения в Rails. Этот метод не является достаточно масштабируемым: чем больше различных развертываний приложения создается, тем больше новых имён окружений необходимо, например `staging` и `qa`. При дальнейшем росте проекта, разработчики могут добавлять свои собственные специальные окружения, такие как `joes-staging`, в результате происходит комбинаторный взрыв конфигураций, который делает управление развертываниями приложения очень хрупким.
+
+В приложении двенадцати факторов переменные окружения являются не связанными между собой средствами управления, где каждая переменная окружения полностью независима от других. Они никогда не группируются вместе в "окружения", а вместо этого управляются независимо для каждого развертывания. Эта модель которая масштабируется постепенно вместе с естественным появлением большего количества развёртываний приложения за время его жизни.
diff --git a/content/ru/dependencies.md b/content/ru/dependencies.md
new file mode 100644
index 000000000..0421cf1ec
--- /dev/null
+++ b/content/ru/dependencies.md
@@ -0,0 +1,12 @@
+## II. Зависимости
+### Явно объявляйте и изолируйте зависимости
+
+Большинство языков программирования поставляются вместе с менеджером пакетов для распространения библиотек, таким как [CPAN](http://www.cpan.org/) в Perl или [Rubygems](http://rubygems.org/) в Ruby. Библиотеки, устанавливаемые менеджером пакетов, могут быть установлены доступными для всей системы (так называемые "системные пакеты") или доступными только приложению в директорию содержащую приложение (так называемые "vendoring" и "bundling").
+
+**Приложение двенадцати факторов никогда не зависит от неявно существующих, доступных всей системе пакетов.** Приложение объявляет все свои зависимости полностью и точно с помощью манифеста *декларации зависимостей*. Кроме того, оно использует инструмент *изоляции зависимостей* во время выполнения для обеспечения того, что неявные зависимости не "просочились" из окружающей системы. Полная и явная спецификация зависимостей применяется равным образом как при разработке, так и при работе приложения.
+
+Например, [Gem Bundler](http://gembundler.com/) в Ruby использует `Gemfile` как формат манифеста для объявления зависимостей и `bundle exec` -- для изоляции зависимостей. Python имеет два различных инструмента для этих задач: [Pip](http://www.pip-installer.org/en/latest/) используется для объявления и [Virtualenv](http://www.virtualenv.org/en/latest/) -- для изоляции. Даже C имеет [Autoconf](http://www.gnu.org/s/autoconf/) для объявления зависимостей, и статическое связывание может обеспечить изоляцию зависимостей. Независимо от того, какой набор инструментов используется, объявление и изоляция зависимостей должны всегда использоваться совместно -- только одного из них недостаточно, чтобы удовлетворить двенадцати факторам.
+
+Одним из преимуществ явного объявления зависимостей является то, что это упрощает настройку приложения для новых разработчиков. Новый разработчик может скопировать кодовую базу приложения на свою машину, необходимыми требованиями для которой являются только наличие среды выполнения языка и менеджера пакетов. Всё необходимое для запуска кода приложения может быть настроено с помощью определённой *команды настройки*. Например, для Ruby/Bundler командой настройки является `bundle install`, для Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) это `lein deps`.
+
+Приложение двенадцати факторов также не полагается на неявное существование любых инструментов системы. Примером является запуск программ ImageMagick и `curl`. Хотя эти инструменты могут присутствовать во многих или даже в большинстве систем, нет никакой гарантии, что они будут присутствовать на всех системах, где приложение может работать в будущем, или будет ли версия найденная в другой системе совместима с приложением. Если приложению необходимо запустить инструмент системы, то этот инструмент должен быть включен в приложение.
diff --git a/content/ru/dev-prod-parity.md b/content/ru/dev-prod-parity.md
new file mode 100644
index 000000000..fdd594f03
--- /dev/null
+++ b/content/ru/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Паритет разработки/работы приложения
+### Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими
+
+Исторически существуют значительные различия между разработкой (разработчик делает живые изменения на локальном [развёртывании](./codebase) приложения) и работой приложения (развёртывание приложения с доступом к нему конечных пользователей). Эти различия проявляются в трех областях:
+
+* **Различие во времени:** разработчик может работать с кодом, который попадёт в рабочую версию приложения только через дни, недели или даже месяцы.
+* **Различие персонала**: разработчики пишут код, OPS инженеры разворачивают его.
+* **Различие инструментов**: разработчики могут использовать стек технологий, такой как Nginx, SQLite, и OS X, в то время как при рабочем развертывании используются Apache, MySQL и Linux.
+
+**Приложение двенадцати факторов спроектировано для [непрерывного развертывания](http://www.avc.com/a_vc/2011/02/continuous-deployment.html) благодаря минимизации различий между разработкой и работой приложения. Рассмотрим три различия, описанных выше:
+
+* Сделать различие во времени небольшим: разработчик может написать код, и он будет развёрнут через несколько часов или даже минут.
+* Сделать небольшими различия персонала: разработчик который написал код, активно участвует в его развертывание и наблюдет за его поведением во время работы приложения.
+* Сделать различия инструментов небольшими: держать окружение разработки и работы приложения максимально похожими.
+
+Резюмируя сказанное выше в таблицу:
+
+| + | Традиционное приложение | +Приложение двенадцати факторов | +
|---|---|---|
| Время между развёртываниями | +Недели | +Часы | +
| Автор кода/тот кто разворачивает | +Разные люди | +Те же люди | +
| Окружение разработки/работы приложения | +Различные | +Максимально похожие | +
| Тип | +Язык | +Библиотека | +Адаптеры | +
|---|---|---|---|
| База данных | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Очередь сообщений | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Кэш | +Ruby/Rails | +ActiveSupport::Cache | +Память, файловая система, Memcached | +
+
+部署可以按需加载或卸载资源。例如，如果应用的数据库服务由于硬件问题出现异常，管理员可以从最近的备份中恢复一个数据库，卸载当前的数据库，然后加载新的数据库 -- 整个过程都不需要修改代码。
diff --git a/content/zh_cn/build-release-run.md b/content/zh_cn/build-release-run.md
new file mode 100644
index 000000000..838e0418c
--- /dev/null
+++ b/content/zh_cn/build-release-run.md
@@ -0,0 +1,18 @@
+## V. 构建，发布，运行
+### 严格分离构建和运行
+
+[基准代码](./codebase) 转化为一份部署(非开发环境)需要以下三个阶段：
+
+* *构建阶段* 是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包 [依赖项](./dependencies)，编译成二进制文件和资源文件。
+* *发布阶段* 会将构建的结果和当前部署所需 [配置](./config) 相结合，并能够立刻在运行环境中投入使用。
+* *运行阶段* （或者说“运行时”）是指针对选定的发布版本，在执行环境中启动一系列应用程序 [进程](./processes)。
+
+
+
+**12-facfor 应用严格区分构建，发布，运行这三个步骤。** 举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建步骤。
+
+部署工具通常都提供了发布管理工具，最引人注目的功能是退回至较旧的发布版本。比如， [Capistrano](https://github.com/capistrano/capistrano/wiki) 将所有发布版本都存储在一个叫 `releases` 的子目录中，当前的在线版本只需映射至对应的目录即可。该工具的 `rollback` 命令可以很容易地实现回退版本的功能。
+
+每一个发布版本必须对应一个唯一的发布 ID，例如可以使用发布时的时间戳（`2011-04-06-20:32:17`），亦或是一个增长的数字（`v100`）。发布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。
+
+新的代码在部署之前，需要开发人员触发构建操作。但是，运行阶段不一定需要人为触发，而是可以自动进行。如服务器重启，或是进程管理器重启了一个崩溃的进程。因此，运行阶段应该保持尽可能少的模块，这样假设半夜发生系统故障而开发人员又捉襟见肘也不会引起太大问题。构建阶段是可以相对复杂一些的，因为错误信息能够立刻展示在开发人员面前，从而得到妥善处理。
diff --git a/content/zh_cn/codebase.md b/content/zh_cn/codebase.md
new file mode 100644
index 000000000..40af32cca
--- /dev/null
+++ b/content/zh_cn/codebase.md
@@ -0,0 +1,17 @@
+## I. 基准代码
+### 一份基准代码（*Codebase*），多份部署（*deploy*）
+
+12-Factor应用(译者注：应该是说一个使用本文概念来设计的应用，下同)通常会使用版本控制系统加以管理，如[Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/), [Subversion](http://subversion.apache.org/)。一份用来跟踪代码所有修订版本的数据库被称作 *代码库*（code repository, code repo, repo）。
+
+在类似 SVN 这样的集中式版本控制系统中，*基准代码* 就是指控制系统中的这一份代码库；而在 Git 那样的分布式版本控制系统中，*基准代码* 则是指最上游的那份代码库。
+
+
+
+基准代码和应用之间总是保持一一对应的关系：
+
+* 一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用 12-Factor 进行开发。
+* 多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案是将共享的代码拆分为独立的类库，然后使用 [依赖管理](./dependencies) 策略去加载它们。
+
+尽管每个应用只对应一份基准代码，但可以同时存在多份部署。每份 *部署* 相当于运行了一个应用的实例。通常会有一个生产环境，一个或多个预发布环境。此外，每个开发人员都会在自己本地环境运行一个应用实例，这些都相当于一份部署。
+
+所有部署的基准代码相同，但每份部署可以使用其不同的版本。比如，开发人员可能有一些提交还没有同步至预发布环境；预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码，我们就认为它们只是相同应用的不同部署而已。
diff --git a/content/zh_cn/concurrency.md b/content/zh_cn/concurrency.md
new file mode 100644
index 000000000..f3b0f7fee
--- /dev/null
+++ b/content/zh_cn/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. 并发
+### 通过进程模型进行扩展
+
+任何计算机程序，一旦启动，就会生成一个或多个进程。互联网应用采用多种进程运行方式。例如，PHP 进程作为 Apache 的子进程存在，随请求按需启动。Java 进程则采取了相反的方式，在程序启动之初 JVM 就提供了一个超级进程储备了大量的系统资源(CPU 和内存)，并通过多线程实现内部的并发管理。上述 2 个例子中，进程是开发人员可以操作的最小单位。
+
+
+
+**在 12-factor 应用中，进程是一等公民。**12-Factor 应用的进程主要借鉴于 [unix 守护进程模型](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/) 。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的 *进程类型* 。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。
+
+这并不包括个别较为特殊的进程，例如通过虚拟机的线程处理并发的内部运算，或是使用诸如 [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/), [Node.js](http://nodejs.org/) 的异步/事件触发模型。但一台独立的虚拟机的扩展有瓶颈（垂直扩展），所以应用程序必须可以在多台物理机器间跨进程工作。
+
+上述进程模型会在系统急需扩展时大放异彩。 [12-Factor 应用的进程所具备的无共享，水平分区的特性](./processes) 意味着添加并发会变得简单而稳妥。这些进程的类型以及每个类型中进程的数量就被称作 *进程构成* 。
+
+12-Factor 应用的进程 [不需要守护进程](http://dustin.github.com/2010/02/28/running-processes.html) 或是写入 PID 文件。相反的，应该借助操作系统的进程管理器(例如 [Upstart](http://upstart.ubuntu.com/) ，分布式的进程管理云平台，或是类似 [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) 的工具)，来管理 [输出流](/logs) ，响应崩溃的进程，以及处理用户触发的重启和关闭超级进程的请求。
diff --git a/content/zh_cn/config.md b/content/zh_cn/config.md
new file mode 100644
index 000000000..bcc671be5
--- /dev/null
+++ b/content/zh_cn/config.md
@@ -0,0 +1,22 @@
+## III. 配置
+### 在环境中存储配置
+
+通常，应用的 *配置* 在不同 [部署](./codebase) (预发布、生产环境、开发环境等等)间会有很大差异。这其中包括：
+
+* 数据库，Memcached，以及其他 [后端服务](./backing-services) 的配置
+* 第三方服务的证书，如 Amazon S3、Twitter 等
+* 每份部署特有的配置，如域名等
+
+有些应用在代码中使用常量保存配置，这与 12-Factor 所要求的**代码和配置严格分离**显然大相径庭。配置文件在各部署间存在大幅差异，代码却完全一致。
+
+判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。
+
+需要指出的是，这里定义的"配置"并**不**包括应用的内部配置，比如 Rails 的 `config/routes.rb`，或是使用 [Spring](http://spring.io/) 时 [代码模块间的依赖注入关系](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) 。这类配置在不同部署间不存在差异，所以应该写入代码。
+
+另外一个解决方法是使用配置文件，但不把它们纳入版本控制系统，就像 Rails 的 `config/database.yml` 。这相对于在代码中使用常量已经是长足进步，但仍然有缺点：总是会不小心将配置文件签入了代码库；配置文件的可能会分散在不同的目录，并有着不同的格式，这让找出一个地方来统一管理所有配置变的不太现实。更糟的是，这些格式通常是语言或框架特定的。
+
+**12-Factor推荐将应用的配置存储于 *环境变量* 中**（ *env vars*, *env* ）。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码；与配置文件不同，不小心把它们签入代码库的概率微乎其微；与一些传统的解决配置问题的机制（比如 Java 的属性配置文件）相比，环境变量与语言和系统无关。
+
+配置管理的另一个方面是分组。有时应用会将配置按照特定部署进行分组（或叫做“环境”），例如Rails中的 `development`,`test`, 和 `production` 环境。这种方法无法轻易扩展：更多部署意味着更多新的环境，例如 `staging` 或 `qa` 。 随着项目的不断深入，开发人员可能还会添加他们自己的环境，比如 `joes-staging` ，这将导致各种配置组合的激增，从而给管理部署增加了很多不确定因素。
+
+12-Factor 应用中，环境变量的粒度要足够小，且相对独立。它们永远也不会组合成一个所谓的“环境”，而是独立存在于每个部署之中。当应用程序不断扩展，需要更多种类的部署时，这种配置管理方式能够做到平滑过渡。
diff --git a/content/zh_cn/dependencies.md b/content/zh_cn/dependencies.md
new file mode 100644
index 000000000..38040ce1b
--- /dev/null
+++ b/content/zh_cn/dependencies.md
@@ -0,0 +1,12 @@
+## II. 依赖
+### 显式声明依赖关系（ *dependency* ）
+
+大多数编程语言都会提供一个打包系统，用来为各个类库提供打包服务，就像 Perl 的 [CPAN](http://www.cpan.org/) 或是 Ruby 的 [Rubygems](http://rubygems.org/) 。通过打包系统安装的类库可以是系统级的（称之为 "site packages"），或仅供某个应用程序使用，部署在相应的目录中（称之为 "vendoring" 或 "bunding"）。
+
+**12-Factor规则下的应用程序不会隐式依赖系统级的类库。** 它一定通过 *依赖清单* ，确切地声明所有依赖项。此外，在运行过程中通过 *依赖隔离* 工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。
+
+例如， Ruby 的 [Gem Bundler](http://gembundler.com/) 使用 `Gemfile` 作为依赖项声明清单，使用 `bundle exec` 来进行依赖隔离。Python 中则可分别使用两种工具 -- [Pip](http://www.pip-installer.org/en/latest/) 用作依赖声明， [Virtualenv](http://www.virtualenv.org/en/latest/) 用作依赖隔离。甚至 C 语言也有类似工具， [Autoconf](http://www.gnu.org/s/autoconf/) 用作依赖声明，静态链接库用作依赖隔离。无论用什么工具，依赖声明和依赖隔离必须一起使用，否则无法满足 12-Factor 规范。
+
+显式声明依赖的优点之一是为新进开发者简化了环境配置流程。新进开发者可以检出应用程序的基准代码，安装编程语言环境和它对应的依赖管理工具，只需通过一个 *构建命令* 来安装所有的依赖项，即可开始工作。例如，Ruby/Bundler 下使用 `bundle install`，而 Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) 则是 `lein deps`。
+
+12-Factor 应用同样不会隐式依赖某些系统工具，如 ImageMagick 或是`curl`。即使这些工具存在于几乎所有系统，但终究无法保证所有未来的系统都能支持应用顺利运行，或是能够和应用兼容。如果应用必须使用到某些系统工具，那么这些工具应该被包含在应用之中。
diff --git a/content/zh_cn/dev-prod-parity.md b/content/zh_cn/dev-prod-parity.md
new file mode 100644
index 000000000..f7cf98c2a
--- /dev/null
+++ b/content/zh_cn/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. 开发环境与线上环境等价
+### 尽可能的保持开发，预发布，线上环境相同
+
+从以往经验来看，开发环境（即开发人员的本地 [部署](./codebase)）和线上环境（外部用户访问的真实部署）之间存在着很多差异。这些差异表现在以下三个方面：
+
+* **时间差异：** 开发人员正在编写的代码可能需要几天，几周，甚至几个月才会上线。
+* **人员差异：** 开发人员编写代码，运维人员部署代码。
+* **工具差异：** 开发人员或许使用 Nginx，SQLite，OS X，而线上环境使用 Apache，MySQL 以及 Linux。
+
+**12-Factor 应用想要做到 [持续部署](http://www.avc.com/a_vc/2011/02/continuous-deployment.html) 就必须缩小本地与线上差异。** 再回头看上面所描述的三个差异:
+
+* 缩小时间差异：开发人员可以几小时，甚至几分钟就部署代码。
+* 缩小人员差异：开发人员不只要编写代码，更应该密切参与部署过程以及代码在线上的表现。
+* 缩小工具差异：尽量保证开发环境以及线上环境的一致性。
+
+将上述总结变为一个表格如下：
+
+| + | 传统应用 | +12-Factor 应用 | +
|---|---|---|
| 每次部署间隔 | +数周 | +几小时 | +
| 开发人员 vs 运维人员 | +不同的人 | +相同的人 | +
| 开发环境 vs 线上环境 | +不同 | +尽量接近 | +
| 类型 | +语言 | +类库 | +适配器 | +
|---|---|---|---|
| 数据库 | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| 队列 | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| 缓存 | +Ruby/Rails | +ActiveSupport::Cache | +Memory, filesystem, Memcached | +