DRAFT checklist for developing or benchmarking an application against 12factor.net

12factorapp_checklist.md

The twelve-factor app Checklist

Also factors in the four principles of modern Release Engineering

• Identifiability Being able to identify all of the source, tools, environment, and other components that make up a particular release.
• Reproducibility The ability to integrate source, third party components, data, and deployment externals of a software system in order to guarantee operational stability.
• Consistency The mission to provide a stable framework for development, deployment, audit, and accountability for software components.
• Agility The ongoing research into what are the repercussions of modern software engineering practices on the productivity in the software cycle, i.e. continuous integration.

Codebase

One codebase tracked in revision control, many deploys

The Version Control system manages past, present, and proposed versions as branches

• 1 code base for an app, no code is shared or dependent on code from any other app?
• 1 code repository is used to managed all releases/versions?

Dependencies

Explicitly declare and isolate dependencies

All required dependencies either use a community package manager or are managed from source are managed in a permissioned version control system.

• the app does not rely on common/system-wide packages (ex. apt-get/yum)
• the app installs within an isolated or virtualized environment where version of the code engine (python/ruby/node) are explicitly controlled/declared in addition to its required libraries/dependencies (*if applicable)

Ruby

• Gemfile Node
• package.json Python
• requirements.txt

Config

All system/service configuration is stored in a separate and secure environment

The app stores config in environment variables that are easy to change between deploys without changing any code. They are never grouped together as "environments" (does not scale), but instead are independently managed for each deploy.

• Configuration is seperated from codebase
• Configuration is managed entirely by variables that can be changed/established on build
• Production Config files are managed in a private repository with 2-factor auth or managed as prompts
• Production Config files are included in .gitignore

Backing Services

Treat backing services (DB/Messaging/SearchIndexing/Email/etc) as external attached resources

The code for an app makes no distinction between local and third party services.

• Item 1
• Item 2

Build, Release, Run

Strictly separate build and run stages

• Item 1
• Item 2

Processes

Execute the app as one or more stateless processes

Processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database. Sticky sessions are a violation and should never be used or relied upon.

• Item 1
• Item 2

Port binding

---

Export services via port binding

Ensure build scripts denote all ports/users

• Item 1
• Item 2

Concurrency

Scale out via the process model

Blah

• Item 1
• Item 2

Disposability

Maximize robustness with fast startup and graceful shutdown

Blah

• Item 1
• Item 2

Dev/prod parity

Keep development, staging, and production as similar as possible

Make the following gap as small as possible:

• The time gap: Time between writing code and deploy of it.
• The personell gap: Developers write code, ops deploy it.
• The tools gap: Development and production tools.

• Item 1
• Item 2

Logs

Treat logs as events streams

The app never concerns itself with routing or storage of its output.

• Item 1

• Item 2

• ## Admin processes Run admin/management tasks as one-off processes

Blah

• Item 1
• Item 2

Notes from https://polyawesomism.wordpress.com/2015/08/12/cheat-sheet-twelve-factor-app/

Factors

Codebase:

• Single repository per app (e.g. GitHub), deployed on various machines (e.g. staging, prod).

Dependencies:

• All dependencies are explicitly declared in a packaging system (e.g. Bundler, Chef) and isolated from the wider system when the app is run.

Config:

• Variables (i.e. values that vary between deploys, credentials) stored as environment variables (no code change, can’t be checked in to repo, OS agnostic, cleaner, scalable).

Backing Services:

• All external dependencies (e.g. database, SMTP) are treated as attached resources, able to be swapped out without any code changes

Build, Release, Run:

• Strictly separated, versioned, immutable, one-way process from code repository to build (most moving parts, complied and ready for execution), to release (build combined with a config), to run (fewest moving parts, launch in environment).

Processes:

• Executed code is stateless and shares nothing — all data is stored in a stateful backing service (e.g. database, S3) although temporary storage can be used (e.g. memory, disk), but never depended upon.

Port Binding:

• App is completely self-contained and provides its own webserver as a dependency — the only responsibility of the environment is binding to a port to serve requests.

Concurrency:

• More smaller first-class citizen processes assigned to different process types working independently (collectively referred to as the process formation) to maximise scalability

Disposability:

• Processes should start quick, shut down gracefully, be robust against sudden termination (e.g. hardware failure), and can be started or stopped at a moment’s notice.

Dev/Prod Parity:

• Deploy hourly (time gap), coders also deploy (personnel gap), dev and prod environments are as similar as possible (tool gap) — including backing services (i.e. no developer shortcuts such as lightweight database via adapter)

Logs:

• All running processed write to stdout captured and collated by the environment (e.g. Fluent, Papertrail) for tailing, indexing, graphical representation or analysis.

Admin:

• Script

Copied from http://bradley-holt.com/2011/11/the-twelve-factor-app-applied-to-php/

The Twelve-Factor App Applied to PHP
If you develop web apps, I encourage you to check out The Twelve-Factor App. This is an excellent resource for anyone building and deploying software-as-a-service. PHP has great support for many of the twelve-factors. I want to take a look at specifically how each factor may be applied to a PHP application.
I. Codebase
“One codebase tracked in revision control, many deploys”
There’s really not much here that would be different in PHP versus any other language. Who isn’t using some form of revision control these days?
II. Dependencies
“Explicitly declare and isolate dependencies”
There are a few tools available to PHP developers to help manage dependencies. The PEAR package manager may help here, but has its flaws. Pyrus, the PEAR2 package manager, looks promising. There’s also Composer. I’ve heard of people using their operating system’s package manager (e.g. RPM) to deploy their PHP applications and manage dependencies. I’m not sure if there any tools in PHP to enforce dependency isolation.
III. Config
“Store config in the environment”
The simplest option here is to use environment variables. Many frameworks, including Zend Framework, allow you to have environment-specific configuration such as development, test, and production. This is not recommended for twelve-factor apps as it doesn’t scale as new environments are added.
IV. Backing Services
“Treat backing services as attached resources”
There’s not really anything to say here that’s specific to PHP.
V. Build, release, run
“Strictly separate build and run stages”
Phing or the more general-purpose Ant could work here. Even though it’s not written in PHP, there’s no reason why you couldn’t use Capistrano for this. I don’t think the run stage typically applies to PHP, as it happens implicitly as part of the release stage. However, there are tasks such as flushing the APC cache (if apc.stat=0) that might be considered part of the run stage.
VI. Processes
“Execute the app as one or more stateless processes”
PHP processes are already stateless and shared-nothing. This makes PHP a great fit for twelve-factor apps. Memory space or the filesystem should be used as a short-lived, single-process cache. If you’re using an asset manager, such as Assetic, then any assets should be compiled and cached during the build stage.
VII. Port binding
“Export services via port binding”
I don’t think port binding applies to PHP applications—at least not in the way it’s meant in twelve-factor. PHP relies on a web server and uses something like FastCGI or PHP-FPM to communicate with the web server. PHP 5.4 will have its own built-in web server, but this is intended for development use only. It’s really the combination of PHP and its web server that will be bound to a port. This brings up challenges when it comes to dependency management, as the web server itself is now a dependency.
VIII. Concurrency
“Scale out via the process model”
I’m not sure how processes would become first-class citizens in a PHP web application. However, each individual request/response cycle is handled by its own process. In that regard, PHP already uses the process model.
IX. Disposability
“Maximize robustness with fast startup and graceful shutdown”
PHP processes are very disposable. Again, this is just part of how PHP works.
X. Dev/prod parity
“Keep development, staging, and production as similar as possible”
Nothing specific to PHP here. Although, it’s not uncommon for PHP developers to use SQLite in development and MySQL or PostgreSQL in production. This is not recommended for a twelve-factor app—use the same software and versions of backing services in all environments.
XI. Logs
“Treat logs as event streams”
There are tons of logging options in PHP. Zend_Log_Writer_Stream lets you send log data to a PHP stream. Alternatively, StatsD and the PHP StatsD library look pretty good.
XII. Admin processes
“Run admin/management tasks as one-off processes”
This is easy enough in PHP. If you want an interactive shell with readline history, tab completion, and quick access to documentation then check out phpsh.