Bradley Holt is a web developer, entrepreneur, community facilitator, speaker, and an author. He is the co-founder of Found Line, a creative studio with capabilities in web development, web design, and print design. He is a Board Member at Vermont Community Access Media, a non-profit community media and technology center. He is a minor contributor of source code and bug reports to Zend Framework and an active member of the PHP community. He organizes the Burlington, Vermont PHP Users Group where he is a regular speaker and is involved with helping to organize other technology community events such as Vermont Code Camp. He has spoken at (or will be speaking at) SXSW Interactive, OSCON, OSCON Data, the jQuery Conference, and ZendCon. He is the author of Writing and Querying MapReduce Views in CouchDB and Scaling CouchDB, both published by O’Reilly Media. He blogs at bradley-holt.com and can be found on Twitter as @BradleyHolt. Bradley is a DZone MVB and is not an employee of DZone and has posted 17 posts at DZone. You can read more from them at their website. View Full User Profile

The Twelve-Factor App Applied to PHP

11.30.2011
| 2733 views |
  • submit to reddit

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.

 

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

Published at DZone with permission of Bradley Holt, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)