Page 1 of 1

Managing a multi-site codebase

Posted: Tue Sep 06, 2011 7:51 am
by MonkeyMeister
Good afternoon all,

My first post here, it's great to see a heavily active PHP dedicated community, so I am excited to get involved.

For my first post, I would like to open a discussion with fellow developers, as to how they would tackle the situation we are in, and how best to go about managing a rapidly expanding codebase. This topic has created quite some heated debate within our company, and it would be great to have some outside opinion. I'll explain our situation first:

We're in the process of building a brand new, custom insurance quotation website for an international insurance broker. We have three RHEL dedicated servers with Rackspace (who, if anyone is interested, we could not recommend highly enough - they are simply the best), a development server in the UK, a production server in the UK and a production server in Sydney, Australia. We began developing the website from scratch, which was a new insurance website for Australian clients. It was written in PHP with a MySQL server storing the customer / policy and scheme data. Before the site was completed, the insurance company also required two further sites, a similar site catering for UK clients, and one providing sickness and accident cover. We subsequently took the codebase for the Australian site and copied it into two other virtual hosts, creating 3 completely separate running instances of that software, each with their own branding. We then continued to develop on the original Australian instance, whilst once or twice a week updating the other sites to reflect recent changes to the Australian one.

The company then requested a further 2 more sites, using the same software, but being branded differently. Suddenly, we had 5 separate versions of the software to maintain, and now these newer sites required some functionality changes, which would need to be specific to that particular site. Now, 3 sites operate using the same codebase and 2 sites operate using a slightly modified codebase. Now that the projects are drawing to a close, during testing, bugs are coming to light, and having to fix the bugs across the 5 different sites is a logistical nightmare.

Each site has the following codebase:

/admin/ - same across all sites
/css/ - different for each project, provides styling changes for each site
/downloads/ - same for each site
/files/ - same for each site
/images/ - different for each site
/includes/ - same for each site
/script/ - different for each site
/templates/ - different for each site (this contains the design, layout and content)

So ideally, we'd like all the folders that are the same for each site (i.e the actual software powering the website) to fetch from a single repository on the server that that virtualhost sits upon, and the rest (design-related stuff mainly) to come from the virtualhost that the site sits in.

Adding to this complication is the fact that one of our servers is in Australia and one in the UK. All I can think is that we have a single repo on our UK site and push new versions to that, and automatically server-to-server mirror that repo accross to the Australian server, to power to 2 or 3 sites over there.

Ideally, we would want to merge all 6 databases into a single database too, so presumably we'd have to implement some form of real-time MySQL mirroring where both servers act as masters? Not even sure if that is possible.

What do you think guys? Are we being a little ambitious? Are we going down the right path?

Your comments, opinions and criticisms are welcomed with open arms.

Many thanks,

MonkeyMeister

Re: Managing a multi-site codebase

Posted: Tue Sep 06, 2011 11:42 pm
by nowaydown1
Greetings, and welcome to the forum. I think your question was fairly wide in scope so I'll try to touch on a few different points here: Let me begin by offering the unpopular solution: Don't cater to your customer's requests for tailored functionality. It has been my experience that the more you cater to that mindset, the more your code-bases will diverge. While I can certainly understand the desire from a fiscal and customer satisfaction standpoint, unless you have a good amount of manpower to maintain these forks, you more often than not wind up shooting yourself in the foot. Eventually your branches diverge so much that your product suffers as you try to provide support across many branches. Quality suffers, customers lose confidence in your offering, and things go badly for both parties. It also becomes messy quickly when it comes to things like back-porting security fixes and the like.

The alternative suggestion I would make is to listen to your customers requests, and when you get enough of them, look for the common ground. Build features that put flexibility in the hands of your customers, but gets you off the hook for maintaining different code bases. For example, maybe customer 1 comes to you and says "We really have to be able to use our existing LDAP service for authentication". Customer 2 comes to you and says "Gee, we really like the product, but the fact that we can't use our existing website accounts for authentication is a deal breaker for us". Both these customers want different functionality. In this case, start thinking about a service oriented architecture. Build a web service that ties into your application's authentication system. Write a specification around it and let your customers bear the burden of how to interface with it. "Oh you want to authenticate against LDAP? We have an authentication service, no problem. Here's the documentation for it.". Some organizations won't have the technical expertise in-house to follow this model. This is another opportunity for you to monetize, without compromising your "no changes to core" policy.

You outlined a directory structure. I'm working off the assumption that you guys are using some kind of source control product (SVN, Git). I would restructure this a little bit and get all the customer specific branding into a theme directory or some other kind of container. Then you could setup exclusions (ignore everything in /theme) on these directories so they are not kept as part of your product's code base. You could have two repositories, your application code, and your customer specific branding. On customer install, you pull down your latest stable of your core product, and checkout the customer specific branding. By default, maybe your /theme directory contains your default look and feel.

I can't really speak to the database points you mentioned. Hope the above helps your group discussion points.