This project has moved. For the latest updates, please go here.

Code Organization

Apr 15, 2014 at 5:02 AM
Hi

Have joined a company newly and the team has developed one application in ASP.NET planned for one entity.

Now this application has been rolled out to 5 other group entities and our team have created 5 databases, and 5 copies of the source for all these entities. There are difference in some of the features.

Currently we make changes in one code base , do the build and realease /deployment.

Now we are planning to use TFS. We have the trial version of TFS.

My question is how do I structure my code in Source Safe.

1) We want to have one code base with options to have specific exclusive code(feature) for some entities.
2) We must be able to develop new features and release it to say Company A, Company C and Company D.
3) We must be able to make a build and deploy the same with very less effort.
4) Any Bug fixed must be one time fix across entities.

Example
Company A may have feature 1,2,3,4
Company B may have 1,2,4,5
Company C may have 1,2,3,7

Added to this there is virtually no documentation available. Every thing is in the Head ;) / Human memory.

Would Appreciate if some one has encountered the same problem and resolved it.
I was directed to this discussion fourm.

I guess some one would have solved this problem using branching.

Would Appreciate some help / suggestion.

Best Regards
Vadhi
Apr 15, 2014 at 12:50 PM
The burden on your team is proportional to the complexity of the your source management scheme.

I'm sure someone has solved this with branching. That does not mean that branching is the best way to solve this. If you maintain different branches for each customer, it will be complex.

The simplest model would be to maintain one set of source code for all customers, and design it to be modular so you can enable/disable be either deploying different modules or using feature switches to enable/disable features.

Probably the most important question is "Why is there "virtually no documentation available?" Devising a complex branching scheme in an environment where people won't even document the customer's products in an orderly fashion is unlikely to make things turn out well. And the root cause of problems will not be a poor branching plan. Your problem will be the answer to that question. I suggest you discuss that with your team first and be realistic about what you find.
Apr 16, 2014 at 5:42 AM
Hi

Thanks for your reply.

Now we are putting in place mechanism to document the application.
This application is for a Brick and Morter company Whish is into fabrication.
This application has a history of development and no doumentation in the past.

I too think that Branching per say may not be needed but we must alter our code to expose some unique features to certain entities.
Having done that we will have one code base that caters to all 5 entities.

Best Regards
Vadhi
Apr 16, 2014 at 2:19 PM
It sounds like you are introducing many useful improvements there. I think you will be glad once you have that common code base.

There are many ways to achieve the flexibility you need between different customers. Martin Fowler has a nice article on feature toggles and the various ways they are used. http://martinfowler.com/bliki/FeatureToggle.html. His reference to "business toggles" seems relevant to you. His article is light reading and very useful.

There are some really heavy concepts out there like software product lines. But at their root, all these are different ways to make software configurable so you can build in the known variations and switch them dynamically at build, delivery, or runtime, without having to change the code for each situation. If you think about existing products like SAP, PeopleSoft, and Oracle EBS, they have all been built on a similar idea.

While your customers must compromise by giving up personalized software packages, they get in return, a flexible product that is affordable. Most customers cannot afford to pay you what it would take to personally code all their variations. Either they pay too much or you get paid too little and you can't sustain your business.

I would love to know what configuration approach you finally choose to fit your unique situation. Feel free to share that when your design settles down. I would enjoy hearing from you and others would benefit from your journey.