Wednesday, September 02, 2009

Deployment of php applications

Deployment is the process of taking live a codebase: make a web application work by transporting it to the production server, configuring it in the local environment and start the needed daemons. Here is a checklist for deploying php applications, which have the advantage of not requiring compilation.

Transporting the codebase
I used mainly two types of file transfer to get a working copy of an application:
  • ftp: it is the most proven technique and was the right choice for uploading a large amount of data. It is slowly becoming obsolete for deployment purposes but almost every hosting provider offers an ftp service.
  • ssh and subversion: where available, a remote shell with a working copy of the codebase under version control is a powerful choice for rapid updates, since it keep track of local "hot" changes and it transmits only modified and new files over the network.
It is considered good practice to checkout in an auxiliary folder and to work on it until the application is ready. A symbolic link is then established to this new folder for simple rollback is something goes wrong (and it will).

Setting up the environment
You should never forget to check source files and environment properties to make sure the application is runnable and it can act on the right data.
  • writable (aka public) folders: some folders have to be writable from the php process because files will be kept in them after uploading or elaboration. Ftp transfer normally does not mantain chmod permissions, so you may have to tweak it manually.
  • file permissions: the same configuration applies to writable files, like sqlite databases or similar.
  • database schema: every version or release of an application which uses a relational database will work along with a particular version of the schema, the definition of tables and their columns. A migration script should be prepared to upgrade the table from the previous structure. If it's the first deployment, the database must be created ex-novo.
  • other setup: any product will probably have a configuration script or web page to run, or a config file to compile. For example blogs and cms need database credentials that must be entered in a config.php file which will be included in every http request.
Starting the daemons
About the php case, the database and web servers are always running, being them on a shared or virtualized server. Php applications have a shared nothing architecture, so once they are configured the web application should run smoothly: this is a very different workflow from Java one, where you have to recompile and/or a packing a new jar. It theory, you can work by manually modifying scripts and uploading to a web server, but it is not a very good practice.
In some cases, a restart of webserver is needed, for instance if using aggressive apc options which cache in memory the content of php scripts. Otherwise, php scripts will be interpreted as needed by user requests.

Be sure to double check your assumptions; going live is a delicate procedure but is the key to show the world your beautiful product.

No comments: