12 Factor App
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:
- Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
- Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
- Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
- Minimize divergence between development and production, enabling continuous deployment for maximum agility;
- And can scale up without significant changes to tooling, architecture, or development practices.
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. Codebase
One codebase tracked in revision control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production as similar as possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes
I. Codebase
One codebase tracked in revision control, many deploys
A twelve-factor app is always tracked in a version control system, such as Git, Mercurial, or Subversion. A copy of the revision tracking database is known as a code repository, often shortened to code repo or just repo.
A codebase is any single repo (in a centralized revision control system like Subversion), or any set of repos who share a root commit (in a decentralized revision control system like Git).
There is always a one-to-one correlation between the codebase and the app:
- If there are multiple codebases, it's not an app – it's a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor.
- Multiple apps sharing the same code is a violation of twelve-factor. The solution here is to factor shared code into libraries which can be included through the dependency manager.
There is only one codebase per app, but there will be many deploys of the app. A deploy is a running instance of the app. This is typically a production site, and one or more staging sites. Additionally, every developer has a copy of the app running in their local development environment, each of which also qualifies as a deploy.
The codebase is the same across all deploys, although different versions may be active in each deploy. For example, a developer has some commits not yet deployed to staging; staging has some commits not yet deployed to production. But they all share the same codebase, thus making them identifiable as different deploys of the same app.
I. 基准代码
一份基准代码(Codebase),多份部署(deploy)
12-Factor应用(译者注:应该是说一个使用本文概念来设计的应用,下同)通常会使用版本控制系统加以管理,如Git, Mercurial, Subversion。一份用来跟踪代码所有修订版本的数据库被称作 代码库(code repository, code repo, repo)。
在类似 SVN 这样的集中式版本控制系统中,基准代码 就是指控制系统中的这一份代码库;而在 Git 那样的分布式版本控制系统中,基准代码 则是指最上游的那份代码库。
基准代码和应用之间总是保持一一对应的关系:
- 一旦有多个基准代码,就不能称为一个应用,而是一个分布式系统。分布式系统中的每一个组件都是一个应用,每一个应用可以分别使用 12-Factor 进行开发。
- 多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案是将共享的代码拆分为独立的类库,然后使用 依赖管理 策略去加载它们。
尽管每个应用只对应一份基准代码,但可以同时存在多份部署。每份 部署 相当于运行了一个应用的实例。通常会有一个生产环境,一个或多个预发布环境。此外,每个开发人员都会在自己本地环境运行一个应用实例,这些都相当于一份部署。
所有部署的基准代码相同,但每份部署可以使用其不同的版本。比如,开发人员可能有一些提交还没有同步至预发布环境;预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码,我们就认为它们只是相同应用的不同部署而已。
12 Factor App的更多相关文章
- 12 Factor CLI Apps
CLIs are a fantastic way to build products. Unlike web applications, they take a small fraction of t ...
- docker应用容器化准则—12 factor
在云的时代,越来越多的传统应用需要迁移到云环境下,新应用也要求能适应云的架构设计和开发模式.而12-factor提供了一套标准的云原生应用开发的最佳原则. 在容器云项目中应用容器化主要参考12-Fac ...
- 12 factor 目录
I. 基准代码 一份基准代码,多份部署 II. 依赖 显式声明依赖关系 III. 配置 在环境中存储配置 IV. 后端服务 把后端服务当作附加资源 V. 构建,发布,运行 严格分离构建和运行 VI. ...
- 161027、Java 中的 12 大要素及其他因素
对于许多人来说,"原生云"和"应用程序的12要素"是同义词.本文的目的是说有很多的原生云只坚持了最初的12个因素.在大多数情况下,Java 能胜任这一任务.在本 ...
- Netflix分享构建Microservices的经验
Netflix分享构建Microservices的经验 http://t.cn/Rwjgutw 新词:Microservices.我觉得就是service oriented architecture的 ...
- Docker website
https://github.com/docker/labs/ (nguo123gmail Cooooos123!) Docker Tutorials and Labs At this time ...
- DevOps 工程师成长日记系列二:配置
原文地址:https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-2-config ...
- 关于Sidecar Pattern
本文转载自关于Sidecar Pattern 导语 Sidecar 是一个很纠结的名字,我们在翻译技术雷达时采用了一个比较通俗的翻译,即边车,而这个词随着微服务的火热与 Service Mesh 的逐 ...
- oclif cli app开发简单试用
oclif 是heroku 开源的cli 开发框架,有一篇关于12 factor cli app 开发的文章很值得看看 https://medium.com/@jdxcode/12-factor-cl ...
随机推荐
- c# 读取对象的[公有属性]的名称,类型,值
/// <summary> /// 获取某个对象的[公有属性]的名称,类型,值 /// </summary> /// <typeparam name="T&qu ...
- windows下安装gym
安装gym在执行pip install -e'.[all]'这句语句时,可能会出现这种情况 在pycharm中运行的时候会出现如下这种情况: 或者这种情况 出现这种问题可能是python的版本太高了, ...
- aria2 源码解析专题—— (一)基础架构
此文章是这个专题的开篇,由于初入 C++ 的大门,所以想着拿个项目来看看,凑巧有点基础,又想学习一下在unix上的编程,所以就找了 aria2 这个库来看看源码,希望能学到一些东西. 言归正传,今天把 ...
- tensorflow源码解析之common_runtime-graph_optimizer
目录 核心概念 graph_optimizer function optimization_registry 1. 核心概念 本篇主要讲图的优化迭代器.我们在构建原始图的时候,专注于达到目的,但不会去 ...
- 如何用webgl(three.js)搭建处理3D隧道、3D桥梁、3D物联网设备、3D高速公路、三维隧道桥梁设备监控-第十一课
开篇废话: 跟之前的文章一样,开篇之前,总要写几句废话,大抵也是没啥人看仔细文字,索性我也想到啥就聊啥吧. 这次聊聊疫情,这次全国多地的疫情挺严重的,本人身处深圳,深圳这几日报导都是几十几十的新增病例 ...
- LGP6276题解
众所周知,排列是一个置换,一个置换是一车环. 步数就是这些环长的 \(lcm\). 如果你去思考直接 DP,会发现很困难,根本设不出来状态.于是考虑正难则反:每个质数幂 \(p^k\) 对答案的贡献. ...
- LGP3703题解
不会数据结构石锤了/kk 题意清晰. 我们看到 \(1\) 操作比较奇怪,考虑从 \(1\) 操作入手. 设 \(f_u\) 为 \(u\) 到根节点一共有多少种颜色,我们使用树剖来维护这个东西. 考 ...
- ASP.NET Core框架探索之Authorization
今天我们一起来探索一下ASP.NET Core框架中的Authorization.我们知道请求进入管道处理流程先会使用Authentication进行用户认证,然后使用Authorization进行用 ...
- python 程序小练习
print("Type integers,each followed by Enter; or just Enter to finish") total = 0 count = 0 ...
- Using Beyond Compare with TFS
In order to configure Visual Studio to use Beyond Compare for a compare operation choose the followi ...