Managing multiple web applications with the same code base

Question

I'm looking for the best way (or easiest way) to manage multiple instances of a PHP web application, that share the same code base.

Let me break it down for you:

Our domain is hosting multiple instances of the application, each with their own settings files and database.

http://mydomain.com
|
|------/customer1/
|
|------/customer2/
|
|------/customer3/ + custom features

Let's say that customer 1 & 2 purchased the application (that we host for them), and they have the base model of that application. (ie. not customized)

However, customer 3 wants feature X or Y, so we code that feature for him and add that to the application.

But whenever there is an update to the code base (ie. a security fix in the core classes of the framework) all three customers should get an update of the base code!

What would be the best way of managing this sort of setup? Manually uploading all files using FTP is a pain, and it's not possible to merge code.

Using Git is perhaps a solution, but how would I go around and do it? Create separate repositories per customer? What if we grow to over one-hundred customers?

Any insight are welcome, including why we should or should not use such a setup. (but remember that we'll be the ones hosting the application for our customers)

Answer 1

I remember doing this years ago so you will have to take into account i'm now a little rusty at this.

I built a standalone framework, which combined all includes into ONE .php file. Any frameworks that used that, would do a PULL request and if the md5 of their framework matched the framework on the central server then no update was needed. Otherwise it would download the new framework over https and replace it's own copy. This created an automatic update system that was PULLED to all other apps that used it.

A major problem to this is, if you cause say a syntax error and you upload that to the central server, it will get pulled to all others and break them! You will be best to use a cron job to make the pull request that does NOT use the framework so the broken framework won't break it from doing a pull request to FIX the syntax error in the framework. This at least adds the ability to automatically fix itself as well once you fix the syntax error on the central server. However, having a staging server to test each update really is very important in this case.

That is only the basics of course as if you have say images that the framework uses they will also need to get pulled over, as well as any SQL updates and so forth.

You must regorisly test this before uploading to the central server in order to prevent mass errors! Not ideal! Unit testing, staging server, small and simple updates but more often (large updates have more potential to go wrong, and more to undo if it does go wrong) will all help mitigate the risk.

You will also have to structure the framework VERY VERY VERY VERY VERY well from the beginning to make it as flexible as possible when planning on having many different sites use it. If you design it wrong in the beginning it may be next to impossible to redesign further down the road. For example it may be wise to use PDO for database access, allowing all the applications the ability to use different databases while your classes etc will still no know how to interact with the database (regardless of if it's mysql or oracle), though, i would advise at least sticking to one if you can.

Design wise, you are best to look at other language frameworks and see how they do what they do. You must stick to good design principles, use design patterns only where applicable, and take note of MVC!

Further Reading...

• http://en.wikipedia.org/wiki/Software_design_pattern
• http://www.ipipan.gda.pl/~marek/objects/TOA/oobasics/oobasics.html
• http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
• http://www.phpframeworks.com/

This is no easy task, so be warned.

Answer 2

You mixed two separate different tasks in one question

• Development and support of diverged code
• Deploy of code from (any) SCM to live systems

Answer on 1-st question (for any modern) SCM is branching and merge branches (each customer have own branch, into which you merge needed parts from you single development-branch, or /better/ with "branch-per-task" you merge task-branch in all needed targets, avoiding cherry-picking)

Answer on 2-nd question is "Build-tools", which can interact with your SCM (you have to write more details later for more detailed answer)