SitePoint Sponsor

User Tag List

Results 1 to 2 of 2
  1. #1
    SitePoint Member
    Join Date
    May 2009
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Architecture for site with different features for multiple clients

    I develop a site for a number of clients (ASP.NET, C#, Javascript). Each client’s site has differences from the others, some small differences, some big. I can easily have a different ‘skin’ (CSS, images) for each site, but it gets more complicated when I have different code/features between the sites.

    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).


    Advantages

    * 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.


    Disadvantages

    * 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

    * One single source file could be quite large, say a Javascript file, and to change one line for Ca I would have to copy the whole file and change one line, which increases the merge work required if I have to adapt Ca to support a new release of the generic codebase.(I can break large files into small files, but I don’t want there to be TOO many requests to the server for individual JS files.)

    * 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 :-)

  2. #2
    SitePoint Addict KJedi's Avatar
    Join Date
    Sep 2005
    Location
    Ukraine, Nikolaev
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    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!


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •