The Twelve-Factor App

Introduction

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

Background

The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform.

This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and avoiding the cost of software erosion.

Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books Patterns of Enterprise Application Architecture and Refactoring.

Who should read this document?

Any developer building applications which run as a service. Ops engineers who deploy or manage such applications.

The Twelve Factors

I. 코드베이스

버전 관리되는 하나의 코드베이스와 다양한 배포

II. 종속성

명시적으로 선언되고 분리된 종속성

III. 설정

환경(environment)에 저장된 설정

IV. 백엔드 서비스

백엔드 서비스를 연결된 리소스로 취급

V. 빌드, 릴리즈, 실행

철저하게 분리된 빌드와 실행 단계

VI. 프로세스

애플리케이션을 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행

VII. 포트 바인딩

포트 바인딩을 사용해서 서비스를 공개함

VIII. 동시성(Concurrency)

프로세스 모델을 통한 확장

IX. 폐기 가능(Disposability)

빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화

X. dev/prod 일치

development, staging, production 환경을 최대한 비슷하게 유지

XI. 로그

로그를 이벤트 스트림으로 취급

XII. Admin 프로세스

admin/maintenance 작업을 일회성 프로세스로 실행