PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

The Twelve-Factor App Applied to PHP

Note: This article was originally published at Planet PHP on 19 April 4260.
Planet 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

aoOne codebase tracked in revision control, many deploysa

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

aoExplicitly declare and isolate dependenciesa

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

aoStore config in the environmenta

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

aoTreat backing services as attached resourcesa

There's not really anything to say here that's specific to PHP.

V. Build, release, run

aoStrictly separate build and run stagesa

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

aoExecute the app as one or more stateless processesa

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

aoExport services via port bindinga

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

aoScale out via the process modela

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

aoMaximize robustness with fast startup and graceful shutdowna

PHP processes are

Truncated by Planet PHP, read more at the original (another 1526 bytes)