I would use patterns like Façade, Mediator or Dependency Injection and design methodologies like interface-driven-design to attempt to abstract customer-specific functionality into decoupled classes or even assemblies.
One solution is to rebuild your solution into a specific binary per customer. The drawback of that is you essentially have to perform full regression testing on all the core code when making modifications for a particular customer. If you can get that abstraction to the assembly level (i.e. there's a core binary and customer binaries that are deployed together) you can decouple the customer functionality from the core functionality sufficiently to ensure interaction is kept to specific points and only need to test those interaction points. If you've already shipping a solution and you're just now thinking about customer-specific customizations, it's likely that would require a in- depth design change. On Wed, 5 Sep 2007 14:45:10 +0000, Paul Cowan <[EMAIL PROTECTED]> wrote: >Hi, >We are running into an increasing problem with our product which I could really do with some advice from someone of an experienced nature who has possibly come across this problem before. >The problem is this: > >We have a core product that 10 customers have bought. The problem is, each one of these customers has made changes that customise the product to their own need and has required meant that we have 10 branches of the code. > >As we get more customers then this will mean more branches of the code. > >Can anyone give me any advice of what is good practice for this type of problem? =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
