Managing Multiple Versions?

April 16, 2013 2:29 PM

I'm looking for best-practices for managing multiple versions of the same C# code which are *almost* the same, but not quite.

I'm not familiar with version control software at all, but what I've read is that revision control software does the opposite of what I'm trying to do. I'm not trying to consolidate changes into a single current master version; I'm trying to manage multiple, similar "forks" of the same program, so that if a major change to the underlying code that applies to all versions it can be handled cleanly, but still keep each version distinct.

A few more details: We sell a software package that allows custom data entry forms with all sorts of fun C# under the hood; my job is to develop these custom data-entry DLLs for the customers that buy the software package through us. All the customers are in the same industry, so I can reuse a lot of my code, but each one has some specific needs that have to be addressed.

So, I made code for one customer's specifications and everything worked great. The second customer needed a couple tweaks off of what the first one had, so now I have two good versions. Now Customer #3 splits the difference, putting back in things #1 needed that #2 didn't, but uses one of #2's features and then tosses in its own custom needs. I've consolidated as much as I can to reduce the amount of places things need to be changed, but, say, a field is added or changed from a text box to a dropdown box, there might be ten places that need a data type changed. But, now let's say I find a bug that affects the 90% of identical code -- but I've got three different sets of source code now to update each one the same way, and I can see down the road when I've got 10 customers things are going to get hairy. I'm also making things less complicated by doing 'dirty' things like just hiding, rather than removing, orphan fields, or re-using fields without changing names, which are only going to make things worse in the long run.

So, how do programmers manage having multiple parallel versions of the "same" software, to ensure that everyone stays up to date? Is this something that Git or Subversion actually does but I don't understand it well enough?

posted by AzraelBrown to Technology (9 answers total)

Best answer: With svn, you could have branches 1..n for your project, which split off the trunk. Branch i can check its core changes into the trunk. Repositories of branches 1..i-1 and i+1..n can merge core changes to the trunk into their respective branches. The core code in this case would be constitutive code that can be reused with all "sub"-projects. You would want to coordinate this, perhaps by enforcing daily updates that get everyone on the same page.
posted by Blazecock Pileon at 2:36 PM on April 16, 2013

Best answer: Very briefly, yes, version control software can do this. You will have a master branch and then branches for each customer. You can push/pull commits between branches. In the situation you outline above you will have to do some careful merging, as you may have conflicts that need review.

I haven't done a lot of heavy workflow like this, but it's a common issue that you should be able to find documentation on. The Git book might be a good place to start - here's their chapter on branching workflow.
posted by expialidocious at 2:41 PM on April 16, 2013

Best answer: Version control means keeping your versions under control. If you have many versions, you need a lot of control! If you are not currently using a VCS like Subversion, you should make adopting one a top priority. Aside from managing your current version(s), a VCS will give you 100% accurate history for your software, it will give you very useful tools to develop cooperatively, and will give you a single clean location to do backups of. Which you're already doing, right?

In general the problem you are describing -- having several customers with unique requirements for the same underlying product -- is complex enough that managing this complexity can make or break a small software business. There are two standard techniques to apply here. Technique #1 is what Blazecock and expialidocious are talking about, where you version control releases for the various customers and use the VCS tools to patch changes from place to place in the VCS. Technique #2 is to modularize your software. Different programming cultures use different terminology here, but the basic idea is the same for all languages. Ideally you would have a single version of your total package of features, and then you would have customer-specific configurations. In other words, keep your common code common, and keep the customer-specific stuff minimal and isolated.

Reorganizing your code in modules might sound difficult, but if you have everything under version control, you can just go nuts! If you break things, you can just use the version controlled history to unbreak them. :)
posted by mindsound at 3:05 PM on April 16, 2013 [4 favorites]

Both my suggestions require that you consolidate your code. IMO that is required to meet your requirements of "[ensuring] that everyone stays up to date", . All the suggestions about source control are good and ultimately the best. However, I have managed similar issues in the past.

I have either

1) Use the consolidated code and have the 'tweaks' embedded inside conditional compiles
#if (CUST!)
blah1()
#else
blah2()
#endif

or

2) Use the consolidated code and have the 'tweaks' embedded inside variable, so they have the same compiled code

if(_customer1_hack){
do_cust1();
}else if (_customer2_hack){
do_cust2();
}else{
....
}
posted by njk at 3:07 PM on April 16, 2013

One thing to think about is trying to structure your code such that you can move as much of the 90%-identical code as possible out into a library that you can include in your various customer-specific programs. That way most of your bugfixes, etc., can be made in one place. You may also be able to move some of the customer-specific differences out of the code and into separate configuration files. (I'm speaking in generalities here because I don't know much about C# or your runtime)

In any case, whether or not you do the fancy branching and merging as discussed above, version control systems are your friend! I can't imagine writing code without one!

(on preview, what mindsound said!)
posted by sriracha at 3:09 PM on April 16, 2013

Best answer: If you are doing software development, you need version control software. Even if you are the only developer, and you never want to branch, and you back up your filesystem every night, and you are only ever going to release once... version control is still a Good Thing.

That said, in the past 3 years I have been on two teams which switched from SVN to Git. Each time, the team operated much, much better after making the switch. I highly recommend Git.

Also, I will second the idea of refactoring your code, especially if you ever are going to support these customers or sell them upgrades. Moving common functionality into a core library is a good idea, you could also consider using OO design (since UI frameworks seem to be one of the areas where class hierarchies are an OK idea).
posted by rustcrumb at 6:47 PM on April 16, 2013 [1 favorite]

thirding sriracha and mindsound on 'modularization'...to go further, you need to look at software patterns that encourage reusability by encapsulating things-that-change. SCC is a critical element of a project. I won't work without it. But you need OOP and design patterns. More crudely, if you have to fork to gain software reuse, you're doing it wrong.
posted by j_curiouser at 10:27 PM on April 16, 2013 [1 favorite]

Response by poster: Thanks all -- Yes, I've modularized/consolidated as much as I can already, but the kinds of objects from the SDK limits me a bit with how far I can push it. Like in my example above, one customer wants a textbox, the other wants a dropdown box -- outwardly, not much different, but when my code needs to read from and write to data contained, there's two entirely different methods of interacting with those two objects that even a "if cust1 then...if cust2 then..." won't solve. Part of that is the odd way the SDK handles things, which I don't have control over unless I want to rewrite my own structure of objects and do translation (which, of course, I do not).

I will look deeper into revision control software -- the suggestions above are still somewhat greek to me, but expialidocious' link looks like it might put me on track. Thanks much!
posted by AzraelBrown at 6:15 AM on April 17, 2013

What you need to implement is a Model-View-Controller. Your model (business logic) and Controller (mediator) can stay consistent. You can interchange Views for your separate customers.

This won't make sense if you do not have separation of responsibilities. Most beginner WinForms apps, as a counter-example, utilize an autonomous View - all UI *and* business logic are implemented in the body of a Form. This is bad.

Isolate (encapsulate) business logic in a separate library that is fully reusable between customers. Then create customer-specific Views (or a single View that is configurable per customer).

I think you do yourself a disservice by trying to solve this OOP design problem in an SCC solution space.

The question is not, "How can I manage lots of copies of stuff?"

The question is, "How can I build flexible applications without copying stuff at all?"
posted by j_curiouser at 3:06 PM on April 17, 2013 [1 favorite]