Link to home
Start Free TrialLog in
Avatar of Scott McDaniel (EE MVE )
Scott McDaniel (EE MVE )Flag for United States of America

asked on

Software versioning best practices

I'm working in VB.NET, and using BitBucket for offsite source code storage only at this point.

One of my projects is about to be released to a much larger audience, which will result in more requests for that utility. Each of those utilities has some form of customization - generally business rules type of thing, but often revisions that should be added to the "main" source. I would like suggestions or best practices regarding the correct way to create my new projects, based on the source, so that I can better manage updates, revisions, feature additions, etc.

I've read quite a bit about branches, forks and merges, but I'm not entirely sure how this would be handled, especially since some of the revisions should NOT be saved back to the main source code (i.e. the specific business rules), while other items (feature requests, bug fixes, etc) will almost certainly need to be saved back. I'm comfortable pulling down the project, and saving it back to the BitBucket server, but that's about the extent of my interaction.

One example scenario would be this:

I've created a utility for CompanyA, and have deployed that project as Version1. That project contains all of my common source code, along with a module to contain the specific business rules for CompanyA.

CompanyB buys the same utility, with requests for revisions for specific business rules. No major functionality changes to this.

CompanyC buys the same utility, but asks for a major feature integration (perhaps email capabilities), and they also need revisions for specific business rules.

In my current process, I have been copying the project over to a new directory and maintaining specific versions. This works, but as you can imagine this will become a huge mess very shortly (I only have 3 now, but there are many more coming down the pipe). I have to go back and update all 3 projects now for code fixes, and that's obviously not going to work.

So my goal is to better understand versioning and such in general, and GIT and BitBucket in specific. Can anyone help me with this?
Avatar of Jaime Olivares
Jaime Olivares
Flag of Peru image

My first hunch is that you need to design a good pluggable architecture, so you would write plugins instead of modifying your main codebase.  If you are working with .net, I suggest to read a bit about Microsoft Extensibility Framework (MEF)
Avatar of Scott McDaniel (EE MVE )

ASKER

Thanks for your input Jaime. MEF looks very capable, and it seems as if it's a good tool for something like this. Unfortunately I'm not able to implement something of this nature, since much of the codebase is provided by others, and I cannot change it - it must remain as-is, and I have to work around that. That will change as time moves on, but for now, MEF is not feasible.

I'm pretty well stuck with the methods I described above - using version control to maintain different versions with a common code base, where I build on that code base. My intent is to keep the original source "clean", while still allowing me the latitude needed to make changes and such for specific customers.

Is that doable? Seems like it should be, and that I should be able to "branch" off that source to create my own. I realize the main code base could change, and that could be catastrophic - but the code base hasn't changed in many years, and isn't about to any time soon. The company is rewriting the application, and when that happens I believe they're writing in the framework for more intelligent add-ins. But for now, I'm stuck with what I have.

Thanks again - any further suggestions?
SOLUTION
Avatar of Jaime Olivares
Jaime Olivares
Flag of Peru image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks again, your input is much appreciated.

So if i branch off the trunk a few times, and then I modify the trunk code, would that modification flow "upstream" to all my branches? Sorry if this sounds like a newbie question, but I am quite a newbie to using source code control for this sort of thing ...
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I've been reviewing a bit more about Branching and Forking, and from my reading it seems they are very similar, with the exception being a Fork is a distinct copy/clone of the main source. This seems to be a better fit for me, as I need to keep those customer-specific features distinct in each code base.

Are you familiar with Branches vs Forks? If so, could you provide any further information?

Thank you both very, very much for helping me to better understand this. This is an area of my knowledge that needs quite a bit of fleshing out, and you're helping tremendously with that!
Avatar of pepr
pepr

Forking (named that way say at GitHub) means cloning everything with read-only access -- including all branches.

Cloning your own repository to your own another repository is pretty the same, but you can also write back (commit to local repo and push to the remote one). In Git, you can limit cloning to a single branch. This way the local repo and the remote repository may finally look quite different.

So, in my opinion, you can think about many scenarios how to combine branches and clones (remote repositories). Your local branch may be the clone of a remote repository branch. This way, you may start limit your thinking to branches. The remote repositories will become local branches anyway.

If one branch is dedidated for implementing a single feature (or shared by all or some of the project specialised to the customers, or special for a single custome), each one project can have another branch that is a merge of several chosen "feature" branches.

I understand it it difficult to jump into the running train of the big project. Anyway, it is possible (with Git) simply separate chunks of related files with code and create separate git repositories. Then you can create another empty repository, add remote repositories for the related feature branches, and create another branch as the merge of local branches.

The good thing (in my opinion) with Git is, that you actually can start the wrong way (unintentionally badly designed branches and repositories), and you can still make it nice via later steps -- thing that is almost impossible (at least for me) to do with CVS or SVN). In other words, cloned or somehow derived Git repositories are easy to create, easy to transfer the important things to other repositories, easy to check whether you have the same thing at your repository, hence easy to decide that the wrongly designed Git repository was fully replaced elsewhere and can be thrown away.
Thanks for your detailed explanation. I'm using Mercurial instead of Git, although I did so simply because BitBucket defaulted to Mercurial. I'm reading up more on the details and differences between the two so that I can make a better decision. I'm not far enough into the project(s) to make any difference if I have to start over with Git instead of Mercurial, so any thoughts on the differences would be welcomed as well.

Sorry, I know this is somewhat vague and all over the place, but I'm still in the "feeling the walls in the dark, looking for the light switch" stage with my knowledge of version control and such.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Sorry for my delay in closing this. I've been buried with projects.

I did learn quite a bit about versioning, and the best way to use the various tools. I've awarded points to most of your comments, as they have definitely helped me to better understand and use those tools.