Results 1 to 2 of 2
May 22, 2009, 06:40 #1
- Join Date
- May 2009
- 0 Post(s)
- 0 Thread(s)
Architecture for site with different features for multiple clients
I can of course just branch the codebase for each client, but it becomes a pain to try to merge features from one client to the some or all of the others. It takes time to merge the relevant code, merging is really boring, plus it can be hard to find the right time to do the merge.
As the number of clients increases, the complexity seems to go up exponentially. :-(
I could divide the codebase into code that is the same for all clients, and code that is different, but where to draw the line? As soon as I do, there will no doubt be a requirement to change code in the former for a particular client. And for clients that are very similar, there will be a lot of duplicate code, which is bad.
Is there a ‘best practice’ technique to use in this case? I haven't been able to find one (and i've Googled it a LOT). Surely this is a common problem??
The strategy I’m thinking of is having:
- A generic non-client-specific codebase (let’s call the first version G 1.0), with it’s own test/release cycle
- A codebase for each client (Ca, Cb, Cc, Cd, etc.), which contains just those of the generic files that are DIFFERENT for that client, plus any files that are unique to that client.
To build the site for client 'Ca', I would just pull all of the generic codebase from source control, then pull the codebase for Ca on top of that, possibly overwriting some files.
I can then add a feature to Ca, by adding a new file, or copying an existing file from the generic codebase, adding it to the Ca codebase, and changing it.
Once that feature is tested and released to the Ca site, I can manually merge that change into the generic codebase for release in G 1.1. When Cb, Cc, etc. are upgraded to use G 1.1, they will get that feature ‘for free’. The feature could be configurable on/off in the generic codebase if only some clients will want it. (If the feature was only likely to be of use to Ca, there’s no need to add it to the generic codebase).
* As the number of clients increases, the merge complexity remains manageable, with reduced duplicate code. The merge complexity seems more like N than N-squared, i.e. NOT exponential.
* Technique is easy to implement and try out. If it doesn’t work out, I can easily change back to having a separate codebase for each client.
* The major disadvantage seems to be the extra test/release cycle for the generic codebase.
* The more files in a client's codebase, the more merging work involved in updating it to use a new release of the generic codebase
* When checking in code, I’ll need to make sure I check it into the right codebase.
Any comments, suggestions, pointers?
A possible enchancement to the above technique… Some of my code is object-oriented. For this code, instead of overwriting the entire file in Ca, I could create a sub-class of the generic class, and just override the relevant methods. So duplication of code would be eliminated. Well, almost :-)
May 22, 2009, 07:21 #2
- Join Date
- Sep 2005
- Ukraine, Nikolaev
- 0 Post(s)
- 0 Thread(s)
I think, your approach is OK. Actually, it's normal development approach when you use some framework. Framework files remain unchanged, you only add extensions, subclasses, change configs, add behaviours to extend it's functionality.
If you host them on the same server, they may use the same core files. I have lots of project and 90% of them uses the same framework (I'm from PHP world, I use Yii), framework is not copied.
The only thing I'd like to note - Keeping everything in one or two JS files during development is a bad idea. Keep everything separated and easy to maintain. Use JS minify tools to build resulting code for production.IQ RIA - Delivering smart web-applications
High-quality PHP, Yii, Ruby on Rails, ExtJS, Backbone, EmberJS and jQuery consulting.
Dashboards, HTML5 and CRM development.
Request a quote now!