Comments on: Deployment of PHP Applications

By: Mike Willbanks

Mike Willbanks — Tue, 24 Nov 2009 02:25:14 +0000

Bradley – you are correct on both fronts, the main reason for having a pre and post deployment is to eliminate any potential downtime as well as having database changes that are capable for handling the current code base as you hit every server in an area.

The biggest advantage that this has is that you can create the table structure for the current code base and then move it into what you need in the post.

For example: We need to add a new column to our user table, there are a few ways to do it. Typically I would add a column in the pre-deployment where I want it to have a default and then in the post taking away the default as well as migrating the additional user records.

Another example: We are moving to another table and it doesn’t make sense to make the changes directly to the table, we make a new table that the new application will utilize when the application is deployed per server, then we migrate the existing data to the new app post-deployment. For example, say you have a large table (1+ million records) you are going to take downtime if you modify it directly in relation to a commonly utilize table, however, if you utilize this strategy this is mitigated.

By: Bradley Holt

Bradley Holt — Tue, 10 Nov 2009 23:40:58 +0000

Good article — I also enjoyed your ZendCon UnCon session on the topic. However, there is one piece that I’m still a little confused about. What is the purpose of having separate pre-deployment and post-deployment files? And, how exactly do you implement these two separate files? I think the purpose of the pre-deployment file is to make any database changes that are both backwards and forwards compatible (i.e. will run against either the old or the newly deployed application) and the purpose of the post-deployment file is to make any necessary database changes that may *not* be backwards compatible and so can only be run after deployment. Is this correct? Also, in your ZendCon UnCon session I thought you said that if you were using dbeploy you would have separate pre and post metadata tables. Can you go into more detail about how this would work? It seems odd to have two metatdata tables that are both responsibility for deploying the same database. Is the goal of all these pre and post files to have zero downtime due to database migrations or is there another benefit to this approach?

By: Daniel Cousineau

Daniel Cousineau — Fri, 09 Oct 2009 17:41:07 +0000

DBDeploy is a great resource, even if only for the fact that Phing ships with a DBDeploy plugin built straight in. It is pretty close to the metal though (deltas are SQL files partitioned into your UP and DOWN scripts).

If you decide to use it, the Doctrine ORM has very nice migration features like being able to run a diff against your schema changes and last built models to create your migration deltas.