The Twelve-Factor App

Einführung

Heute wird Software oft als Dienst geliefert - auch Web App oder Software-As-A-Service genannt. Die Zwölf-Faktoren-App ist eine Methode um Software-As-A-Service Apps zu bauen die:

Die Zwölf-Faktoren-Methode kann auf Apps angewendet werden, die in einer beliebigen Programmiersprache geschrieben sind, und die eine beliebige Kombination von unterstützenden Diensten benutzen (Datenbank, Queue, Cache, …)

Hintergrund

Die Mitwirkenden an diesem Dokument waren direkt beteiligt an der Entwicklung und dem Deployment von hunderten von Apps und wurden Zeugen bei der Entwicklung, beim Betrieb und der Skalierung von hunderttausenden von Apps im Rahmen unserer Arbeit an der Heroku-Plattform.

Dieses Dokument ist eine Synthese all unserer Erfahrungen und der Beobachtungen einer großen Bandbreite von Software-As-A-Service Apps. Es ist eine Bestimmung der idealen Praktiken bei der App-Entwicklung mit besonderem Augenmerk auf die Dynamik des organischen Wachstums einer App über die Zeit, die Dynamik der Zusammenarbeit zwischen den Entwicklern die an einer Codebase zusammenarbeiten und der Vermeidung der Kosten von Software-Erosion.

Unsere Motivation ist, das Bewusstsein zu schärfen für systembedingte Probleme in der aktuellen Applikationsentwicklung, ein gemeinsames Vokabular zur Diskussion dieser Probleme zu liefern und ein Lösungsportfolio zu diesen Problemen mit einer zugehörigen Terminologie anzubieten. Das Format ist angelehnt an Martin Fowlers Bücher Patterns of Enterprise Application Architecture und Refactoring.

Wer sollte dieses Dokument lesen?

Jeder Entwickler der Apps baut, die als Dienst laufen. Administratoren, die solche Apps managen oder deployen.

Die zwölf Faktoren

I. Codebase

Eine im Versionsmanagementsystem verwaltete Codebase, viele Deployments

II. Abhängigkeiten

Abhängigkeiten explizit deklarieren und isolieren

III. Konfiguration

Die Konfiguration in Umgebungsvariablen ablegen

IV. Unterstützende Dienste

Unterstützende Dienste als angehängte Ressourcen behandeln

V. Build, release, run

Build- und Run-Phase strikt trennen

VI. Prozesse

Die App als einen oder mehrere Prozesse ausführen

VII. Bindung an Ports

Dienste durch das Binden von Ports exportieren

VIII. Nebenläufigkeit

Mit dem Prozess-Modell skalieren

IX. Einweggebrauch

Robuster mit schnellem Start und problemlosen Stopp

X. Dev-Prod-Vergleichbarkeit

Entwicklung, Staging und Produktion so ähnlich wie möglich halten

XI. Logs

Logs als Strom von Ereignissen behandeln

XII. Admin-Prozesse

Admin/Management-Aufgaben als einmalige Vorgänge behandeln