Dutch Translation

content/nl/admin-processes.md

@@ -0,0 +1,14 @@
+## XII. Admin-processen
+### Voer admin/beheertaken uit als eenmalige processen
+
+De [proces formatie](./concurrency) is de reeks van processen die gebruikt worden om de gewone zaken van de app te doen (zoals het afhandelen van web verzoeken) terwijl het draait. Los daarvan zullen ontwikkelaars vaak eenmalige administratieve of onderhoudstaken voor de app willen doen, zoals:
+
+* Het uitvoeren van database migraties (bijv. `manage.py migrate` in Django, `rake db:migrate` in Rails).
+* Het uitvoeren van een console (ook bekend als een [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) shell) om willekeurige code uit te voeren of de modellen van de app te inspecteren tegen de live database.  De meeste talen bieden een REPL door het uitvoeren van de interpreter zonder argumenten (bijv. `python` of `perl`) of in sommige gevallen hebben een apart commando (bijv. `irb` voor Ruby, `rails console` voor Rails).
+* Het draaien van eenmalige scripts die gecommit zijn in de repo van de app (bijv. `php scripts/fix_bad_records.php`).
+
+Eenmalige admin processen moeten worden uitgevoerd in een identieke omgeving als de reguliere [langlopende processen](./processes) van de app. Ze draaien tegen een [release](./build-release-run), met dezelfde [codebase](./codebase) en [config](./config) als elk proces dat tegen die release draait. De beheercode moet samen met de applicatiecode worden geleverd om synchronisatieproblemen te voorkomen.
+
+Dezelfde [dependency isolation](./dependencies) technieken moeten gebruikt worden op alle procestypes. Bijvoorbeeld, als het Ruby web proces het commando `bundle exec thin start` gebruikt, dan zou een database migratie `bundle exec rake db:migrate` moeten gebruiken. Op dezelfde manier zou een Python programma dat Virtualenv gebruikt de vendored `bin/python` moeten gebruiken voor het draaien van zowel de Tornado webserver als alle `manage.py` admin processen.
+
+12-factor heeft een sterke voorkeur voor talen die een REPL shell uit de doos bieden, en die het gemakkelijk maken om eenmalige scripts te draaien. In een lokale implementatie roepen ontwikkelaars eenmalige admin processen aan door een direct shell commando in de checkout directory van de app. Bij een productie-implementatie kunnen ontwikkelaars ssh gebruiken of een ander mechanisme om commando's op afstand uit te voeren, zoals voorzien door de uitvoeringsomgeving van die implementatie, om zo'n proces uit te voeren.

content/nl/background.md

@@ -0,0 +1,8 @@
+Achtergrond
+==========
+
+De medewerkers aan dit document zijn direct betrokken geweest bij de ontwikkeling en implementatie van honderden apps, en zijn indirect getuige geweest van de ontwikkeling, werking en schaling van honderdduizenden apps via ons werk op het <a href="http://www.heroku.com/" target="_blank">Heroku</a> platform
+
+Dit document verzamelt al onze ervaringen en observaties over een grote verscheidenheid van software-as-a-service apps in het wild. Het is een verzameling van ideale praktijken voor app-ontwikkeling, met bijzondere aandacht voor de dynamiek van de organische groei van een app in de tijd, de dynamiek van de samenwerking tussen ontwikkelaars die werken aan de codebase van de app, en <a href="http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/" target="_blank">het vermijden van de kosten van software-erosie</a>.
+
+Onze motivatie is om het bewustzijn te vergroten van een aantal systematische problemen die we hebben gezien in de moderne applicatie-ontwikkeling, om een gedeelde woordenschat te bieden voor het bespreken van deze problemen, en om een set van brede conceptuele oplossingen aan te bieden voor die problemen met bijbehorende terminologie. De indeling is geïnspireerd op Martin Fowler's boeken *<a href="https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC" target="_blank">Patterns of Enterprise Application Architecture</a>* en *<a href="https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C" target="_blank">Refactoring</a>*.

content/nl/backing-services.md

@@ -0,0 +1,14 @@
+## IV. Backing-diensten
+### Behandel backing services als bijgevoegde bronnen
+
+Een *backing service* is een service die de app via het netwerk gebruikt als onderdeel van zijn normale werking. Voorbeelden zijn datastores (zoals [MySQL](http://dev.mysql.com/) of [CouchDB](http://couchdb.apache.org/)), messaging/queueing systemen (zoals [RabbitMQ](http://www.rabbitmq.com/) of [Beanstalkd](https://beanstalkd.github.io)), SMTP diensten voor uitgaande email (zoals [Postfix](http://www.postfix.org/)), en caching systemen (zoals [Memcached](http://memcached.org/)).
+
+Backing services zoals de database worden traditioneel beheerd door dezelfde systeembeheerders die de runtime van de app implementeren. Naast deze lokaal beheerde diensten, kan de app ook diensten hebben die door derden worden geleverd en beheerd. Voorbeelden zijn SMTP-diensten (zoals [Postmark](http://postmarkapp.com/)), metriek-verzamelende diensten (zoals [New Relic](http://newrelic.com/) of [Loggly](http://www.loggly.com/)), binaire asset-diensten (zoals [Amazon S3](http://aws.amazon.com/s3/)), en zelfs API-toegankelijke consumentendiensten (zoals [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), of [Last.fm](http://www.last.fm/api)).
+
+**De code voor een 12-factor app maakt geen onderscheid tussen lokale diensten en diensten van derden.** Voor de app zijn beide verbonden resources, toegankelijk via een URL of andere locator/credentials opgeslagen in de [config](./config). Een [deploy](./codebase) van de 12-factoren app zou in staat moeten zijn om een lokale MySQL database te verwisselen met een die wordt beheerd door een derde partij (zoals [Amazon RDS](http://aws.amazon.com/rds/)) zonder enige wijzigingen aan de code van de app. Op dezelfde manier zou een lokale SMTP-server kunnen worden vervangen door een SMTP-service van een derde partij (zoals Postmark) zonder codewijzigingen. In beide gevallen hoeft alleen de resource handle in de config veranderd te worden.
+
+Elke afzonderlijke backing service is een *resource*. Bijvoorbeeld, een MySQL database is een bron; twee MySQL databases (gebruikt voor sharding op de applicatielaag) kwalificeren als twee verschillende bronnen. De 12-factor app behandelt deze databases als *attached resources*, wat aangeeft dat ze losgekoppeld zijn aan de deploy waaraan ze gekoppeld zijn.
+
+<img src="/images/attached-resources.png" class="full" alt="A production deploy attached to four backing services." />
+
+Resources kunnen naar believen aan deploys worden toegevoegd of ervan worden losgekoppeld. Bijvoorbeeld, als de database van de app zich niet goed werkt vanwege een hardwareprobleem, kan de app-beheerder een nieuwe databaseserver opstarten die is hersteld vanaf een recente back-up. De huidige productiedatabase kan worden losgekoppeld en de nieuwe database aangekoppeld -- allemaal zonder enige codewijziging.

content/nl/build-release-run.md

@@ -0,0 +1,18 @@
+## V. Build, release, run
+### Strikt gescheiden houden van build en run stadia
+
+Een [codebase](./codebase) wordt getransformeerd in een (niet-ontwikkel) deploy door drie stadia:
+
+* De *build stage* is een transformatie die een code repo omzet in een uitvoerbare bundel, bekend als een *build*. Met behulp van een versie van de code op een commit gespecificeerd door het deployment proces, haalt de build fase vendors [dependencies](./dependencies) op en compileert binaries en assets.
+* De *release stage* neemt de geproduceerde build van de build stage en combineert het met de huidige [config](./config) van de deploy. De resulterende *release* bevat zowel de build als de config en is klaar voor onmiddellijke uitvoering in de uitvoeringsomgeving.
+* De *run fase* (ook bekend als "runtime") draait de app in de executie omgeving, door het starten van een set van de app's [processen](./processes) tegen een geselecteerde release.
+
+![Code wordt een build, die gecombineerd wordt met config om een release te maken.](/images/release.png)
+
+**De 12-factor app maakt gebruik van een strikte scheiding tussen de build, release en run stadia.** Het is bijvoorbeeld onmogelijk om wijzigingen aan te brengen in de code tijdens runtime, aangezien er geen manier is om die wijzigingen terug te propageren naar het build stadium.
+
+Deployment tools bieden meestal release management tools, met name de mogelijkheid om terug te gaan naar een vorige release. Bijvoorbeeld, de [Capistrano](https://github.com/capistrano/capistrano/wiki) deployment tool slaat releases op in een subdirectory genaamd `releases`, waar de huidige release een symlink is naar de huidige release directory. Het `rollback` commando maakt het makkelijk om snel terug te gaan naar een vorige release.
+
+Elke release moet altijd een unieke release ID hebben, zoals een tijdstempel van de release (zoals `2011-04-06-20:32:17`) of een oplopend nummer (zoals `v100`).  Releases zijn een append-only grootboek en een release kan niet worden gemuteerd als deze eenmaal is aangemaakt. Elke verandering moet een nieuwe release aanmaken.
+
+Builds worden geïnitieerd door de ontwikkelaars van de app wanneer nieuwe code wordt uitgerold. Runtime uitvoering, daarentegen, kan automatisch gebeuren in gevallen zoals een server reboot, of een gecrasht proces dat opnieuw wordt gestart door de procesmanager. Daarom moet de run-fase beperkt worden tot zo weinig mogelijk bewegende delen, omdat problemen die een app verhinderen te draaien midden in de nacht kunnen gebeuren als er geen ontwikkelaars bij de hand zijn. De build fase kan complexer zijn, omdat fouten altijd op de voorgrond staan voor een ontwikkelaar die de deploy aanstuurt.

content/nl/codebase.md

@@ -0,0 +1,17 @@
+## I. Codebase
+### Eén codebasis bijgehouden in versiebeheer, veel uitrollen
+
+Een twelve-factor app wordt altijd bijgehouden in een versiebeheersysteem, zoals [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), of [Subversion](http://subversion.apache.org/). Een database voor het bijhouden van revisies staat bekend als een *code repository*, vaak afgekort tot *code repo* of gewoon *repo*
+
+Een *codebasis* is een enkele repo (in een gecentraliseerd revisiebeheersysteem zoals Subversion), of een set van repo's die een root commit delen (in een gedecentraliseerd revisiebeheersysteem zoals Git)
+
+![Eén codebase gaat samen met vele uitrollen](/images/codebase-deploys.png)
+
+Er is altijd een één-op-één correlatie tussen de codebase en de app:
+
+* Als er meerdere codebasissen zijn, is het geen app -- het is een gedistribueerd systeem. Elk onderdeel in een gedistribueerd systeem is een app, en elk kan individueel conform zijn met twelve-factor principes.
+* Meerdere apps die dezelfde code delen is een overtreding van de twelve-factor principes. De oplossing hier is om gedeelde code te herwerken in software-libraries die kunnen worden opgenomen in de [dependency manager](./dependencies).
+
+Er is slecht één codebase per app, maar er zullen veel uitrollen van de app zijn. Een *uitrol* is een draaiende instantie van de app. Dit is typisch voor een productie omgeving, en een of meer staging omgevingen. Daarnaast heeft elke ontwikkelaar een kopie van de app draaien in hun lokale ontwikkelomgeving, die ook gekwalificeert zijn als een uitrol.
+
+De codebasis is dezelfde over alle uitrollen, hoewel verschillende versies actief kunnen zijn in elke uitrol. Bijvoorbeeld, een ontwikkelaar heeft een aantal commits die nog niet zijn uitgerold naar staging; staging heeft een aantal commits die nog niet zijn uitgerold naar productie. Maar ze delen allemaal dezelfde codebasis, waardoor ze identificeerbaar zijn als verschillende uitrollen van dezelfde app.

content/nl/concurrency.md

@@ -0,0 +1,14 @@
+## VIII. Concurrentie
+### Schaalvergroting via het procesmodel
+
+Elk computerprogramma, eenmaal uitgevoerd, wordt vertegenwoordigd door een of meer processen. Web apps hebben een verscheidenheid aan procesuitvoeringsvormen aangenomen. PHP-processen bijvoorbeeld draaien als kindprocessen van Apache, die op verzoek worden opgestart naar gelang de hoeveelheid verzoeken. Java processen hebben de tegenovergestelde aanpak, waarbij de JVM één groot uberproces levert dat een groot blok systeembronnen (CPU en geheugen) reserveert bij het opstarten, met concurrency die intern beheerd wordt via threads. In beide gevallen is (zijn) het (de) lopende proces(sen) slechts minimaal zichtbaar voor de ontwikkelaars van de app.
+
+![Schaal wordt uitgedrukt als lopende processen, workload diversiteit wordt uitgedrukt als procestypes.](/images/process-types.png)
+
+**In de 12-factor app zijn processen een eerste klas burger.** Processen in de 12-factor app zijn sterk afgeleid van [het unix procesmodel voor het draaien van service daemons](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Met behulp van dit model kan de ontwikkelaar zijn app ontwerpen om verschillende werkbelastingen aan te kunnen door elk type werk toe te wijzen aan een *procestype*. HTTP-verzoeken kunnen bijvoorbeeld worden afgehandeld door een webproces, en langlopende achtergrondtaken door een werkproces.
+
+Dit sluit niet uit dat individuele processen hun eigen interne multiplexing afhandelen, via threads in de runtime VM, of het async/evented model dat te vinden is in tools als [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), of [Node.js](http://nodejs.org/). Maar een individuele VM kan maar zo groot worden (verticale schaal), dus de applicatie moet ook in staat zijn om meerdere processen te overspannen die draaien op meerdere fysieke machines.
+
+Het procesmodel blinkt pas echt uit wanneer het tijd is om uit te schalen. De [niets delende, horizontaal partitioneerbare aard van 12-factor app processen] (./processes) betekent dat het toevoegen van meer concurrency een eenvoudige en betrouwbare operatie is. De reeks van procestypes en het aantal processen van elk type staat bekend als de *procesformatie*.
+
+12-factor app processen [moeten nooit daemoniseren](http://dustin.github.com/2010/02/28/running-processes.html) of PID-bestanden schrijven. Vertrouw in plaats daarvan op de procesmanager van het besturingssysteem (zoals [systemd](https://www.freedesktop.org/wiki/Software/systemd/), een gedistribueerde procesmanager op een cloud-platform, of een tool zoals [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) in ontwikkeling) om [uitvoerstromen](./logs) te beheren, te reageren op gecrashte processen, en door de gebruiker geïnitieerde herstarts en shutdowns af te handelen.

content/nl/config.md

@@ -0,0 +1,22 @@
+## III. Configuratie
+### Config opslaan in de omgeving
+
+De *config* van een app is alles wat waarschijnlijk varieert tussen [deploys](./codebase) (staging, productie, ontwikkelomgevingen, etc).  Dit omvat:
+
+* Resource handles naar de database, Memcached, en andere [backing-services](./backing-services)
+* Credentials naar externe diensten zoals Amazon S3 of Twitter
+* Per-deploy waarden zoals de canonieke hostnaam voor de deploy
+
+Apps slaan soms config op als constanten in de code. Dit is een schending van de 12-factors, die **strikte scheiding van config en code** vereist. Config varieert aanzienlijk tussen deploys, code niet.
+
+Een lakmoesproef voor het feit of een app alle configuratie correct uit de code heeft gehaald, is of de codebase op elk moment open source kan worden gemaakt, zonder de credentials te compromitteren.
+
+Merk op dat deze definitie van "config" **niet** interne applicatie config omvat, zoals `config/routes.rb` in Rails, of hoe [code modules zijn verbonden](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) in [Spring](http://spring.io/). Dit type van configuratie varieert niet tussen deploys, en wordt dus best in de code gedaan.
+
+Een andere benadering van config is het gebruik van config bestanden die niet ingecheckt worden in revisie controle, zoals `config/database.yml` in Rails. Dit is een enorme verbetering ten opzichte van het gebruik van constanten die in de code repo worden ingecheckt, maar heeft nog steeds zwakke punten: het is gemakkelijk om per ongeluk een config bestand in de repo in te checken; er is een neiging voor config bestanden om verspreid te zijn over verschillende plaatsen en verschillende formaten, wat het moeilijk maakt om alle config op één plaats te zien en te beheren. Verder hebben deze formaten de neiging programmeertaal- of framework-specifiek te zijn.
+
+**De 12-factor app slaat de configuratie op in *environment variables*** (vaak afgekort tot *env vars* of *env*).  Env vars zijn gemakkelijk te veranderen tussen deploys zonder code te veranderen; in tegenstelling tot config files, is er weinig kans dat ze per ongeluk in de code repo ingecheckt worden; en in tegenstelling tot custom config files, of andere config mechanismen zoals Java System Properties, zijn ze een programmeertaal- en OS-agnostische standaard.
+
+Een ander aspect van config management is groeperen. Soms groeperen apps hun config in benoemde groepen (vaak "omgevingen" genaamd), genoemd naar specifieke deploys, zoals de `development`, `test`, en `production` omgevingen in Rails. Deze methode schaalt niet netjes: als meer deploys van de app worden gemaakt, zijn nieuwe omgevingsnamen nodig, zoals `staging` of `qa`. Als het project verder groeit, kunnen ontwikkelaars hun eigen speciale omgevingen toevoegen, zoals `joes-staging`, wat resulteert in een combinatorische explosie van config die het beheren van deploys van de app erg broos maakt.
+
+In een 12-factor app, zijn env vars granulaire controls, elk volledig orthogonaal aan andere env vars. Ze worden nooit gegroepeerd als "omgevingen", maar worden in plaats daarvan onafhankelijk beheerd voor elke implementatie. Dit is een model dat soepel opschaalt naarmate de app zich op natuurlijke wijze uitbreidt naar meer implementaties gedurende zijn levensduur.