+
+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..7a34788ed
--- /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](https://www.mercurial-scm.org/), 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..f19ac8080
--- /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](https://github.com/eventmachine/eventmachine), [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 [systemd](https://www.freedesktop.org/wiki/Software/systemd/), 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..43bc11ca5
--- /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 [Bundler](https://bundler.io/) 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..c1216f579
--- /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://avc.com/2011/02/continuous-deployment/) 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 ressources 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..ae76a3b19
--- /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'*étape 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`). La liste des releases est accessible en écriture incrémentale 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és 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 entraîner 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..e50c048c9
--- /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](https://www.mercurial-scm.org/), 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..f3ff239ba
--- /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 asynchrones que l'on retrouve dans des outils comme [EventMachine](https://github.com/eventmachine/eventmachine), [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 du 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. À la place, utilisez le gestionnaire de processus du système d'exploitation (tel que [systemd](https://www.freedesktop.org/wiki/Software/systemd/), 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..396519b4c
--- /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 rendue 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, 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 tendance à ê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 leurs propres environnements particuliers, comme `joes-validation`, ce qui entraîne une explosion combinatoire de la configuration qui rend la gestion des déploiements 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..146c066d1
--- /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épendance 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, [Bundler](https://bundler.io/) 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 chaîne 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 œil à 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, par exemple ImageMagick ou `curl`. Bien que ces outils puissent exister sur beaucoup voire la plupart des systèmes d'exploitation, 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..1cd06c0b4
--- /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://avc.com/2011/02/continuous-deployment/) 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 | +Librairie | +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 deployment a piacimento. Per 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.
diff --git a/content/it/build-release-run.md b/content/it/build-release-run.md
new file mode 100644
index 000000000..96927e3b1
--- /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 deployment attraverso tre fasi:
+
+* la fase di *build*, che converte il codice del repo in una build "eseguibile". Usando una certa versione del codice, a 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 deployment 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.** Per 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 deployment offrono tipicamente dei tool di gestione delle release, in particolare alcuni dedicati a un rollback verso una release precedente. Per 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 a una certa release velocemente.
+
+Ogni release dovrebbe inoltre possedere un ID univoco di rilascio, come per 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 a un crash con successivo riavvio del processo). A 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.
diff --git a/content/it/codebase.md b/content/it/codebase.md
new file mode 100644
index 000000000..e7669a05c
--- /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](https://www.mercurial-scm.org/), 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 e applicazione:
+
+* Se ci sono più codebase, non si parla più di applicazione ma di sistema distribuito. Ogni componente in un sistema distribuito è un'applicazione, e 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 deployment 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 deployment, anche se potrebbero essere attive diverse versioni nello stesso istante. Si pensi per esempio a 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.
diff --git a/content/it/concurrency.md b/content/it/concurrency.md
new file mode 100644
index 000000000..1ea240065
--- /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. Per 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 a un tipo di processo ben definito. Per 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 e interno il multiplexing, tramite threading, all'interno della VM in esecuzione, o magari un modello asincrono o basato su eventi come quello di [EventMachine](https://github.com/eventmachine/eventmachine), [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 e affidabile. L'array dei tipi di processo e 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 [systemd](https://www.freedesktop.org/wiki/Software/systemd/), 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..656dca8e2
--- /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 [deployment](./codebase) all'altro (staging, production, ambienti di sviluppo). Ad esempio:
+
+* Valori da usare per connettersi a un database, Memcached, oppure altri [backing service](./backing-services);
+* Credenziali per servizi esterni, come Amazon S3 o Twitter;
+* Valori eventualmente definiti per i singoli deployment, 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 deployment 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 deployment a deployment: 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 per 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 e 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 a essere collegati a 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 deployment in deployment 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", per 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 deployment. 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..cfc7408ee
--- /dev/null
+++ b/content/it/dependencies.md
@@ -0,0 +1,12 @@
+## II. Dipendenze
+### Dipendenze dichiarate e 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.
+
+Per esempio, [Bundler](https://bundler.io/) 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 e 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.
diff --git a/content/it/dev-prod-parity.md b/content/it/dev-prod-parity.md
new file mode 100644
index 000000000..77e6cedc4
--- /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 a un [deployment](./codebase) in locale) e quello di produzione (un deployment 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 deployment;
+* **Strumenti**: gli sviluppatori potrebbero usare uno stack quale Nginx, SQLite e OS X, mentre in produzione per il deployment verrebbero installati Apache, MySQL e Linux.
+
+**Un'applicazione twelve-factor è progettata per il [rilascio continuo](http://avc.com/2011/02/continuous-deployment/), 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 Deployment | +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 | +
| + | 伝統的なアプリケーション | +Twelve-Factor App | +
|---|---|---|
| デプロイの間隔 | +数週間 | +数時間 | +
| コードを書く人とデプロイする人 | +異なる人 | +同じ人 | +
| 開発環境と本番環境 | +異なる | +できるだけ一致 | +
| 種類 | +言語 | +ライブラリ | +アダプター | +
|---|---|---|---|
| データベース | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| キュー | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| キャッシュ | +Ruby/Rails | +ActiveSupport::Cache | +メモリ, ファイルシステム, Memcached | +
+
+리소스는 자유롭게 배포에 연결되거나 분리될 수 있습니다. 예를 들어, 애플리케이션의 데이터베이스가 하드웨어 이슈로 작용이 이상한 경우, 애플리케이션의 관리자는 최신 백업에서 새로운 데이터베이스 서버를 시작시킬 것입니다. 그리고 코드를 전혀 수정하지 않고 현재 운영에 사용하고 있는 데이터베이스를 분리하고 새로운 데이터베이스를 연결할 수 있습니다.
diff --git a/content/ko/build-release-run.md b/content/ko/build-release-run.md
new file mode 100644
index 000000000..00ff6aee9
--- /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..28d54f827
--- /dev/null
+++ b/content/ko/codebase.md
@@ -0,0 +1,17 @@
+## I. 코드베이스
+### 버전 관리되는 하나의 코드베이스와 다양한 배포
+
+Twelve-Factor 앱은 항상 [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), [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..b388c6a4c
--- /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](https://github.com/eventmachine/eventmachine), [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의 프로세스 관리자(예: [systemd](https://www.freedesktop.org/wiki/Software/systemd/))나 클라우드 플랫폼의 분산 프로세스 매니저, 혹은 [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..c1f033277
--- /dev/null
+++ b/content/ko/config.md
@@ -0,0 +1,22 @@
+## III. 설정
+### 환경(environment)에 저장된 설정
+
+애플리케이션의 *설정*은 [배포](./codebase) (스테이징, 프로덕션, 개발 환경 등) 마다 달라질 수 있는 모든 것들입니다. 설정에는 다음이 포함됩니다.
+
+* 데이터베이스, 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..99a2e7f74
--- /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를 이용하여 모든 종속성을 완전하고 엄격하게 선언합니다. 더나아가, *종속성 분리* 툴을 사용하여 실행되는 동안 둘러싼 시스템으로 암묵적인 종속성 "유출"이 발생하지 않는 것을 보장합니다. 이런 완전하고 명시적인 종속성의 명시는 개발과 서비스 모두에게 동일하게 적용됩니다.
+
+예를 들어, 루비에서 사용되는 [Bundler](https://bundler.io/)는 종속성 선언을 위해 `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`을 사용하는 경우가 있습니다. 이러한 툴들은 대부분의 시스템에 존재하지만, 모든 시스템에 존재하는 것이 보장되는 것은 아닙니다. 미래의 시스템에서는 존재하지 않을 수 있으며, 호환되는 버전이 있으라는 보장도 없습니다. 애플리케이션에게 시스템 도구가 필요하다면, 그 도구를 애플리케이션과 통합해야 합니다.
diff --git a/content/ko/dev-prod-parity.md b/content/ko/dev-prod-parity.md
new file mode 100644
index 000000000..eb90cdd47
--- /dev/null
+++ b/content/ko/dev-prod-parity.md
@@ -0,0 +1,77 @@
+## X. dev/prod 일치
+### development, staging, production 환경을 최대한 비슷하게 유지
+
+역사적으로, 개발 환경(애플리케이션의 개발자가 직접 수정하는 로컬의 [배포](./codebase))과 production 환경(최종 사용자가 접근하게 되는 실행 중인 배포) 사이에는 큰 차이가 있었습니다. 이러한 차이는 3가지 영역에 걸처 나타납니다.
+
+* **시간의 차이**: 개발자가 작업한 코드는 production에 반영되기까지 며칠, 몇주, 때로는 몇개월이 걸릴 수 있습니다.
+* **담당자의 차이**: 개발자가 작성한 코드를 시스템 엔지니어가 배포합니다.
+* **툴의 차이**: production 배포는 아파치, MySQL, 리눅스를 사용하는데, 개발자는 Nginx, SQLite, OS X를 사용할 수 있습니다.
+
+**Twelve Factor App은 개발 환경과 production 환경의 차이를 작게 유지하여 [지속적인 배포](http://avc.com/2011/02/continuous-deployment/)가 가능하도록 디자인 되었습니다.** 위에서 언급한 3가지 차이에 대한 대응책은 아래와 같습니다.
+
+* 시간의 차이를 최소화: 개발자가 작성한 코드는 몇 시간, 심지어 몇 분 후에 배포됩니다.
+* 담당자의 차이를 최소화: 코드를 작성한 개발자들이 배포와 production에서의 모니터링에 깊게 관여합니다.
+* 툴의 차이를 최소화: 개발과 production 환경을 최대한 비슷하게 유지합니다.
+
+위의 내용을 표로 요약하면 아래와 같습니다.
+
+| + | 전통적인 애플리케이션 | +Twelve-Factor App | +
|---|---|---|
| 배포 간의 간격 | +몇 주 | +몇 시간 | +
| 코드 작성자와 코드 배포자 | +다른 사람 | +같은 사람 | +
| 개발 환경과 production 환경 | +불일치함 | +최대한 유사함 | +
| 종류 | +언어 | +라이브러리 | +어댑터 | +
|---|---|---|---|
| 데이터 베이스 | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| 큐(Queue) | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| 캐쉬 | +Ruby/Rails | +ActiveSupport::Cache | +메모리, 파일시스템, 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..a0c59d8a8
--- /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 zawsze jest zarządzana w systemie kontroli wersji takim jak [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), 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 sam 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..37375252f
--- /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ń) 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](https://github.com/eventmachine/eventmachine), [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. [systemd](https://www.freedesktop.org/wiki/Software/systemd/), 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..93cb1ea12
--- /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. [Bundler](https://bundler.io/) 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ę zależ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łączone.
diff --git a/content/pl/dev-prod-parity.md b/content/pl/dev-prod-parity.md
new file mode 100644
index 000000000..50e2234f4
--- /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://avc.com/2011/02/continuous-deployment/) 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 pode 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..610ddee68
--- /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 de 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..91d46fcb9
--- /dev/null
+++ b/content/pt_br/codebase.md
@@ -0,0 +1,17 @@
+## 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](https://www.mercurial-scm.org/), 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.
+* Múltiplas 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* (ou implantação) é 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, entretanto diferentes versões podem estar ativas em cada deploy. Por exemplo, um desenvolvedor tem alguns registros ainda não implantados no ambiente de teste, o ambiente de teste ainda tem registros não implantados 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..0bdca1eac
--- /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) em execução são apenas minimamente visível para os 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](https://github.com/eventmachine/eventmachine), [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 [systemd](https://www.freedesktop.org/wiki/Software/systemd/), 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..e4c11387d
--- /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 às vezes armazenam as configurações no código como constantes. Isto é uma violação da doze-fatores, a qual exige uma **estrita separação entre configuração e 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, as aplicações incluem a configuração em grupos nomeados (muitas vezes chamados de ambientes) que remetem 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..5eb220463
--- /dev/null
+++ b/content/pt_br/dependencies.md
@@ -0,0 +1,12 @@
+## 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, [Bundler](https://bundler.io/) 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..e54f5a332
--- /dev/null
+++ b/content/pt_br/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Paridade entre desenvolvimento e 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://avc.com/2011/02/continuous-deployment/) 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 desenvolvimento 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..7e8b4aafd
--- /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..27c0e1641
--- /dev/null
+++ b/content/ru/codebase.md
@@ -0,0 +1,17 @@
+## I. Кодовая база
+### Одна кодовая база, отслеживаемая в системе контроля версий, -- множество развёртываний
+
+Приложение двенадцати факторов всегда отслеживается в системе контроля версий, такой как [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) или [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..1e3b5b5a9
--- /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](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) и [Node.js](http://nodejs.org/). Но каждая индивидуальная виртуальная машина может масштабироваться только ограниченно (вертикальное масштабирование), поэтому приложение должно иметь возможность быть запущенным как несколько процессов на различных физических машинах.
+
+Модель, построенная на процессах в полной мере демонстрирует свои преимущества, когда приходит время масштабирования. [Отсутствие разделяемых данных и горизонтальное разделение процессов приложения двенадцати факторов](./processes) означает, что добавление большего параллелизма является простой и надёжной операцией. Массив процессов различного типа и количество процессов каждого типа называются *формированием процессов (process formation)*.
+
+Процессы приложения двенадцати факторов [никогда не должны демонизироваться](http://dustin.github.com/2010/02/28/running-processes.html) и записывать PID файлы. Вместо этого они должны полагаться на менеджер процессов операционной системы (например, [systemd](https://www.freedesktop.org/wiki/Software/systemd/), распределённый менеджер процессов на облачной платформе, или инструмент как [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..ea216d36f
--- /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..caffb63d3
--- /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").
+
+**Приложение двенадцати факторов никогда не зависит от неявно существующих, доступных всей системе пакетов.** Приложение объявляет все свои зависимости полностью и точно с помощью манифеста *декларации зависимостей*. Кроме того, оно использует инструмент *изоляции зависимостей* во время выполнения для обеспечения того, что неявные зависимости не "просочились" из окружающей системы. Полная и явная спецификация зависимостей применяется равным образом как при разработке, так и при работе приложения.
+
+Например, [Bundler](https://bundler.io/) в 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..8dde29b41
--- /dev/null
+++ b/content/ru/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Паритет окружений разработки и продуктива (Dev/prod parity)
+### Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими
+
+Исторически существуют значительные различия между разработкой (разработчик делает живые изменения на локальном [развёртывании](./codebase) приложения) и работой приложения (развёртывание приложения с доступом к нему конечных пользователей). Эти различия проявляются в трёх областях:
+
+* **Различие во времени:** разработчик может работать с кодом, который попадёт в рабочую версию приложения только через дни, недели или даже месяцы.
+* **Различие персонала**: разработчики пишут код, OPS инженеры разворачивают его.
+* **Различие инструментов**: разработчики могут использовать стек технологий, такой как Nginx, SQLite, и OS X, в то время как при рабочем развёртывании используются Apache, MySQL и Linux.
+
+**Приложение двенадцати факторов спроектировано для [непрерывного развёртывания](http://avc.com/2011/02/continuous-deployment/) благодаря минимизации различий между разработкой и работой приложения. Рассмотрим три различия, описанных выше:
+
+* Сделать различие во времени небольшим: разработчик может написать код, и он будет развёрнут через несколько часов или даже минут.
+* Сделать небольшими различия персонала: разработчик который написал код, активно участвует в его развёртывании и наблюдает за его поведением во время работы приложения.
+* Сделать различия инструментов небольшими: держать окружение разработки и работы приложения максимально похожими.
+
+Резюмируя сказанное выше в таблицу:
+
+| + | Традиционное приложение | +Приложение двенадцати факторов | +
|---|---|---|
| Время между развёртываниями | +Недели | +Часы | +
| Автор кода/тот кто разворачивает | +Разные люди | +Те же люди | +
| Окружение разработки/работы приложения | +Различные | +Максимально похожие | +
| Тип | +Язык | +Библиотека | +Адаптеры | +
|---|---|---|---|
| База данных | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Очередь сообщений | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Кэш | +Ruby/Rails | +ActiveSupport::Cache | +Память, файловая система, Memcached | +
+
+Zdroje je možné pripájať a odpájať od nasedení podľa ľubovôle. Napríklad, ak je databáza z dôvodu hardvérových problémov nestabilná, správca aplikácie môže rozbehnúť nový databázový server zo zálohy. Aktuálna produkčná databáza môže byť odpojená a nový databáza pripojená -- všetko bez zmien v kóde.
diff --git a/content/sk/build-release-run.md b/content/sk/build-release-run.md
new file mode 100644
index 000000000..897146c53
--- /dev/null
+++ b/content/sk/build-release-run.md
@@ -0,0 +1,19 @@
+## V. Build, release, run
+### Jasne oddelené fázy build, release a run
+
+[Kód](./codebase) sa transformuje do (nevývojárskeho) nasadenia troma krokmi:
+
+* *Krok build* transformuje kód v repozitári na vykonateľný balík nazývaný *build*. Použitím verzie kódu v čase commitu špecifikovaného nasadzovacím procesom, krok build stiahne [závislosti](./dependencies) a skompiluje binárky a assets.
+* *Krok release* zoberie build vytvorený predchádzajúcim krokom a skombinuje ho s aktuálnou [konfiguráciou](./config) pre dané nasadenie. Výsledok *release* obsahuje build a konfiguráciu pripravené na okamžité vykonanie v exekučnom prostredí.
+* *Krok run* (alebo "runtime") spustí aplikáciu v exekučnom prostredí naštartovaním aplikačných [procesov](./processes) voči danému release.
+
+
+
+**Dvanásť faktorová aplikácia striktne oddeľuje fázy build, release a run.** Napríklad: je nemožné spraviť zmeny v kóde počas jeho behu, keďže neexistuje spôsob, ako by sa tieto zmeny dostali späť do fázy build.
+
+Nástroje na nasadzovanie zvyčajne ponúkajú spôsoby na správu release, hlavne teda možnosť vrátiť sa na predchádzajúci release. Napríklad [Capistrano](https://github.com/capistrano/capistrano/wiki) si ukladá release v podpriečinku s názvom `releases`, kde je aktuálny release symlink na priečinok s aktuálnym releasom. Tento príkaz `rollback` umožňuje jednoducho a rýchlo vrátiť sa na predchádzajúci release.
+
+Každý release by mal vždy mať unikátne release ID, ako napríklad timestamp release (napríklad `2019-04-06-20:32:17`) alebo inkrementálne číslo (napr. `v100`). Releasy sú záznamy, ktoré iba pribúdajú a release sa nedá zmeniť potom jeho vytvorení. Každá zmenu musí vytvoriť nový release.
+
+Buildy inicializujú developeri aplikácie kedykoľvek sa nasadzuje nový kód. Vykonávanie behu sa na rozdiel od buildov vykonáva automaticky v prípade reštartu servera, alebo pri reštarte padnutého procesu správcom procesov. Preto by fáza spustenia mala mať čo najmenej pohyblivých častí, keďže problémy, ktoré so spustením aplikácie môžu nastať v strede noci, keď developeri nie sú k dispozícii. Fáza build môže byť komplexnejšia, keďže chyby sú vždy viditeľné developerom, ktorí spustili nasadenie.
+
diff --git a/content/sk/codebase.md b/content/sk/codebase.md
new file mode 100644
index 000000000..e4e911b35
--- /dev/null
+++ b/content/sk/codebase.md
@@ -0,0 +1,17 @@
+## I. Zdrojový kód
+### Jeden zdrojový kód vo verzionovacom systéme, veľa nasadení
+
+Dvanásť faktorová aplikácia je vždy uložená vo verzionovacom systéme ako napríklad [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), alebo [Subversion](http://subversion.apache.org/). Kópia databázy verzionovacieho systému sa nazýva *repozitár kódu*, často skrátene *repozitár* alebo len *repo*.
+
+*Zdrojový kód* je akýkoľvek repozitár (v centralizovanom verzionovacom systéme ako napr. Subversion), alebo akákoľvek skupina repozitárov, ktoré majú spoločný koreňový commit (v decentralizovanm verzionovacom systéme ako napr. Git).
+
+
+
+Vždy existuje korelácia jedna k jednej medzi zdrojovým kódom a aplikáciou:
+
+* Ak je to viacero zdrojových kódov, nie je to aplikácia -- je to distribuovaný systém. Každý komponent v distribuovanom systéme je aplikácia, a každá môže osobitne spĺňať dvanásť faktorov.
+* Viaceré aplikácie zdieľajúce jeden kód je porušenie dvanástich faktorov. Riešenie je oddelenie zdieľaného kódu do knižníc, ktoré sa pripoja pomocou [správy závislostí](./dependencies).
+
+Každá aplikácia má len jeden zdrojový kód, ale nasadení jednej aplikácie bude viacero. *Nasadenie* je bežiaca inštancia aplikácie. Typicky je to produkčný web a jeden alebo viacero testovacích webov. Navyše, každý developer má kópiu bežiacej aplikácie vo svojom vlastnom vývojovom prostredí, z ktorých každé sa ráta ako nasadenie.
+
+Zdrojový kód je rovnaký na všetkých nasadeniach, aj keď samozrejvie rôzne verzie môžu byť aktívne na rôznych nasadeniach. Napríklad, developer má niekoľko commitov, ktoré nie sú nasadené na testovacom prostredí a na testovacom prostredí sú commity, ktoré ešte nie sú na produkcii. Ale všetky zdieľajú jeden zdrojový kód a dá sa teda povedať, že sú rôznymi nasadeniami jednej aplikácie.
diff --git a/content/sk/concurrency.md b/content/sk/concurrency.md
new file mode 100644
index 000000000..d93c854e5
--- /dev/null
+++ b/content/sk/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. Concurrency
+### Škálovanie pomocou modelu procesov
+
+Každý počítačový program je po spustení reprezentovaný jedným alebo viac procesmi. Webové aplikácie sa objavujú v rôznych formách vykonávania procesov. Napríklad, PHP procesy bežia ako podprocesy Apachu, spustené na požiadanie podľa objemu požiadaviek. Java procesy prevzali opačný prístup, kde JVM poskytuje jeden masívny nadproces, ktorý si vyhradí veľké množstvo systémových prostriedkov (CPU a pamäte) pri spustení a súbežnosť spravuje interne cez vlákna. V obidvoch prípadoch sú bežiace procesy len minimálne viditeľné pre developera aplikácie.
+
+
+
+**V dvanásť faktorovej aplikácii sú procesy prvotriednymi obyvateľmi.** Procesy v dvanásť faktorovej aplikácii preberajú správanie z [modelu unix procesov pre démony služieb](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Použitím tohoto modelu, developer môže navrhnúť svoju aplikáciu tak, aby rôznu prácu vykonávali rôzne *typy procesov*. Napríklad, HTTP požiadavky môže spravovať webový proces, a dlho bežiace úlohy na pozadí môže spravovať worker proces.
+
+Toto nevylučuje, že si individuálne procesy nemôžu spravovať svoj interný multiplexing cez vlákna vnútri VM alebo interpretra, alebo async/event model v nástrojoch ako [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), alebo [Node.js](http://nodejs.org/). Keďže individuálne VM môže rásť len obmedzene (vertikálne škálovanie), aplikáciu musí byť tiež schopná sa rozšíriť na viacero procesov bežiacich na viacerých fyzických strojoch.
+
+Procesový model vyniká, keď príde čas rozširovania. [Nezdieľaná, horizontálne particionovateľná podstata procesov dvanásť faktorovej aplikácie](./processes) znamená, že pridanie väčšej súbežnosti je jednoduchá a spoľahlivá operácia. Súhrn typov procesov a počtu procesov každého typu sa nazýva *process formation*.
+
+Procesty dvanásť faktorovej aplikácie [by sa nikdy nemali démonizovať](http://dustin.github.com/2010/02/28/running-processes.html) alebo zapisovať PID súbory. Namiesto toho by sa mali spoliehať na manažéra procesov operačného systému (ako napr. [systemd](https://www.freedesktop.org/wiki/Software/systemd/), distribuovaného manažéra procesov na cloudovej platforme, alebo nástroji ako [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) počas vývoja) na spravovanie [výstupných streamov](./logs), reakcie na spadnuté procesy, a spravovanie userom iniciovaných reštartov a zastavení.
diff --git a/content/sk/config.md b/content/sk/config.md
new file mode 100644
index 000000000..02758b2b8
--- /dev/null
+++ b/content/sk/config.md
@@ -0,0 +1,22 @@
+## III. Konfigurácia
+### Konfigurácia uložená v prostredí
+
+*Konfigurácia* aplikácie je všetko, čo sa líši medzi [nasadeniami](./codebase) (staging, produkcia, vývojárske prostredie, atď). To zahŕňa:
+
+* Pripojenia k databázam, Memcached a iným [podporným službám](./backing-services)
+* Prihlasovacie údaje k externým službám ako Amazon S3 alebo Twitter
+* Špeciálne hodnotu Per-nasadenie values such ako napríklad kanonické názvy hostov.
+
+Aplikácia si niekedy ukladá konštanty v kóde. Toto je porušenie dvanástich faktorov, ktoré vyžaduje **striktné oddelenie konfigurácie od kódu**. Konfigurácia sa medzi nasadeniami podstatne odlišuje, kód nie.
+
+Litmusovým testom správneho oddelenia konfigurácie, je to či by mohla byť v ktoromkoľvek momente open-sourcovaná bez úniku prihlasovacích údajov.
+
+Všimnite si, že definícia "konfigurácie" **nezahŕňa** internú konfiguráciu aplikácie, ako napríklad `config/routes.rb` v Rails, alebo [prepojenie modulov](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) v [Spring](http://spring.io/). Tento typ konfigurácie sa medzi nasadeniami nelíši, a preto je najlepšie ho nechať v kóde.
+
+Ďalšou možnosťou, ako pristupovať ku konfiguráciám je mať konfiguračné súbory, ktoré nie sú uložené v revíznom systéme, ako napríklad `config/database.yml` v Rails. Je to obrovské zlepšenie oproti konštantám uloženým v repozitári, ale stále má slabosť: je veľmi jednoduché omylom tento súbor uložiť do repozitára; je tendencia mať konfiguračné súbory na rôznych miestach a v rôznych formátoch, a preto je ťažké ich spravovať z jedného miesta. Navyše, tieto formáty zvyknú byť špecifické pre jazyk alebo framework.
+
+**Dvanásť faktorová aplikácia konfiguráciu ukladá v *premenných prostredia*** (často skrátané na *env vars* alebo *env*). Premenné prostredia sa dajú jednoducho meniť pri nasadeniach bez potreby zmeny v kóde; na rozdiel od konfiguračných súborov je minimálna šanca, že ich niekto omylom uloží do repozitára; a narozdiel od rôznych konfiguračných súborov, alebo iných konfiguračných mechanizmov ako napr. Java System Properties, premenné prostredia sú nezávislé na jazyku alebo OS.
+
+Ďalším pohľadom na správu konfigurácie je zoskupovanie. Niekedy aplikácie zoskupia konfigurácie do pomenovaných skupín (často nazývaných called "prostredia") a sú pomenované podľa jednotlivých typov nasadení, ako napríklad `development`, `test`, a `production` prostredia v Rails. Tento spôsob je náročné škálovať čistým spôsobom: ako pribúdajú ďalšie typy nasadení, je potrebné vytvárať nové názvy prostredí, ako napríklad `staging` alebo `qa`. Ako projekt ďalej rastie, developeri môžu pridávať ďalšie vlastné špeciálne prostredia ako `joes-staging`, a výsledkom je kombinatorická explózia konfiguračných prostredí a tým sa stáva spravovanie nasadení veľmi citlivé.
+
+V dvanásť faktorovej aplikácii sú premenné prostredia granulárne nastavenia, každé ortogonálne k inej premennej prostredia. Nikdy sa nezoskupujú spolu do pomenovaných "prostredí", ale namiesto toho sú nezávisle spravované pre každé nasadenie. Tento model sa plynule škáluje počas prirodzeného rastu aplikácie ako pribúdajú ďalšie typy nasadení.
diff --git a/content/sk/dependencies.md b/content/sk/dependencies.md
new file mode 100644
index 000000000..d019b44b0
--- /dev/null
+++ b/content/sk/dependencies.md
@@ -0,0 +1,12 @@
+## II. Závislosti
+### Explicitne deklarované a izolované závislosti
+
+Väčšina programovacích jazykov poskytuje distribučný systém knižníc, napríklad [CPAN](http://www.cpan.org/) pre Perl alebo [Rubygems](http://rubygems.org/) pre Ruby. Knižnice nainštalované cez balíčkovací systém sa dajú nainštalovať pre celý systém (nazývané "site packages") alebo len v rámci priečinka s aplikáciou (nazýva sa "vendoring" alebo "bundling").
+
+**Dvanásť faktorová aplikácia sa nikdy nespolieha na implicitnú existenciou systémových balíčkov.** Svoje závislosti deklaruje úplne a presne, pomocou *deklaráciu závislostí*. Ďalej používa nástroj na *izoláciu závislostí*, pre istotu, aby žiadne implicitné závislosti "nepretiekli" z vonkajšieho systému. Špecifikácia závislostí je úplná a explicitná a používa sa rovnako na produkcii tak aj pri vývoji.
+
+Napríklad, [Bundler](https://bundler.io/) pre Ruby poskytuje `Gemfile` manifest format na deklaráciu závislostí a `bundle exec` na izoláciu závislostí. V pythone sú na to dva rôzne nástroje -- [Pip](http://www.pip-installer.org/en/latest/) sa používa na deklaráciu a [Virtualenv](http://www.virtualenv.org/en/latest/) na izoláciu. Dokonca aj C má [Autoconf](http://www.gnu.org/s/autoconf/) na deklaráciu závislostí, a statické linkovanie poskytuje izoláciu závislostí. Nezáleží na nástrojoch, deklarácia závislostí a izolácia sa musia vždy používať spolu -- len jedno alebo druhé nestačí na splnenie dvanástich faktorov.
+
+Jednou z výhod explicitnej deklarácie závislosí je to, že zjednodušuje rozbehanie aplikácie pre nových developerov. Nový developer si len naklonuje repozitár aplikácie do svojho vývojárskeho prostredia a ako prerekvizity mu stačí mať nainštalovaný kompilátor jazyka a manažér závislostí. Všetko potrebné na rozbehanie aplikácie sa dotiahne deterministickým *build príkazom*. Napríklad, build príkaz pre Ruby/Bundler je `bundle install`, pre Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) je to `lein deps`.
+
+Dvanásť faktorová aplikácia nezávisí na implicitnej existencii akéhokoľvek systémového nástroja. Príkladom môže byť spustenie ImageMagick alebo `curl` cez shell. Napriek tomu, že tieto nástroje môžu existovať na veľa alebo aj väčšine systémov, neexistuje záruka, že budú existovať na všetkých systémoch, na ktorých bude aplikácia bežať v budúcnosti, alebo, že verzia na budúcom systéme bude kompatibilná s aplikáciou. Ak aplikácia potrebuje spúšťať systémový nástroj cez shell, daný nástroj by mal byť zahrnutý do aplikácie.
diff --git a/content/sk/dev-prod-parity.md b/content/sk/dev-prod-parity.md
new file mode 100644
index 000000000..f460e049d
--- /dev/null
+++ b/content/sk/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Dev/prod parity
+### Vývojové, testovacie a produkčné prostredie sú čo najpodobnejšie ako sa dá
+
+Historicky bývali podstatné rozdiely medzi vývojovým prostredím (developer upravoval živé lokálne [nasadenie](./codebase)) a produkčným prostredím (bežiace nasadenie aplikácie, na ktoré pristupujú používatelia). Tieto rozdiely sa prejavujú v týchto troch oblastiach:
+
+* **Časový rozdiel:** Developer môže pracovať na kóde, ktorý trvá dni, týždne alebo dokonca mesiace pred tým ako sa dostane na produkciu.
+* **Personálny rozdiel**: Developeri píšu kód, systémový administrátory ho nasadzujú.
+* **Nástrojový rozdiel**: Developeri môžu používať Nginx, SQLite, a OS X, pričom na produkcii beží Apache, MySQL, a Linux.
+
+**Dvanásť faktorová aplikácia je navrhnutá pre [continuous deployment](http://avc.com/2011/02/continuous-deployment/) tak, že udržiava rozdiely medzi vývojom a produkciou.** Keď sa pozrieme na tri rozdiely popísané vyššie:
+
+* Zmenšite časový rozdiel: developer napíše kód a nasadí ho v priebehu hodín alebo dokonca minút.
+* Zmenšite personálny rozdiel: developeri, ktorí kód píšu by mali byť prítomní pri nasadzovaní a sledovaní správania na produkcii.
+* Zmenšite nástrojvý rozdiel: udržujte vývojové a produkčné prostredie nakoľko sa dá rovnaké.
+
+Súhrn vyššie napísaného v tabuľke:
+
+| + | Tradičná aplikácia | +Dvanásť faktorová aplikácia | +
|---|---|---|
| Čas medzi nasadeniami | +Týždne | +Hodiny | +
| Autori kódu vs nasadzovači kódu | +Rôzni ľudia | +Rovnakí ľudia | +
| Vývojárske vs produkčné prostredie | +Rozdielne | +Čo najpodobnejšie | +
| Typ | +Jazyk | +Knižnica | +Adapér | +
|---|---|---|---|
| Databáza | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Fronta | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Cache | +Ruby/Rails | +ActiveSupport::Cache | +Pamäť, súborový systém, Memcached | +
+
+ทรัพยากรสามารถแนบและถอดออกจาก deploy ได้ ตัวอย่างเช่น ถ้าฐานข้อมูลของ app ทำงานผิดปรกติเนื่องจากปัญหาของฮาร์ดแวร์ ผู้ดูแลระบบของ app อาจจะ spin up เซิร์ฟเวอร์ฐานข้อมูลขึ้นมาใหม่จากการข้อมูลที่สำรองล่าสุด ฐานข้อมูลของ production ปัจจุบันควรจะถอดออกและแนบด้วยฐานข้อมูลใหม่ -- ทั้งหมดนี้ไม่มีการเปลี่ยนแปลง code
diff --git a/content/th/build-release-run.md b/content/th/build-release-run.md
new file mode 100644
index 000000000..04366e58b
--- /dev/null
+++ b/content/th/build-release-run.md
@@ -0,0 +1,19 @@
+## V. Build, release, run
+### แยกขั้นตอนของการ build และ run อย่างเคร่งครัด
+
+[codebase](./codebase) จะเปลี่ยนแปลงไปเป็น (non-development) deploy ด้วย 3 ขั้นตอน:
+
+* *ขั้นตอนการ build* เป็นการแปลงซึ่งเป็นการเปลี่ยน code repo ไปเป็นโปรแกรมที่ทำงานได้ (executable bundle) เรียกว่าการ *build* ใช้ version ของ code ที่ระบุ commit ด้วยกระบวนการ deployment ซึ่งขั้นตอนการ build นี้จะดึง[การอ้างอิง](./dependencies) และ compile เป็น binariy และ assets.
+* *ขั้นตอนการ release* จะนำ build ที่ได้จากขั้นตอนการ build และรวามเข้ากับ [การตั้งค่า](./config) ของ deploy ซึ่งจะได้ *release* ที่มีทั้ง build และ การตั้งค่า ที่พร้อมจะทำงานได้ในสิ่งแวดล้อมการทำงาน
+* *ขั้นตอนการ run* (หรือเรียกว่า "runtime") เป็นการทำให้ app ทำงานในสิ่งแวดล้อมการทำงาน ด้วยการเริ่มใช้งานบางเซตของ app [processes](./processes) ด้วย release ที่ถูกเลือก
+
+
+
+**Twelve-factor app ใช้การแยกขั้นตอนการ build, release และ run ออกจากกันอย่างเคร่งครัด** ตัวอย่างเช่น เป็นไปไม่ได้ที่ทำการเปลี่ยนแปลงของ code ในขณะทำงาน เนื่องจากไม่มีวิธีใดในการเผยแพร่การเปลี่ยนแปลงกลับสู่สถานะ build
+
+เครื่องมื่อสำหรับ deployment โดยทั่วไปจะมีเครื่องมือจัดการการ release อยู่แล้ว และส่วนใหญ่จะมีความสามารถ roll back กลับสู่ release ก่อนหน้าได้ ตัวอย่างเช่น [Capistrano](https://github.com/capistrano/capistrano/wiki) เป็นเครื่องมือ deployment ที่เก็บการ release ในไดเรกทอรีย่อยชื่อว่า `releases` ที่ซึ่ง release ปัจจุบันเชื่อมโยงเข้ากับไดเรกทอรี release ปัจจุบัน สามารถใช้คำสั่ง `rollback` เพื่อทำให้มัน roll back กลับไปเป็น release ก่อนหน้าอย่างรวดเร็ว
+
+ทุกๆ release ควรจะมี release ID เฉพาะเสมอ เช่น timestamp ของ release (เช่น `2011-04-06-20:32:17`) หรือจำนวนนับที่เพิ่มขึ้น (เช่น `v100`), release เป็นบัญชีแยกประเภทที่เพิ่มขึ้นได้เท่านั้นและ release ไม่สามารถแก้ไขได้เมื่อถูกสร้างขึ้นแล้ว ทุกๆ การเปลี่ยนแปลงจำเป็นต้องสร้าง release ใหม่เสมอ
+
+การ build เริ่มต้นโดย developer ของ app เมื่อไรก็ตามที่ code ใหม่ถูก deploy, การทำงานในขณะทำงาน ในทางตรงกันข้าม สามารถเกิดขึ้นได้โดยอัตโนมัติในกรณีที่ server reboot หรือ crashed process ถูก restart โดย process manager ดังนั้นขั้นตอนการ run ถูกทำให้มีขั้นตอนน้อยที่สุดเท่าที่จะเป็นไปได้ เพื่อป้องกันปัญหา app สามารถหยุดการทำงานได้ในเวลาตอนกลางคืนเมื่อไม่มี developer อยู่ทำงาน ขั้นตอนการ build สามารถเป็นขั้นตอนที่ซับซ้อนได้ ในเมื่อ error จะแสดงต่อ developer ผู้ซึ่งทำการ deploy มัน
+
diff --git a/content/th/codebase.md b/content/th/codebase.md
new file mode 100644
index 000000000..6888ce90c
--- /dev/null
+++ b/content/th/codebase.md
@@ -0,0 +1,18 @@
+## I. Codebase
+### มีเพียง codebase เดียวที่ติดตามด้วย version control, มีหลาย deploy
+
+Twelve-factor app สามารถติดตามได้เสมอด้วย version control เช่น [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), หรือ [Subversion](http://subversion.apache.org/) สำเนาของฐานข้อมูลติดตาม version เรียกว่า *code repository* หรือเรียกสั้นๆว่า *code repo* หรือเรียกเพียงแค่ *repo*
+
+*codebase* เป็น repo เดียวใดๆ (ในระบบ version control ที่มีศูนย์กลางอย่างเช่น Subversion) หรือเป็นเซตของ repo ซึ่งแบ่งปัน root commit (ในระบบ version control ที่ไม่มีศูนย์กลางอย่างเช่น Git)
+
+
+
+มีความสัมพันธ์แบบ หนี่ง-ต่อ-หนึ่ง เสมอ ระหว่าง codebase และ app:
+
+* ถ้ามีหลาย codebase, จะไม่เป็น app -- จะเป็นระบบกระจาย (distributed system) แต่ละคอมโพแนนท์ในระบบกระจายเป็น app, และแต่ล่ะคอมโพแนนท์จะปฏิบัติตาม twelve-factor
+* ถ้ามีหลาย app ที่ใช้งาน code เดียวกันจะเป็นการละเมิด twelve-factor วิธีแก้ปัญหาในที่นี้คือเอา code ที่ใช้ร่วมกันทำเป็น libraries ซึ่งสามารถเข้ากับ factor [dependency manager](./dependencies)
+
+มีเพียงหนึ่ง codebase ต่อ app แต่มีหลาย deploy หรือการนำไปใช้งานของ app, หนึ่ง *deploy* จะรัน instance ของ app นี่เป็น production site และมีหนึ่งหรือมากว่า staging site เพิ่มเติม, developer ทุกคนจะมีสำเนาเดียวของ app ที่ทำงานอยู่บนสิ่งแวดล้อมพัฒนาในเครื่องของตนเอง ซึ่งจัดได้ว่าเป็น deploy ด้วยเช่นกัน
+
+Codebase จะเหมือนกันตลอดทั้ง deploy ทั้งหมด แม้ว่า version จะแตกต่างกันอาจจะทำงานในแต่ล่ะ deploy ตัวอย่างเช่น developer มีบาง commit ที่ยังไม่ได้ deploy ไปยัง staging ซึ่ง staging จะมีบาง commit ที่ยังไม่ได้ deploy ไปยัง production แต่ทั้งหมดจะใช้ codebase เดียวกัน ดังนั้นจะต้องทำให้ระบุตัวตนได้ว่าเป็น deploy ที่แตกต่างกันของ app เดียวกัน
+
diff --git a/content/th/concurrency.md b/content/th/concurrency.md
new file mode 100644
index 000000000..2d616b786
--- /dev/null
+++ b/content/th/concurrency.md
@@ -0,0 +1,15 @@
+## VIII. Concurrency
+### ขยายออกของแอพพลิเคชันด้วยรูปแบบ process
+
+โปรแกรมคอมพิวเตอร์ใดๆ เมื่อทำงานแล้วจะถูกแทนที่ด้วย 1 หรือมากกว่า process เว็บแอพมีหลายรูปแบบของ process-execution ตัวอย่างเช่น PHP process ทำงานเป็น process ลูกของ Apache, เริ่มต้นตามความต้องการตามปริมาณคำขอ, Java process มีวิธีที่ตรงกันข้ามซึ่ง JVM จะใช้หนึ่ง uberprocess ขนาดใหญ่ที่สงวนบล็อกขนาดใหญ่สำหรับทรัพยากรระบบ (CPU และหน่วยความจำ) ในตอนเริ่มต้น ซึ่งจัดการ concurrency ภายในด้วย thread ทั้งสองกรณี process ที่ทำงานเป็นส่วนที่มองเห็นน้อยมากสำหรับ developer ของ app
+
+
+
+**ใน twelve-factor app, process เป็นพลเมืองชั้นหนึ่ง** Process ใน twelve-factor app จะใช้คำแนะนำจาก [the unix process model for running service daemons](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/) การใช้รูปแบบนี้ developer สามารถออกแบบ app เพื่อจัดการกับ workload ที่หลากหลายโดยการกำหนดให้ work แต่ละชนิดเป็น *process type** ตัวอย่างเช่น HTTP request อาจจะจัดการด้วย web process และ long-running background tasks จัดการด้วย worker process
+
+ไม่รวม process ย่อยจากการจัดการ multiplexing ภายใน ด้วย thread ข้างใน runtim VM หรือ async/evnted model ที่พบในเครื่องมือเช่น [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) หรือ [Node.js](http://nodejs.org/) แต่ VM แต่ละตัวสามารถเติบโตได้มากเท่านั้น (การขยายแนวตั้ง) ดังนั้น application จำเป็นต้องสามารถขยายเป็นหลาย process ทำงานบนหลายเครื่องได้
+
+รูปแบบ process ดีมากเมือมากับ time to scale out [share-nothing, horizontally partitionable nature of twelve-factor app processes](./processes) หมายความว่าเพิ่ม concurrency ได้ง่ายและทำงานได้น่าเชื่อถือ อาเรย์ชนิดของ process และจำนวนของ process ของแต่ละชนิด รู้จักกันใน *process formation*
+
+Process ของ twelve-factor app [should never daemonize](http://dustin.github.com/2010/02/28/running-processes.html) หรือเขียนไฟล์ PID แต่จะขึ้นอยู่กับตัวจัดการ process ของระบบปฏิบัติการแทน (เช่น [systemd](https://www.freedesktop.org/wiki/Software/systemd/), ตัวจัดการ process กระจายบน cloud platform หรือเครื่องมือ อย่างเช่น [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) ใน development) เพื่อจัดการ [output streams](./logs) ตอบสนองต่อ process ที่ล้มเหลว และจัดการ user-initiated restarts และ shutdowns
+
diff --git a/content/th/config.md b/content/th/config.md
new file mode 100644
index 000000000..d094dd929
--- /dev/null
+++ b/content/th/config.md
@@ -0,0 +1,22 @@
+## III. Config
+### จัดเก็บการตั้งค่า (config) ไว้ในสิ่งแวดล้อมของระบบ
+
+*การตั้งค่า (config)* ของ app เป็นสิ่งที่เปลี่ยนแปลงระหว่าง [deploys](./codebase) (staging, production, developer environments เป็นต้น) รวมทั้ง:
+
+* ทรัพยากรที่จัดการกับฐานข้อมูล, Memcached, และ [backing services](./backing-services) อื่นๆ
+* ข้อมูลประจำตัว (credentials) สำหรับบริการภายนอก อย่างเช่น Amazon S3 หรือ Twitter
+* ค่า Pre-deploy อย่างเช่น canonical hostname สำหรับ deploy
+
+บางครั้ง app เก็บการตั้งค่าเป็นค่าคงทีใน code เป็นการละเมิด twelve-factor ซึ่งต้องการให้ **แยกการตั้งค่าออกจาก code อย่างสมบูรณ์** การตั้งค่าสามารถเปลี่ยนแปลงได้ตาม deploy ที่ไม่อยู่ใน code
+
+การทดสอบ litmus เพื่อดูว่า app มีการเอาการตั้งค่าทั้งหมดออกจาก code ถูกต้องหรือไม่ ทำให้ codebase สามารถ open source ได้ตลอดเวลา โดยไม่กระทบกับ credential ใดๆ
+
+โปรดทราบว่าการนิยามนี้ของ "การตั้งค่า" **ไม่**รวมการตั้งค่า internal application อย่างเช่น `config/routes.rb` ใน Rails หรือ [code modules เชื่อมต่อกันอย่างไร](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) ใน [Spring](http://spring.io/) ชนิดของการตั้งค่าเหล่านี้ไม่เปลี่ยนแปลงตาม deploy และควรจะอยู่ใน code
+
+อีกวิธีการหนึ่งของการตั้งค่าคือการใช้ไฟล์การตั้งค่าซึ่งไม่รวมไว้ใน revision control อย่างเช่น `config/database.yml` ใน Reals ซึ่งเป็นการพัฒนาสำหรับการใช้ค่าคงที่ซึ่งถูกรวมเข้าไปใน code repo แต่ก็ยังมีจุดอ่อนคือมันจะเกิดความผิดพลาดจากการที่รวมค่าการตั้งค่านี้เข้าไปใน repo จะทำให้มีแนวโน้มที่การไฟล์การตั้งค่าจะกระจายอยู่ในที่แตกต่างกันและแตกต่างรูปแบบ ทำให้มันยากที่จะดูแลและจัดการการตั้งค่าทั้งหมดในหนึ่งที่ นอกจากนี้รูปแบบเหล่านี้ยังขึ้นอยู่กับภาษาคอมพิวเตอร์ หรือ เฉพาะ framework.
+
+**Twelve-factor app เก็บการตั้งค่าไว้ใน *environment variable*** (เรียกสั้นๆ ว่า *env vars* หรือ *env*) Env vars จะทำให้ง่ายที่จะเปลี่ยนแปลงระหว่าง deloy โดยปราศจากการเปลี่ยนแปลงของ code ใดๆ ไม่เหมือนกับไฟล์การตั้งค่าที่จะมีโอการผิดพลาดที่จะรวมเข้าไปใน code repo ได้ และไม่เหมือนกับไฟล์การตั้งค่าที่กำหนดเองหรือกลไกการตั้งค่าอื่นๆ อย่างเช่น Java System Properties ที่เป็ของภาษาคอมพิวเตอร์ และมาตรฐานของระบบปฏิบัติการ (OS-agnostic)
+
+อีกแง่มุมของการจัดการการตั้งค่าคือการจัดกลุ่ม (Grouping) บางครั้งการตั้งค่า app แบบกลุ่ม (batch) ในชื่อของกลุ่ม (เรียกว่า "environment") หลังจาก deploy เฉพาะ อย่างเช่น `development`, `test` และ `production` environment ใน Rails วิธีการนี้ทำให้การขยายไม่เรียบร้อยทำให้มี deploy ของ app ถูกสร้างมากขึ้น, จำเป็นต้องตั้งชื่อของ environment ใหม่ อย่างเช่น `staging` หรือ `qa` เป็นตั้น เมื่อ project โตขึ้น developer อาจจะเพิ่ม environments เฉพาะของตัวเองขึ้นมา เช่น `joes-staging` ผมก็คือมีการตั้งค่าจำนวนมากเกินไปซึ่งทำให้จัดการ deploy ของ app ทำได้ยากมาก
+
+ใน twelve-factor app, env vars เป็นรากฐานการควบควมของแต่ล่ะ evn vars อื่นๆ ไม่เคยมีการจัดกลุ่มเป็น "environments" แต่จะจัดการแบบอิสระสำหรับแต่ล่ะ deploy แทน นี่เป็นรูปแบบที่การขยายทำได้อย่างราบรื่นของ app เป็นการขยายโดยธรรมชาติของ deploy มากขึ้นตลอดอายุการทำงานของ app.
diff --git a/content/th/dependencies.md b/content/th/dependencies.md
new file mode 100644
index 000000000..652695987
--- /dev/null
+++ b/content/th/dependencies.md
@@ -0,0 +1,12 @@
+## II. Dependencies
+### มีการประกาศและแยกการอ้างอิง (dependency) ทั้งหมดอย่างชัดเจน
+
+ภาษาโปรแกรมส่วนใหญ่จะมีระบบ packaging สำหรับรองรับ library ต่างๆ อย่างเช่น [CPAN](http://www.cpan.org/) สำหรับ Perl หรือ [Rubygems](http://rubygems.org/) สำหรับ Ruby, Library จะถูกติดตั้งผ่านทางระบบ packaging สามารถติดตั้ง system-wide (เรียกว่า "site packages") หรือกำหนดขอบเขตเป็นไดเรกทรอรีที่มี app (เรียกว่า "vendoring" หรือ "bundling")
+
+**twelve-factor app ไม่ขึ้นอยู่กับ implicit existence of system-wide packages.** โดยประกาศการอ้างอิงทั้งหมด อย่างครบถ้วน และอย่างแน่นอน ด้วย *dependency declaration* manifest นอกจากนี้ใช้เครื่องมือ *dependency isolation* ระหว่างทำงานเพื่อให้แน่ใจว่าไม่มีการอ้างอิงแบบปริยาย "รั่ว (leak in)" จากระบบรอบๆ, รายละเอียดการอ้างอิงที่ครบถ้วนและชัดเจนใช้รูปแบบเดียวกันทั้ง production และ development
+
+ตัวอย่างเช่น [Bundler](https://bundler.io/) สำหรับ Ruby มีรูปบบ `Gemfile` manifest สำหรับประการการอ้างอิง และ `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/) สำหรับประการการอ้างอิง และ static linking สามารถทำแยกการอ้างอิงได้ ไม่ว่าจะใช้เครื่องมืออะไรก็ตามแต่การประการศและแยกการอ้างอิงจำเป็นเสมอที่ใช้ร่วมกัน -- ถ้ามีเพียงหนึ่งหรืออื่นๆ ไม่เพียงพอที่ตรงตาม twelve-factor
+
+ประโยชน์อย่างหนึ่งของการประกาศการอ้างอิงที่ชัดเจนคือลดความยุ่งยากในการติดตั้งสำหรับ developer ใหม่สำหรับ app, developer ใหม่สามารถ check out codebase ของ app มายังเครื่องที่ใช้ development ต้องการเพียงแค่ติดตั้ง language runtime และ dependency manager เป็นข้อกำหนดเบื้องต้น พวกเขาจะสามามารถติดตั้งทุกสิ่งที่ต้องการเพื่อจะรัน code ของ app ด้วย *build command* ตัวอย่างเช่น ใช้ build command สำหรับ Ruby/Bundler คือ `bundle install` ขณะที่ Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) คือ `lein deps`
+
+Twelve-factor app ยังคงไม่ขึ้นอยู่กับเครื่องมือที่มีอยู่แล้ว ตัวอย่างเช่นใช้ shell out ไปยัง ImageMagick หรือ `curl` ขณะที่เครื่องมือเหล่านี้อาจจะมีอยู่บนระบบส่วนใหญ่แล้ว ซึ่งจะไม่รับประกันว่าจะมีอยู่บนเครื่องทั้งหมดซึ่ง app จะทำงานในอนาคต หรือ version ที่หาเจอในเครื่องที่จะไปทำงานในอนาคตจะเข้ากันได้กับ app ถ้า app จำเป็น shell out ใช้เครื่องมือของเครื่อง ที่เครื่องมืออาจจะ vendord ให้ app
diff --git a/content/th/dev-prod-parity.md b/content/th/dev-prod-parity.md
new file mode 100644
index 000000000..ef98f74c8
--- /dev/null
+++ b/content/th/dev-prod-parity.md
@@ -0,0 +1,78 @@
+## X. Dev/prod parity
+### ทำให้ development, staging และ production ให้มีความใกล้เคียงกันที่สุด
+
+ในอดีต มีช่องว่างที่มากมายระหว่าง development (developer แก้ไข app ในเครื่องตัวเอง [deploy](./codebase)) และ production (deploy ที่ทำงานและใช้งานโดยผู้ใช้งานที่แท้จริง) ช่องว่างที่ชัดเจนมี 3 เรื่่อง:
+
+* **ช่องว่างของเวลา** developer จะทำงานบน code ที่ใช้เวลาเป็นวัน, เป็นอาทิตย์ หรือเป็นเดือนที่จะเอาขึ้นสู่ production
+* **ช่องว่างของบุคคล** developer เขียน code แต่วิศวกร ops ทำการ deploy code
+* **ช่องว่างของเครื่องมือ** developer อาจจะใช้ stack อย่างเช่น Nginx, SQLite และ OSX ขณะที่ production deploy ใช้ Apache, MySQL และ Linux
+
+**Twelve-factor app ถูกออกแบบสำหรับ [การ deployment อย่างต่อเนื่อง (continuous deployment)](http://avc.com/2011/02/continuous-deployment/) ด้วยการรักษาช่องว่างระหว่าง development และ production ให้แคบที่สุด** โดยพิจารณาจากช่องว่าง 3 เรื่องด้านบน:
+
+* ทำให้เวลาสั้นลง: developer อาจจะเขียน code และทำการ deploy ในเวลาเพียงชั่วโมงเดียวหรือเพียงไม่กี่นาทีหลังจากเขียน code เสร็จ
+* ทำให้ช่องว่างบุคคลแคบลง: developer เป็นคนเขียน code และเป็นคนที่ deploy code เองและเป็นคนที่ดูใน production เอง
+* ทำให้ช่องว่างเครื่องมือแคบลง: ทำให้ใช้เครื่องมือ developement และ production เหมือนกันมากที่สุดเท่าที่จะทำได้
+
+สรุปข้างบนเป็นตาราง:
+
+| + | Traditional app | +Twelve-factor app | +
|---|---|---|
| เวลาระหว่าง deploys | +สัปดาห์ | +ชั่วโมง | +
| คนเขียน code vs คน deploy code | +คนละคน | +คนเดียวกัน | +
| สภาพแวดล้อม Dev vs 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 | +
+
+Kaynaklar dağıtımlara istenilen zamanda eklenilip çıkartılabilir. Örneğin, eğer uygulamanın veritabanı donanımsal sorunlar yaşıyorsa, uygulamanın yöneticisi son yedeklemeden geri yüklenmiş yeni bir veritabanı sunucusu oluşturabilir. Problemli veritabanının uygulamadan bağlantısı kesilip, yeni veritabanı bağlanabilir, hem de hiçbir kod değişikliği olmadan.
diff --git a/content/tr/build-release-run.md b/content/tr/build-release-run.md
new file mode 100644
index 000000000..fa0c99184
--- /dev/null
+++ b/content/tr/build-release-run.md
@@ -0,0 +1,18 @@
+## V. Derleme, yayınlama, çalıştırma
+### Derleme ve çalıştırma aşamalarını tam olarak ayırma
+
+Bir [kod tabanı](./codebase) üç aşamada (geliştirme dağıtımı olmayan) dağıtıma dönüşür:
+
+* *Derleme aşaması* kod deposunun *derleme* olarak bilinen çalıştırılabilir bir pakete çevrilmesidir. Dağıtım evresi tarafından seçilen commit'teki kod kullanılır. Sistem, üçüncü parti [bağımlılıkları](./dependencies) toparlar ve çalıştırılabilirleri ve statik dosyaları derler.
+* *Yayınlama aşaması*, derleme aşaması tarafından üretilmiş derlemeyi alır ve dağıtımı güncel [yapılandırmasıyla](./config) birleştirir. Son durumda oluşan *yayın* derleme ve yapılandırmanın ikisini de içerir ve çalışma ortamında çalıştırmak için hazırdır.
+* *Çalıştırma evresi* (aynı zamanda "runtime" olarak bilinir) seçili yayının karşılığındaki [süreçleri](./processes) başlatarak, çalıştırma ortamındaki uygulamayı çalıştırır.
+
+
+
+**On iki faktör uygulamalarının derleme, yayınlama ve çalıştırma aşamaları tamamen birbirinden bağımsızdır.** Örneğin, koddaki değişiklikleri derleme aşamasına geri döndürmenin bir yolu olmadığı için çalışma zamanında kodda değişiklik yapmak imkansızdır.
+
+Dağıtım araçları genelde yayın yönetim araçları da sunar. En dikkat çeken yetenekleri ise bir önceki yayına geri dönebilmeleridir. Örneğin, [Capistrano](https://github.com/capistrano/capistrano/wiki) farklı yayınları `releases` adındaki bir alt dizinde depolar. Çalışıyor olan yayın ise bu alt dizinlerden birine oluşturulmuş bir kısayol dosyasıdır. Capistrano'nun `rollback` komutu, kısayol dosyasının işaret ettiği dizini değiştirerek önceki bir yayına dönüş yapmayı kolaylaştırır.
+
+Her yayın zaman damgası gibi (`2011-04-06-20:32:17` gibi) özel bir ID'ye veya her yeni yayında artan bir numaraya (`v100` gibi) sahip olmalıdır. Yayınlar yalnızca eklemeli bir defterdir ve bir kere oluşturulduğu zaman değiştirilemez. Herhangi bir değişiklik yeni bir yayın oluşturmalıdır.
+
+Derlemeler, geliştiricilerin kod değişikliklerini kod depolarına yüklemesiyle başlatılır. Çalıştırma evresi ise, sunucuların yeniden başlatılması veya çökmüş süreçlerin tekrar ayağa kaldırılması gibi durumlarda otomatik olarak gerçekleştirilir. Bu yüzden çalıştırma evresi olabildiği kadar az sayıda hareketli parçaya sahip olmalıdır ki, gecenin bir yarısında, işinin başında olan hiçbir geliştirici yokken bozulmasın. Derleme evresi ise daha karmaşık olabilir, çünkü hatalar dağıtımı çalıştıran geliştiricilerin her zaman önündedir.
diff --git a/content/tr/codebase.md b/content/tr/codebase.md
new file mode 100644
index 000000000..06187f0e2
--- /dev/null
+++ b/content/tr/codebase.md
@@ -0,0 +1,17 @@
+## I. Kod Tabanı
+### Sürüm kontrol sistemi üzerinde tek bir kod tabanı, birden fazla dağıtım
+
+On iki faktör bir uygulama her zaman [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/) veya [Subversion](http://subversion.apache.org/) gibi bir sürüm kontrol sistemiyle izlenir. Bu sürüm kontrol sistemindeki dosya veritabanına kod deposu (İng. code repository) veya kısaca depo (İng. repo) denir.
+
+Bir *kod tabanı*, tek bir depo (Subversion gibi merkezi sürüm kontrol sistemi) ya da kök *commit* paylaşan birden fazla depodan (Git gibi merkezi olmayan sürüm kontrol sistemi) oluşur.
+
+
+
+Kod tabanı ve uygulama arasında her zaman birebir ilişki vardır:
+
+* Eğer birden fazla kod tabanı varsa bu bir uygulama değil, dağıtık sistemdir. Dağıtık sistemdeki her bileşen bir uygulamadır ve her biri on iki faktörle bireysel olarak uyumlu olmalıdır.
+* Aynı kodu paylaşan birden fazla uygulama, on iki faktörü ihlal eder. Burada çözüm, paylaşılan kodun [bağımlılık yöneticisi](./dependencies) aracılığıyla dahil edilebilecek kütüphanelere dönüştürülmesidir.
+
+Uygulamanın sadece bir kod tabanı vardır fakat birden fazla dağıtımı olacaktır. Bir *dağıtım*, uygulamanın çalışan bir örneğidir. Bu dağıtımlar genelde bir canlı yayın (İng. production) ve bir veya birkaç test ortamıdır. Ayrıca her geliştiricinin kendi yerel geliştirme ortamında çalışan bir kopyası vardır ve bunların her biri aynı zamanda dağıtım olarak nitelendirilirler.
+
+Dağıtımlarda anlık olarak farklı sürümler etkin olabilir fakat kod tabanı tüm dağıtımlarda aynıdır. Örneğin, bir geliştirici henüz commit'lemediği değişiklikleri çalıştırıyor olabilir, veya test ortamında henüz canlı yayına dağıtılmamış bir sürüm çalışıyor olabilir. Bu nedenle hepsi ayrı dağıtım olarak tanımlanır ama kod tabanı aynıdır.
diff --git a/content/tr/concurrency.md b/content/tr/concurrency.md
new file mode 100644
index 000000000..9ef8f593f
--- /dev/null
+++ b/content/tr/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. Eş Zamanlılık
+### Süreç modeli yardımıyla dağıtıklaştırma
+
+Herhangi bir bilgisayar programı bir kere çalıştığı zaman bir veya daha fazla süreç tarafından temsil edilir. Web uygulamaları çeşitli süreç çalıştırma formlarına sahiptir. Örneğin, PHP süreçleri Apache'nin alt süreci olarak çalışır, ve istek hacmine göre ihtiyaç duyuldukça başlatılır. Java süreçleri karşıt yaklaşımı benimser; JVM, başlangıçta büyük miktarda sistem kaynağı (CPU ve bellek) ayıran büyük bir süreci başlatır, ve eşzamanlı iş parçacıkları (İng. threads) aracılığıyla JVM içerisinde dahili olarak yönetilir. Her iki durumda, çalışan süreçler, uygulamanın geliştiricilerine minimum düzeyde görünürdür.
+
+
+
+**On iki faktör uygulamasında, süreçler birinci sınıf üyelerdir.** On iki faktör uygulamasındaki süreçler arkaplan servis programları çalıştırmak için olan [Unix süreç modeli](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/)nden güçlü ipuçları alır. Bu modeli kullanarak geliştirici, uygulamasının her iş tipini bir *süreç tipine* atayarak, farklı iş yüklerini kontrol etmek için uygulamasını planlayabilir. Örneğin, HTTP istekleri web süreçleri tarafından işlenir ve uzun çalışan arkaplan görevleri, işçi süreçler tarafından işlenir.
+
+Bu, çalışma zamanı (İng. runtime) içindeki iş parçacıkları veya [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) ve [Node.js](http://nodejs.org/) gibi araçlarda bulunan asenkron/olay-bazlı model gibi, süreçlerin kendi çok-kanallılığını hariç tutmaz. Fakat bir sanal makinanın dikey ölçekte büyümesinin bir sınırı vardır. Bu yüzden uygulama aynı zamanda birden fazla fiziksel makinede çalışan çoklu süreçleri içerebilmelidir.
+
+Bu süreç modeli, konu ölçeklendirmeye geldiğinde gerçekten farkını ortaya koyar. Paylaşımsız, yatay olarak bölümlenebilir bir doğası olan on iki faktör uygulama süreçleri, daha fazla eş zamanlılık eklemenin kolay ve güvenilir bir iş olduğu anlamına gelir. Süreç tipleri dizisi ve her bir tipin süreç sayısı *süreç formasyonu* olarak bilinir.
+
+On iki faktör uygulama süreçleri [asla arkaplan süreçleri başlatmamalı](http://dustin.github.com/2010/02/28/running-processes.html) ya da PID dosyaları yazmamalıdır. Bunun yerine, [çıktı akışlarını](./logs) kontrol etmek, çökmüş süreçlere cevap vermek, kullanıcı sebepli tekrar başlatma ve kapatmaları süreçek için işletim sistemlerinin süreç yöneticisine ([systemd](https://www.freedesktop.org/wiki/Software/systemd/) gibi bulut platformunda yayınlanmış süreç yöneticisi veya geliştirme sırasında [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html)'e benzer araçlar) dayanır.
diff --git a/content/tr/config.md b/content/tr/config.md
new file mode 100644
index 000000000..4fa9b30d3
--- /dev/null
+++ b/content/tr/config.md
@@ -0,0 +1,22 @@
+## III. Yapılandırma
+### Yapılandırma ayarlarını ortam değişkeni saklama
+
+Bir uygulamanın *yapılandırma ayarları* [dağıtımlar](./codebase) arasında farklı olma ihtimali olan her şeydir. Örneğin:
+
+* Veritabanlarının, önbellekleme servislerinin ve diğer [yardımcı servislerin](./backing-services) erişim bilgileri
+* Amazon S3 ve Twitter gibi dış servisler için kimlik bilgileri
+* Dağıtımlar için standart sunucu ismi gibi dağıtım-öncesi değerler
+
+Uygulamalar bazen yapılandırma ayarlarını kod içerisinde saklar. Bu on iki faktörün, **yapılandırmayı koddan mutlak ayrımını** gerektiren kuralın ihlalidir. Yapılandırma ayarları dağıtımlar arasında değişir, ama kod değişmez.
+
+Bir uygulamanın herhangi bir kimlik bilgisinin gizliliğini ihlal etmeden açık kaynak yapılabilip yapılamayacak olması, tüm yapılandırmaları koddan doğru bir biçimde çıkarılıp çıkarılmadığını belirleyebilecek bir litmus testidir.
+
+Bu *yapılandırma ayarı* tanımının, [Spring](http://spring.io/)'de [kod modüllerinin bağlantısında](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) olduğu gibi ve Rails'deki `config/routes.rb` gibi dahili uygulama yapılandırmasını **içermediğini** unutmayın. Bu tip yapılandırmalar, dağıtımlar arasında değişiklik göstermeyeceği için, kod içinde gerçekleştirilmeleri mantıklıdır.
+
+Yapılandırmaya diğer bir yaklaşım da Rails'deki `config/database.yml` gibi dosyaların versiyon kontrol sistemine dahil edilmeden kullanımıdır. Bu, kod deposuna dahil edilmiş sabitler kullanmaya göre büyük bir gelişimdir, fakat hala zayıflıkları vardır: Bu dosyaların yanlışlıkla versiyon kontrol sistemine dahil edilme olasılığı oldukça yüksektir. Yapılandırma dosyalarının farklı yerlerde ve farklı formatlarda dağılmış olması eğilimi mevcuttur, ve bu durum bütün yapılandırmayı bir yerde görmeyi ve yönetmeyi zorlaştırır. Dahası, bu formatlar genelde dil veya çatı için özelleşmiştir.
+
+**On iki faktör uygulamalarında yapılandırma *ortam değişkenlerinde* kaydedilir** (sıklıkla *env vars* veya *env* olarak kısaltılır). Ortam değişkenleri herhangi bir kod değişikliği olmadan, dağıtımlar arasında kolay değişebilir; Yapılandırma dosyalarının aksine, kod deposuna yanlışlıkla dahil edilme ihtimali düşüktür; ve özel yapılandırma dosyalarının veya Java sistem özellikleri gibi yapılandırma mekanizmalarının aksine, onlar dil ve işletim sisteminden etkilenmez.
+
+Yapılandırma yönetiminin diğer bir açısı da gruplandırmadır. Bazen uygulamalar, Rails'deki `geliştirme`, `test` ve `canlı` ortamları gibi belirli dağıtımlardan sonra adlandırılmış gruplar içinde yapılandırılır. Bu yöntem temiz bir şekilde ölçeklenemez. Çünkü uygulamanın daha fazla dağıtımı oluştukça, yeni ortam isimleri gerekli olur, `staging` veya `qa` gibi. Projeler ilerde geliştikçe, geliştiriciler `joes-staging` kendi özel ortam değişkenlerini ekleyebilir. Bu da yapılandırma dosyalarının hızla artmasıyla sonuçlanarak dağıtım yönetimini oldukça kırılganlaştırır.
+
+On iki faktör uygulamasında ortam değişkenleri parçacıklı kontrol edilirler, birbirlerinden bağımsızlardır. Asla gruplandırılmazlar, onun yerine her bir dağıtım için bağımsız olarak yönetilirler. Bu, uygulamayı yaşam süresi boyunca daha fazla dağıtıma genişletmeyi sorunsuzca ölçeklendiren bir modeldir.
diff --git a/content/tr/dependencies.md b/content/tr/dependencies.md
new file mode 100644
index 000000000..017302353
--- /dev/null
+++ b/content/tr/dependencies.md
@@ -0,0 +1,12 @@
+## II. Bağımlıklar
+### Bağımlılıkların açıkça tanımlanması ve izole edilmesi
+
+Çoğu programlama dili destek kütüphanelerini dağıtmak için bir paketleme sistemi sunar. Mesela Perl için [CPAN](http://www.cpan.org/), Ruby için [Rubygems](http://rubygems.org/). Bir paketleme sistemi aracılığıyla yüklenen kütüphaneler, sistem genelinde ("site paketleri" olarak bilinir) yüklenebilir veya uygulamanın bulunduğu dizine ("sağlayıcı" veya "paketleme" olarak bilinir) dahil edilebilir.
+
+**On iki faktör bir uygulama asla bir sistem geneli paketin yüklü olduğunu varsaymaz.** Bir *bağımlılık bildirimi* manifestosu ile tüm bağımlılıkları tam ve eksiksiz olarak bildirir. Üstelik bağımlılıkların çevredeki sistemden sızmamasını sağlamak için çalıştırma sırasında bir *bağımlılık yalıtım* aracı kullanılır. Tam ve açık bağımlılık belirtimi hem canlı yayın hem de geliştirme için eşit olarak uygulanmaktadır.
+
+Örneğin, Ruby'nin [Bundler](https://bundler.io/)'ı, bağımlılık bildirimi için `Gemfile` manifesto formatını ve bağımlılık yalıtımı için `bundle exec`'i sunar. Python'da bu adımlar için iki ayrı araç bulunur: [Pip](http://www.pip-installer.org/en/latest/) bildirimde, [Virtualenv](http://www.virtualenv.org/en/latest/) de yalıtımda kullanılır. C bile bağımlılık bildirimi için [Autoconf](http://www.gnu.org/s/autoconf/)'a sahiptir ve bağımlılık yalıtımı statik link ile sağlanır. Ne olursa olsun birbiriyle uyumlu çalışan yazılım uygulaması, bağımlılık bildirimi ve bağımlılık yalıtımı birlikte kullanılmalıdır, sadece birinin olması on iki faktör için yeterli değildir.
+
+Açık bağımlılık bildiriminin bir faydası da uygulamaya yeni katılan geliştiriciler için kurulumu kolaylaştırmasıdır. Yeni geliştirici bilgisayarında yalnızca programlama dilini ve bağımlılık yöneticisine sahip olarak uygulamanın kod tabanını indirebilir. Uygulamanın içindeki önceden belirlenmiş bir *derleme komutu* uygulama kodunun çalışması için ihtiyaç duyulan her şeyi yükleyebilecektir. Örneğin bu komut Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) için `lein deps` iken, Ruby/Bundler için `bundle install`'dur.
+
+On iki faktör uygulamaları herhangi bir sistem aracının yüklü olduğunu varsaymaz. Örnekler `ImageMagick` yada `curl` kullanımını içerir. Bu araçlar çoğu sistemde var olabilse de, uygulamanın gelecekte çalışabileceği sistemlerde bu araçların var olup olmayacağının veya bu araçların sürümlerinin uygulamayla uyumlu olup olmayacağının garantisi yoktur. Uygulamanın bir sistem aracına ihtiyacı oluşuyorsa, o aracın uygulamanın içine dahil edilmesi gerekir.
diff --git a/content/tr/dev-prod-parity.md b/content/tr/dev-prod-parity.md
new file mode 100644
index 000000000..38678a3d6
--- /dev/null
+++ b/content/tr/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X.Geliştirme/Üretim Eşitliği
+### Geliştirme, test etme ve canlı yayın ortamının birbirine olabildiğince benzer olması
+
+Tarihsel olarak, geliştirme ortamı (geliştiricinin uygulamanın yerel [dağıtımına](./codebase) anlık düzenlemeler yaptığı) ve canlı yayın (uygulamanın son kullanıcılar tarafından erişilen çalışan dağıtımı) arasında önemli aralıklar olurdu. Bu aralıklar üç alanda belirtilir:
+
+* **Zaman aralığı:** bir geliştirici kod üzerinde günler, haftalar hatta aylar boyunca bile çalışabilir.
+* **Çalışan aralığı:** Geliştiriciler kod yazar, operasyon mühendisleri dağıtımını sağlar.
+* **Araçların aralığı:** Geliştiriciler Apache, MySQL ve Linux kullanırken; canlı yayında Nginx, SQLite, ve OS X gibi teknolojiler kullanıyor olabilir.
+
+**On iki faktör uygulaması, geliştirme ve canlı yayın aralığını küçük tutarak, [sürekli dağıtım](http://avc.com/2011/02/continuous-deployment/) için tasarlanmıştır.** Yukarda tanımlanan üç aralığa bakarsak:
+
+* Zaman aralığını küçültme: bir geliştirici kod yazabilir ve bu kodu saatler veya hatta dakikalar sonra dağıtmış olabilir.
+* Eleman aralığını küçültme: kodu yazan geliştiriciler, kodu dağıtmakla ve canlı yayındaki davranışını izlemekle yakından ilişkilidir.
+* Araçların aralığını küçültme: geliştirmeyi ve canlı yayını olabildiği kadar benzer tut.
+
+Üstekileri bir tablo olarak özetlersek:
+
+| + | Geleneksel uygulama | +On iki faktör uygulaması | +
|---|---|---|
| Dağıtımlar arasındaki zaman | +Haftalar | +Saatler | +
| Kod yazarları ve kod dağıtımcıları | +Farklı insanlar | +Aynı insanlar | +
| Geliştirme ve canlı yayın ortamı | +Farklı | +Olabildiğince benzer | +
| Tip | +Dil | +Kütüphane | +Uyarlayıcı | +
|---|---|---|---|
| Veritabanı | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Kuyruk | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Önbellek | +Ruby/Rails | +ActiveSupport::Cache | +Bellek, dosya sistemi, Memcached | +
+
+Ресурси за необхідності можуть бути підключені та відключені до розгортання застосунку. Наприклад, якщо база даних застосунку функціонує некорекно у зв'язку з апаратними проблемами, адміністратор може запустити новий сервер бази даних, відновленої з останньої резервної копії. Поточна база даних може бути відключена, а нова база даних підключена — все це без будь-яких змін коду.
diff --git a/content/uk/build-release-run.md b/content/uk/build-release-run.md
new file mode 100644
index 000000000..eaaed6b44
--- /dev/null
+++ b/content/uk/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` дає можливість швидко виконати відкат до попередньої версії.
+
+Кожен реліз повинен завжди мати унікальний ідентифікатор, наприклад, мітку часу релізу (наприклад, `2011-04-06-20:32:17`) або номер, що зростає (наприклад, `v100`). Релізи можуть тільки додаватися, неможливо змінити реліз після його створення. Будь-які зміни мають створювати новий реліз.
+
+Збірка ініцюється розробником застосунку щоразу при розгортанні нового коду. Запуск етапу виконання, навпаки, може відбуватися автоматично в таких випадках, як перезавантаження сервера або перезапуск процесу, шо впав, менеджером процесів. Таким чином, етап виконання має бути максимально технічно простим, бо проблеми, які заважають застосунку запуститися, можуть призвести до його зупинки посеред ночі, коли розробників немає на місці. Етап збірки може бути більш складним, бо можливі помилки завжди видимі розробнику, який запустив процес розгортання.
\ No newline at end of file
diff --git a/content/uk/codebase.md b/content/uk/codebase.md
new file mode 100644
index 000000000..75e86bf68
--- /dev/null
+++ b/content/uk/codebase.md
@@ -0,0 +1,17 @@
+## I. Кодова база
+### Одна кодова база, що відслідковується в системі контролю версій та має багато розгортань
+
+Застосунок дванадцяти факторів завжди відслідковуються в системі контролю версій, такій як [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) або [Subversion](http://subversion.apache.org/). Копія бази даних відстеження ревізій називається *репозиторій коду (code repository)*, що часто скорочується до *code repo* або просто *repo*.
+
+*Кодова база* — це один репозиторій (в централізованих системах контролю версій, як Subversion), або декілька репозиторіїв, які мають спільний початковий комміт (в децентралізованих системах контролю версій, як Git).
+
+
+
+Завжди існує однозначна відповідність між кодовою базою і застосунком:
+
+* За наявності кількох баз коду, це не застосунок, це — розподілена система. Кожен компонент в розподіленій системі є застосунком, і кожен з них може окремо дотримуватися дванадцяти факторів.
+* Кілька різних застосунків, що спільно використовують загальну базу коду, є порушенням дванадцяти факторів. Рішенням в даній ситуації є виділення загального коду в бібліотеки, які можуть бути підключені через [менеджер залежностей](./dependencies).
+
+Існує тільки одна кодова база для кожного застосунку, але може бути багато розгортань одного і того самого застосунку. *Розгортанням (deploy)* є запущений екземпляр застосунку. Це, як правило, production-сайт і один або більше staging-сайтів (проміжних розгортань). Крім того, розробник має копію застосунку, запущеного в його локальному середовищі розробки. Кожну з таких копій також можна кваліфікувати як розгортання (deploy).
+
+Кодова база має бути єдина для всіх розгортань, хоча в кожному розгортанні можуть бути активні різні її версії. Наприклад, розробник може мати деякі зміни у коді, які ще не додані в staging-розгортання; staging-розгортання може мати деякі зміни, які ще не додані в production-розгортання. Але всі вони використовують одну і ту саму кодову базу, таким чином можна їх ідентифікувати як різні розгортання одного і того ж застосунку.
\ No newline at end of file
diff --git a/content/uk/concurrency.md b/content/uk/concurrency.md
new file mode 100644
index 000000000..de609a2c8
--- /dev/null
+++ b/content/uk/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-запити можуть бути оброблені за допомогою веб-процесу (web process), а тривалі фонові завдання оброблені робочим процесом (worker process).
+
+Це не виключає можливості використання індивідуального мультиплексування для окремих процесів через потоки виконання віртуальної машини або асинхронні/подієві моделі в таких інструментах, як [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) або [Node.js](http://nodejs.org/). Але індивідуальна віртуальна машина може масшабуватися тільки обмежено (вертикальне масшабування), тому застосунок також повинен мати можливість бути запущеним як декілька процесів на декількох фізичних машинах.
+
+Модель, побудована на процесах, дійсно показує себе з найкращого боку, коли постає необхідність масштабування. [Відсутність розділених даних і горизонтальне розділення процесів застосунку дванадцяти факторів](./processes) означає, що додавання більшої конкурентності є простою і надійною операцією. Масив типів процесів і кількість процесів кожного типу називається *формацією процесів*.
+
+Процеси застосунку дванадцяти факторів [ніколи не мають демонізуватися](http://dustin.github.com/2010/02/28/running-processes.html) та записувати PID-файли. Замість цього вони мають покладатися на менеджер процесів операційної системи (наприклад, [systemd](https://www.freedesktop.org/wiki/Software/systemd/), розподілений менеджер процесів на хмарній платформі, або в процесі розробки на такий інструмент, як [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html)) для керування [потоком виведення](./logs), реагування на падіння процесів і обробку ініційованих користувачем перезавантаження чи завершення роботи.
diff --git a/content/uk/config.md b/content/uk/config.md
new file mode 100644
index 000000000..8205ba784
--- /dev/null
+++ b/content/uk/config.md
@@ -0,0 +1,22 @@
+## III. Конфігурація
+### Зберігайте конфігурацію в середовищі виконання
+
+*Конфігурація* застосунку — це все, що може змінюватися між [розгортаннями](./codebase) (staging-розгортання, production-розгортання, локальне середовище розробника тощо). Це включає:
+
+* Параметри підключення до бази даних, Memcached і інших [сторонніх сервісів](./backing-services);
+* Реєстраційні дані для підключення до зовнішніх сервісів, таких як Amazon S3 або Twitter;
+* Значення, що залежать від середовища розгортання, такі як канонічне ім'я хосту.
+
+Застосунки іноді зберігають конфігурації як константи в коді. Це є порушенням методології дванадцяти факторів, яка вимагає **обов'язкового відокремлення конфігурації від коду**. Конфігурації застосунку в розгортаннях суттєво відрізняються, код — однаковий.
+
+Лакмусовим папірцем того, чи правильно розділені конфігурація і код, є можливість в будь-який момент відкрити вихідний код застосунку у вільний доступ, при цьому не оприлюднюючи будь-яких приватних даних.
+
+Зверніть увагу, що визначення "конфігурації" **не включає** в себе внутрішні налаштування застосунку, такі як `сonfig/routes.rb` в Rails, або [як пов'язані основні модулі](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) в [Spring](http://spring.io/). Ці налаштування не змінюються між розгортаннями, і тому краще місце для них — саме в коді.
+
+Іншим підходом до конфігурації є використання конфігураційних файлів, що не зберігаються в систему контролю версій, таких як `сonfig/database.yml` в Rails. Це перевага у порівнянні з використанням констант в коді, але все ж таки має суттєві недоліки: є ймовірність помилково зберегти файл конфігурації в репозиторій; існує тенденція коли конфігураційні файли розкидані в різних місцях і в різних форматах, і стає важко передивлятися всі налаштування і керувати ними в одному місці. Крім того, формати цих файлів, як правило, специфічні для конкретної мови програмування чи фреймворку.
+
+**Застосунок дванадцати факторів зберігає конфігурацію в *змінних оточення*** (часто скорочується до *env vars* або *env*). Значення змінних оточення легко змінити між розгортаннями без зміни коду; на відміну від конфігураційних файлів, менш ймовірно випадково зберегти їх в репозиторій коду; і на відміну від конфігураційних файлів або інших механізмів конфігурації, таких як Java System Properties, вони є стандартом, незалежним від мови програмування чи фреймворку.
+
+Іншим аспектом керування конфігурацією є групування. Іноді застосунки об'єднують конфігурації в іменовані групи (які часто називаються "оточеннями"), які називаються в залежності від конкретного розгортання, наприклад, `development`, `test` і `production` оточення в Rails. Цей метод погано масштабується: чим більше створюється різних розгортань застосунку, тим більше необхідно нових імен оточень, наприклад, `staging` або `qa`. При подальшому рості проекту розробники можуть додавати свої власні спеціальні оточення, наприклад, `joes-staging`, що призводить до комбінаторного вибуху конфігурації, який робить керування розгортанням застосунку нестабільним.
+
+У застосунку дванадцяти факторів змінні оточення є незв'язаними між собою засобами керування. Кожна змінна повністю незалежна від інших. Вони ніколи не групуються разом в "оточення", керування ними здійснюється незалежно для кожного розгортання. Ця модель добре масштабується разом з появою більшої кількості розгортань застосунку протягом його експлуатації.
\ No newline at end of file
diff --git a/content/uk/dependencies.md b/content/uk/dependencies.md
new file mode 100644
index 000000000..64dde9f30
--- /dev/null
+++ b/content/uk/dependencies.md
@@ -0,0 +1,12 @@
+## II. Залежності
+### Явно оголошуйте та ізолюйте залежності
+
+Більшість мов програмування мають системи пакунків для розповсюдження бібліотек, такі як [CPAN](http://www.cpan.org/) для Perl або [Rubygems](http://rubygems.org/) для Ruby. Бібліотеки, встановлені через систему пакунків, можуть бути доступними для всієї системи (так звані "site-packages") або встановлені в каталог застосунку (так звані "vendoring" або "bundling").
+
+**Застосунок дванадцяти факторів ніколи не залежить від неявно існуючих, досупних всій системі пакунків.** Застосунок повно і точно вказує всі свої залежності за допомогою маніфесту *оголошення залежностей*. Крім того, він використовує інструмент *ізоляції залежністей* під час виконання, щоб гарантувати, що ніякі неявні залежності не "просочилися" з зовнішньої системи. Повна і явна специфікація залежностей використовується однаково як при розробці, так і в production.
+
+Наприклад, [Bundler](https://bundler.io/) в 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`. У той час, як ці інструменти можуть бути встановлені на багатьох або навіть більшості систем, немає жодної гарантії, що вони будуть встановлені на всіх системах, де застосунок може запускатися в майбутньому, або версія інструменту, встановлена в системі, буде сумісна з застосунком. Якщо застосунку потрібно запускати певні системні інструменти, то такі інструменти мають бути включені в сам застосунок.
\ No newline at end of file
diff --git a/content/uk/dev-prod-parity.md b/content/uk/dev-prod-parity.md
new file mode 100644
index 000000000..d31c57991
--- /dev/null
+++ b/content/uk/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Dev/prod паритет
+### Прагніть максимальної ідентичності development, staging та production середовищ
+
+Історично склалося, що є суттєві відмінності між development середовищем (розробник вносить живі зміни в [локально розгорнутий](./codebase) застосунок) і production середовищем (до якого мають доступ кінцеві користувачі). Ці відмінності проявляються в трьох областях:
+
+* **Різниця в часі**: Розробник може працювати над кодом, який потрапить у production через дні, тижні або навіть місяці;
+* **Різниця в персоналі**: Розробники пишуть код, Ops-інженери розгортають його;
+* **Різниця в інструментах**: Розробники можуть використовувати стек технологій такий, як Nginx, SQLite та OS X, в той час як на production використовується Apache, MySQL та Linux.
+
+**Застосунок дванадцяти факторів проектується для [безперервного розгортання](http://avc.com/2011/02/continuous-deployment/), завдяки мінімізації різниці між production і development середовищами.** Розглянемо три відмінності, описані вище:
+
+* Зменшити різницю в часі: розробник може написати код і він буде розгорнутий через декілька годин або навіть хвилин;
+* Зменшити різницю в персоналі: розробники, які писали код, беруть активну участь в його розгортанні і спостерігають за його поведінкою на production;
+* Зменшити різницю в інструментах: тримати development та production середовища максимально ідентичними.
+
+Резюмуючи сказане вище в таблицю:
+
+| + | Традиційний застосунок | +Застосунок дванадцати факторів | +
|---|---|---|
| Час між розгортаннями | +Тижні | +Години | +
| Автор коду/той хто розгортає | +Різні люди | +Ті ж люди | +
| Dev/Prod розгортання | +Різні | +Максимально ідентичні | +
| Тип | +Мова | +Бібліотека | +Адаптери | +
|---|---|---|---|
| База даних | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Черга повідомлень | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Кеш | +Ruby/Rails | +ActiveSupport::Cache | +Пам'ять, файлова система, Memcached | +
+
+Tài nguyển có thể được thêm vào triển khai khi cần thiết. Ví dụ, nếu cơ sở dữ liệu của ứng dụng bị mất do lỗi phần cứng, quản trị viên của ứng dụng có thể thêm vào một máy chủ cơ sở dữ liệu được khôi phục từ các sao lưu trước đó. Các thay đổi bao gồm cơ sở dữ liệu chính đang sử dụng có thể được loại bỏ, và bổ xung cơ sở dữ liệu mới có thể xảy ra mà không cần thay đổi bất kỳ một đoạn mã nguồn nào.
diff --git a/content/vi/build-release-run.md b/content/vi/build-release-run.md
new file mode 100644
index 000000000..d3ccc9cf5
--- /dev/null
+++ b/content/vi/build-release-run.md
@@ -0,0 +1,18 @@
+## V. Xây dựng, phát hành, vận hành
+### Tách biệt hoàn toàn giữa bước xây dựng và vận hành
+
+[Mã gốc](./codebase) được chuyển sang (tạm dừng phát triển) triển khai thông qua ba bước:
+
+* Bước xây dựng* là bước chuyển các đoạn mã thành các gói có khả năng thực thi được gọi là một *bản xảy dựng*. Sử dụng phiên bản của mã nguồn ở một bản cam kết (commit) quy định bở quy trình triển khai, bước xây dựng lấy về và cung cấp các [phụ thuộc](./dependencies) và biên dịch các thành phần và tài nguyên.
+* Bước phát hành* sử dụng các kết quả của bước xây dựng và kết hợp với các [cấu hình](./config) triển khai hiện tại. Kết quả của *phát hành* bao gồm cả bản xây dựng và các câu hình cho phép ứng dụng có thể được vận hành trong môi trường vận hành.
+* Bước vận hành* (được biết như là "thời gian vận hành" (runtime)) vận hành ứng dụng trong môi trường thực thi, bằng việc thực thi một tập các [tiến trình](./process) của của ứng dụng với một phiên bản phát hành cụ thể.
+
+
+
+**Ứng dụng sử dụng mười hai-hệ số tách biệt hoàn toàn giữa các bước xây dựng, phát hành và vận hành.** Ví dụ, chúng ta không thể tạo ra các thay đổi của mã nguồn khi đang vận hành, do đó không có khả năng quay ngược lại bước xây dựng.
+
+Công cụ triển khai thường cung cấp công cụ quản lý phát hành, cùng với các ký pháp cho phép quay ngược lại bản phat hành trước đó. Ví dụ, công cụ triển khai [Capistrano](https://github.com/capistrano/capistrano/wiki) lưu trữ các phát hành trong thư mục con tên là `releases`, nơi mà phiên bản hiện tại được liên kết giả đến thư mục phát hành hiện tại. Lệnh `rollback` làm cho việc quay trở lại phiên bản trước trở nên dễ dàng.
+
+Mỗi phát hành đều có một định danh duy nhất ID, như là dựa vào thời gian phát hành (như `2011-04-06-20:32:17`) hoặc một số tự tăng (như `v100`). Các phiên bản được tạo ra thành một chuỗi liên tục và một phiên bản không thể thay đổi sau khi nó được tạo ra. Bất cứ thay đổi nào đểu tạo ra một bản phát hành mới.
+
+Các bước xây dựng được khởi tạo với nhà phát triển ứng dụng khi mà mã nguồn được triển khai. Thời gian thực thi, ngược lại, có thể tự động xảy ra trong trường hợp các máy chủ được khởi động lại, hoặc tiến trình tạm dừng được khởi động lại bởi bộ quản lý các tiến trình. Do đó, bước vận hành nên được giữ các thành phần thay đổi càng ít càng tốt, vì các sự cố xảy ra làm ứng dụng không vận hành được có thể gây ra các thiệt hại lúc nửa đêm khi mà không có bất kỳ lập trình viên nào có thể khắc phục sự cố. Bước xây dựng có thể phức tạp hơn, vì các lỗi có thể xuất hiện trước mắt cho lập trình viên, người đang thực hiện triển khai biết được.
diff --git a/content/vi/codebase.md b/content/vi/codebase.md
new file mode 100644
index 000000000..9be6bc17d
--- /dev/null
+++ b/content/vi/codebase.md
@@ -0,0 +1,24 @@
+## I. Mã gốc (codebase)
+### Một mã gốc (codebase) được theo dõi với hệ thống quản lý phiên bản, và nhiều lần triển khai (deploy)
+
+Một ứng dụng 12-hệ số luôn luôn được theo dõi bới hê thống quản lý phiên bản, như là [Git](http://git-scm.com/), [Mercurial](http://mercurial.selenic.com/), hay [Subversion](http://subversion.apache.org/). Một bản lưu của cơ sở dữ liệu các phiên bản được gọi là **kho mã (code repository)**, và hay được viết vắn tắt thành *code repo* hay *repo*.
+
+Một *mã gốc* là bất kì một repo riêng lẻ (trong một hệ thống quản lý phiên bản thống nhất như Subversion), hoặc bất kì một nhóm các repo chia sẻ cùng một commit nguồn (root commit) (trong một hệ thống quản lý phiên bản kiểu phân quyển như Git).
+
+
+
+Sẽ luôn luôn là sự tương quan một-với-một giữa mã gốc và ứng dụng:
+
+* Nếu có nhiều mã gốc, đấy không phải là một ứng dụng -- mà là một hệ thống phân tán. Với các
+phần tử trong một hệ thống phân tán là một ứng dụng, với mỗi cá thể tuân theo luật 12-hệ số.
+* Nhiều ứng dụng chia sẻ cùng một mã là vi phạm luật của 12-hệ số. Giải pháp ở đây là xem xét
+để nhóm các mã chia sẻ thành các thư viện mà có thể được nhúng vào thông qua [trình quản lý các gói phụ thuộc (dependency manager)](./dependencies).
+
+Chỉ có một mã gốc từng ứng dụng, nhưng sẽ có nhiều triển khai của một ứng dụng. Một *triển khai* là một đối tượng thực thi của ứng dụng đó. Đây là trường hợp rất phổ biến của các trang
+đã đi vào hoạt động, và của một vài trang thử nghiệm. Thêm vào đó mỗi lập trình viên sẽ có một
+bản lưu của ứng dụng đang chạy trên môi trường phát triển cá nhân, mỗi bản đều được coi như là
+một triển khai.
+
+Mã gốc sẽ giống nhau trên các triển khai, tuy là phiên bản khác nhau có thể hoạt dộng trong mỗi triển khai. Lấy một ví dụ, một lập trình viên có nhiều commit nhưng chưa triển khai vào
+hệ thống thử (staging); hệ thống thử có nhiều commit mà chưa được triển khai trên hệ thống sản xuất (production). Nhưng cả hai đều chia sẻ cùng một mã gốc; thế nên phải định dạng chúng
+như những cá thể triển khai của cùng một ứng dụng.
diff --git a/content/vi/concurrency.md b/content/vi/concurrency.md
new file mode 100644
index 000000000..8b3518328
--- /dev/null
+++ b/content/vi/concurrency.md
@@ -0,0 +1,15 @@
+## VIII. Đồng bộ hoá
+### Mở rộng theo chiều ngang thông qua mô hình tiến trình
+
+Bất kỳ chương trình máy tính nào, khi vận hành, đều được đại diện bởi một hoặc nhiều tiến trình. Ứng dụng web có thể sử dụng bất kỳ dạng nào của tiến trình vận hành. Ví dụ, tiến trình PHP vận hành như là tiến trình con của Apache, chạy như một tiến trình nền dựa vào số lượng yêu cầu được gửi đến. Ứng dụng Java, tiếp cận theo cách ngược lại, với JVM cung cấp một tiến trình nền tảng lớn (a massive uberprocess) với lượng lớn các tài nguyên (CPU và bộ nhớ) được cấp phát ngay từ đầu, việc đồng bộ hoá được quản lý bên trong thông qua các luồng. Trong cả hai trường hợp, các tiến trình vận hành chỉ hiện hữu rất ít đối với các nhà phát triển của ứng dụng.
+developers of the app.
+
+
+
+**Trong ứng dụng áp dụng mười hai hệ số, các tiến trình là thành phần nền tảng đầu tiên.** Các tiến trình trong ứng dụng áp dụng mười hai hệ số sử dụng các tín hiệu rõ rệt từ [các mô hình tiến trình của unix cho các dịch vụ chạy nền](http://adam.heroku.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Sử dụng mô hinh này, các lập trình viên có thể thiết kế ứng dụng của họ để điều khiển các công việc khác nhau bằng cách gán mỗi loại tương ứng với một *kiểu tiến trình*. Ví dụ, yêu cầu HTTP có thể điều khiển bởi tiến trình web, và các ứng dụng chạy gầm tốn nhiều thời gian có thể được quản lý bởi các tiến trình làm việc.
+
+Điều này không loại bỏ các tiến trình các nhân khỏi việc quản lý chính các kênh nội bộ của tiến trình đó, thông qua các luồng bên trong máy áo đang thực thi, hoặc mô hình bất đồng bộ/xự kiện trong các công cụ như là [EventMachine](http://rubyeventmachine.com/), [Twisted](http://twistedmatrix.com/trac/), hoặc [Node.js](http://nodejs.org/). Nhưng một máy ảo (VM) riêng biệt chỉ có thể mở rộng (mở rộng theo chiều dọc), do đó ứng dụng cần có thể mở rộng thành các tiến trình chạy trên nhiều máy chủ vật lý.
+
+Mô hình tiến trình thực sự nổi trội khi mà việc mở rộng tài nguyên trở nên phổ biển. [Việc không chia sẻ, phân hoạch tự nhiên của các tiến trình của ứng dụng áp dụng mười hai hệ số](./processes) có nghĩa việc thêm các tiến trình đồng bộ hơn là đơn giản và tin cậy. Danh sách các kiểu tiến tình và số lượng tiến trình mỗi loại được biết đến như là *công thức tiến trình*.
+
+Tiến trình của ứng dụng mười hai hệ số [không bao giờ chạy như là dịch vụ nền](http://dustin.github.com/2010/02/28/running-processes.html) hoặc ghi ra tệp tin PID. Thay vào đó, tin tưởng vào hệ thống quản lý tiến trình của hệ điều hành (như là [Upstart](http://upstart.ubuntu.com/), hoặc hệ thống quản lý tiến trình phân tán trên nền tảng đám mấy, hoặc công cụ như là [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) trong quá trình phát triển) để quản lý [luồng xuất ra](./logs), phản hồi các tiến trình bị lỗi, và quản lý yêu cầu khởi động lại hoặc ngưng hoạt động của người dùng.
diff --git a/content/vi/config.md b/content/vi/config.md
new file mode 100644
index 000000000..f4273dc08
--- /dev/null
+++ b/content/vi/config.md
@@ -0,0 +1,27 @@
+## III. Cấu hình
+### Lưu trữ cấu hình trong môi trường
+
+Cấu hình của ứng dụng là những thứ có thể thay đổi qua các [triển khai](./codebase) (hệ thống thử, hệ thống sản xuất, môi trường phát triển, etc). Nó bao gồm:
+* Tài nguyên xử lý cơ sở dữ liệu, Memcached, và [dịch vụ lớp dưới](./backing-services) khác
+* Thông tin đăng nhập đến các dịch vụ như là Amazon S3 hay Twitter
+* Các giá trị ứng với từng triển khai như như là tên của máy chủ để triển khai
+
+Các ứng dụng thường lưu trữ các cấu hình như là hằng số trong mã nguồn. Điều này không phù hợp với nguyên tắc của 12-thừa số, yêu cầu **giới hạn tách biệt các cấu hình khỏi mã nguồn**. Các cấu hình thay đổi qua các triển khai, mã nguồn thì không.
+
+Một litmus test cho ứng dụng có các cấu hình được thừa số hoá chính xác là mã gốc có khả năng nguồn mở hoá bất kỳ lúc nào mà không lo sợ bị mất các thông tin đăng nhập.
+
+Chú ý rằng, định nghĩa của "cấu hình" không bao gồm các cấu hình nội tại của ứng dụng, như là `config/routes.rb` trong Rails, hoặc [các thành phần được kết nối](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) trong [Spring](http://spring.io/). Những cấu hình kiểu này thường không thay đổi giữa các triển khai, và do đó đã thực hiện tốt trong mã nguồn.
+
+Một cách tiếp cận khác với các cấu hình là việc sử dụng tệp tin cấu hình mà tệp tin đó không được quản lý phiên bản, như là `config/database.yml` trong Rails. Đây là một cải tiến lớn so với việc
+sử dụng hằng số trong mã nguồn đã được quản lý phiên bản, nhưng vẫn có điểm yếu: dễ bị thêm nhầm vào quản lý phiên bản, các tệp tin cấu hình dễ bị phân tán ở những nơi khác nhau và các định dạng khác
+nhau, làm cho nó trở nên khó đọc và quản lý tất các cấu hỉnh một cách tập trung. Ngoài ra, định dạng của các tệp tin chứa cấu hình thường do đặc tả của ngôn ngữ- hoặc framework-.
+
+**Ứng dụng áp dụng mười hai thừa số chứa các cấu hình trong *environment variables (biến môi trường)*** (thường viết tắt là *env vars* hoặc *env*). Các biến môi trường rất dễ để thay đổi giữa các triển khai
+mà không phải thay đổi mã nguồn; không giống như tệp tin cấu hình, vẫn có khả năng để bị thêm vào kho mã (code repository); và không giống như các tệp tin cấu hình tuỳ chỉnh, hoặc cơ chế quảnl lý cấu
+hình như là *Java System Properties*, các biến môi trường là *agnostic standard* theo ngôn ngữ và hệ điều hành.
+
+Một khía cạnh khác của quản lý cấu hình là nhóm các cấu hình. Đôi khi, các ứng dụng tổ chức các cấu hình theo nhóm (thường được gọi là "các môi trường") được đặt tên theo các triển khai, như là các môi trường`development`, `test`, and `production` trong Rails. Phương pháp này không mở rộng rõ ràng: nếu như có nhiều triển khải của ứng dụng được tạo ra, tên của các môi trường rất quan trọng, như là `staging` hoặc `qa`. Nếu một dự án phát triển sau này, lập trình viên có thể thêm các môi trường của riêng họ như là `joes-staging`, kết quả là một sự bùng nổ về các cấu hình, làm cho việc quản lý
+các triển khai trở nên không ổn định.
+
+Trong một ứng dụng áp dụng mười hai thừa số, các biến môi trường được quản lý chi tiết, hoàn toàn độc lập với các biến môi trường khác. Chúng không được nhóm với nhau như là các "môi trường", nhưng
+thay vào đó được quản lý độc lập theo các triển khai. Mô hình này giúp cho việc mở rộng trở nên trơn tru như là việc thêm vào các triển khai theo vòng đời của phần mềm được mở rộng một cách tự nhiên.
diff --git a/content/vi/dependencies.md b/content/vi/dependencies.md
new file mode 100644
index 000000000..0c73a06f2
--- /dev/null
+++ b/content/vi/dependencies.md
@@ -0,0 +1,23 @@
+## II. Các phụ thuộc
+### Khai báo rõ ràng và phân tách các phụ thuộc
+
+Hầu hết các ngôn ngữ lập trình đều cung cấp hệ thống gói để phân phối các gói thư viện hỗ trợ, ví dụ như [CPAN](http://www.cpan.org/) cho Perl hay [Rubygems](http://rubygems.org/) cho Ruby. Các thư viện cài đặt thông qua một hệ thống gói có thể được cài đặt ở mức phủ hệ thống (được biết đến với thuật ngữ "site packages") hay được nhóm và trong một thư mục có kèm ứng
+dụng (được biết đến với thuật ngữ "vendoring" hay "bundling").
+
+**Một ứng dụng 12-hệ số không bao giờ phụ thuộc vào sự hiện diện tuyệt đối của các gói hệ
+thống.** Nó khai báo toàn bộ các phụ thuộc hoàn toàn thông qua bản kê khai *khai báo phụ thuộc*. Hơn thế nữa nó còn sử dụng công cụ *phân cách phụ thuộc* trong quá trình thực thi để
+đảm bảo rằng không có các phụ thuộc tuyệt đối nào bị "lọt" vào trong các hệ thống xung quanh.
+Khai báo đầy đủ và rõ ràng các phụ thuộc được áp dụng đồng đều cho cả hệ thống sản xuất và
+phát triển.
+
+Lấy ví dụ [Gem Bundler](http://gembundler.com/) của Ruby cung cấp định dạng kê khai `Gemfile` để khai báo phụ thuộc và `bundle exec` để phân cách phụ thuộc. Với Python thì có công cụ riêng biệt cho các bước trên -- [Pip](http://www.pip-installer.org/en/latest/) được dùng để khai báo [Virtualenv](http://www.virtualenv.org/en/latest/) để phân cách. Ngay cả C có [Autoconf](http://www.gnu.org/s/autoconf/) để khai báo phụ thuộc, và liên kết tĩnh (static linking) có thể cung cấp phân cách phụ thuộc. Bất kể công cụ gì, kê khai phụ thuộc và phân cách luôn phải đi đôi với nhau -- chỉ cần thiếu một trong hai là không đạt yêu câu của của 12-hệ số.
+
+Một ích lợi khác của khai báo phụ thuộc rõ ràng là nó đơn giản hoá quá trình cài đặt cho
+lập trình viên mới tiếp nhận dự án. Các lập trình viên mới có thể lấy về mã trên hệ thống
+phát triển của họ, chỉ với một yêu cầu là cài đặt trước ngôn ngữ lập trình và trình quản lý
+phụ thuộc. Chúng có thể được dùng để thiết lập mọi thứ cần để vận hành một ứng dụng với một
+*lệnh biên dịch/xây dựng* định sẵn. Lấy một ví dụ cụ thể là lệnh thiết lập cho Ruby/Bundler là `bundle install`, còn với Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) là `lein deps`.
+
+Các ứng dụng 12-hệ số đông thời có thể không phụ thuộc vào bất cứ sự hiện diện của các công cụ hệ thống tuyệt đối nào. Các ví dụ bao gồm các công cụ cài đặt sẵn như ImageMagick hay `curl`. Trong khi các công cụ trên có thể hiện diện trên đa số các hệ thống, nhưng không có gì bảo
+đảm là chúng sẽ hiện diện trên toàn bộ các hệ thống mà ứng dụng có thể chạy trong tương la, hoặc có chăng phiên bản tìm thấy trên các hệ thống tương lai sẽ tương thích với ứng dụng. Nếu ứng dụng cần được cài sẵn như một công cụ hệ thống, các công cụ đó nên được đi kèm cùng
+với ứng dụng.
diff --git a/content/vi/dev-prod-parity.md b/content/vi/dev-prod-parity.md
new file mode 100644
index 000000000..bf83fb9c9
--- /dev/null
+++ b/content/vi/dev-prod-parity.md
@@ -0,0 +1,75 @@
+## X. Sự tương đồng giữa quá trình phát triển và vận hành thực tế
+### Đảm bảo sự tương đồng giữa môi trường phát triển, kiểm thử và thực tế
+
+Trước đây, có sự khác biệt nhất định giữa quá trình phát triển (lập trình viên có thể tạo ra các bản chỉnh sửa [triển khai](./codebase) cục bộ của ứng dụng) và vận hành thực tế (phiên bản được triển khai thực tế và truy cập bởi khách hàng). Khác biệt này được thể hiện ở ba lĩnh vực:
+
+* **Về thời gian**: Lập trình viên có thể làm việc với mã nguồn hàng ngày, tuận, thậm chỉ là hàng tháng để có một phiên bản vận hành thực tế.
+* **Về tính cá nhân**: Lập trình viên viết mã nguồn, người vận hành triển khai mã nguồn đó.
+* **Về công cụ**: Lập trình viên có thể sử dụng tập các công cụ như là Nginx, SQLite, và OS X, trong khi triển khai thực tế sử dụng Apache, MySQL, và Linux.
+
+**Ứng dụng áp dụng mười hai hệ số được thiết kế để [triển khai liên tục](http://www.avc.com/a_vc/2011/02/continuous-deployment.html) bằng việc giảm thiểu khác biệt giữa quá trình triển khai và vận hành thực tế.** Chúng ta cùng xem lại các sự khác biệt ở trên:
+
+* Giảm thiểu thời gian: lập trình viên có thể viết mã nguồn và nó được triển khai vài giờ, thậm chí vài phút sau đó.
+* Giảm thiểu tính cá nhân: lập trình viên người viết ra các dòng lệnh, có thể tham gia trực tiếp vào quá trình triển khai và quan sát các hình vi của ứng dụng trong môi trường vận hành thực tế.
+* Giảm thiểu các công cụ: đảm bảo sự tương đồng giữa môi trường phát triển và vận hành.
+
+Tổng kết vấn đề trên thông qua bảng sau:
+| + | Ứng dụng truyền thống | +Ứng dụng sử dụng mười hai hệ số | +
|---|---|---|
| Thời gian giữa các lần triển khai | +Hàng tuần | +Hàng giờ | +
| Tác giả và người triển khai mã nguồn | +Khác nhau | +Cùng một người | +
| Môi trường phát triển và thực tế | +Không đồng nhất | +Tương đồng | +
| Loại | +Ngôn ngữ | +Thư viện | +Mô phỏng | +
|---|---|---|---|
| Cơ sở dữ liệu | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| Hàng đợi | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| Bộ đệm | +Ruby/Rails | +ActiveSupport::Cache | +Memory, filesystem, 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..09e0f443b
--- /dev/null
+++ b/content/zh_cn/build-release-run.md
@@ -0,0 +1,18 @@
+## V. 构建，发布，运行
+### 严格分离构建和运行
+
+[基准代码](./codebase) 转化为一份部署(非开发环境)需要以下三个阶段：
+
+* *构建阶段* 是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包 [依赖项](./dependencies)，编译成二进制文件和资源文件。
+* *发布阶段* 会将构建的结果和当前部署所需 [配置](./config) 相结合，并能够立刻在运行环境中投入使用。
+* *运行阶段* （或者说“运行时”）是指针对选定的发布版本，在执行环境中启动一系列应用程序 [进程](./processes)。
+
+
+
+**12-factor 应用严格区分构建，发布，运行这三个步骤。** 举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建步骤。
+
+部署工具通常都提供了发布管理工具，最引人注目的功能是退回至较旧的发布版本。比如， [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..5cc3b90eb
--- /dev/null
+++ b/content/zh_cn/codebase.md
@@ -0,0 +1,17 @@
+## I. 基准代码
+### 一份基准代码（*Codebase*），多份部署（*deploy*）
+
+12-Factor应用(译者注：应该是说一个使用本文概念来设计的应用，下同)通常会使用版本控制系统加以管理，如[Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), [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..212debfb2
--- /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](https://github.com/eventmachine/eventmachine), [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 文件。相反的，应该借助操作系统的进程管理器(例如 [systemd](https://www.freedesktop.org/wiki/Software/systemd/) ，分布式的进程管理云平台，或是类似 [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..ce9a3eb4b
--- /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 的 [Bundler](https://bundler.io/) 使用 `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..70f668c7f
--- /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://avc.com/2011/02/continuous-deployment/) 就必须缩小本地与线上差异。** 再回头看上面所描述的三个差异:
+
+* 缩小时间差异：开发人员可以几小时，甚至几分钟就部署代码。
+* 缩小人员差异：开发人员不只要编写代码，更应该密切参与部署过程以及代码在线上的表现。
+* 缩小工具差异：尽量保证开发环境以及线上环境的一致性。
+
+将上述总结变为一个表格如下：
+
+| + | 传统应用 | +12-Factor 应用 | +
|---|---|---|
| 每次部署间隔 | +数周 | +几小时 | +
| 开发人员 vs 运维人员 | +不同的人 | +相同的人 | +
| 开发环境 vs 线上环境 | +不同 | +尽量接近 | +
| 类型 | +语言 | +类库 | +适配器 | +
|---|---|---|---|
| 数据库 | +Ruby/Rails | +ActiveRecord | +MySQL, PostgreSQL, SQLite | +
| 队列 | +Python/Django | +Celery | +RabbitMQ, Beanstalkd, Redis | +
| 缓存 | +Ruby/Rails | +ActiveSupport::Cache | +Memory, filesystem, Memcached | +