Just a general question I would love some opinions on. How do you all manage having products "out there" in different flavors and versions as well as a version under development?

Basically I am trying to figure out a better way to have a given version of a given program preserved while I move on with development. For instance, I publish and distribute a version of an application, lets call this version 1. To support version 1's userbase I need to have a copy of that code, database, and other pieces that make up my application so I can debug here if necessary. Now I have version 1.5 in development that has some simple, and some not so simple changes to all the assets of version 1. See where I am going. It was easy in VFP, (inzip your application folder and you were good to go), with .NET, SF, DDT, BO projects, security projects, version control, etc I am just not sure what is the best way to go as we start having some more stuff out there in he world in different flavors and versions to support.

This is probably something some of you take for granted and I would appreciate your opinions. I have several products now that I have to maintain the environment described above.

Keith Chisarik

Well, there is only one way to do this successfully, and that is creating branches.  Whenever we release a version of our software into the field, we create a branch within Team Foundation.  Then we continue to develop on the current branch.  If something comes up that needs to be fixed on the current version in teh field (or an older one) we will download that branched version from source control, fix the changes, and then either post a patch or create a new build.  Our build process even has the ability to take the branch into account so we can tell the build to either use the current version (default) or select a previous branched version.  We have to add the branch to our build process with each branch, but in a crunch we can get back to ground zero.  We even copy our DDT packages to a "previous builds" folder so in the advent of structures changes, etc. we will still be good (learned this one the hard way ). 

What's cool about this is that if I had to make a change on one version (branch) that will need to be made in the current branch, I can merge the branches or even just a single class or file from the branch so that all versions will have the fix.  There is a lot of logic here that is really nice.

But here is the downside...you will need a version control software other than VSS.  We use Team Foundation, but others out there such as SourceGear Vault (http://www.sourcegear.com/vault/index.html) that have this functionality as well.  If you will refer to the training guide when you were here, in section 4.2.2 (Team Environment Software and Selection) you will get some more details on some of the options out there.

Well I can offer some of the solution: source code control. I use Subversion, but team foundation has source control, and there are a gazillion others out there. For this I'd say you need a few features for sure though. You need to be able to tag versions, you need branches and merging is very nice.



Currently, I'm in your very situation. I have a version in production, a version that has some fixes to that version being tested, the next version that is in pieces now, a version that is based on the main app, but with a bunch of functionality removed and a different way of connecting to the database and a version that is a risky overhaul to some critical functionality that I don't want to impede the progress of the app if it doesn't work/takes a while to finish. Here's how I do it.



The "trunk" of my source tree contains the next version (always) and is the main development line. This contains all of the code related to the project: .net source, sql scripts (or could be DDT packages), documentation, help, setup projects/scripts (the tools to make setup programs)...every thing that is needed to develop and deploy the application. Typically I don't check in the actual setup programs or any of the actual exe or dll files...anything that gets created from source is not in source control.



When I'm getting close to releasing, I create a release branch by copying the entire source tree from trunk. This then becomes a release candidate, which then become the production branch, which is were I'd fix my production code. When I release to production (any time I release to production) I'll also tag that branch (in subversion that is just copying the tree to a new folder), so I can always get to the exact code that is in production. Subversion uses a folder approach, so my structure looks something like:







So, current development happens in trunk. I do fixes to production code in /branches/REL-3.0.4. When I release, I'll tag it under /tags and it would become /tags/REL-3.0.4.10.



Then I do risky stuff under branches also. Currently, I'm reworking my search functionality, so my tree also has a branch for that:







How this works is that I check out the code to my local hd, in order to do development. Once I've released a new version into production, I just delete that code off my HD (it's in source control), create the branch for the new production version and check out that version, so my hard drive stays clean. Also, the source tree gets backed up on the server religiously.



Now, there are other things to consider, which I sort have figured out.



- SQL updates. You have to have some way to reliably update the db from almost any version to any other version. The DDT was designed for this. I don't use it much though, just for my security db. I check in the packages it creates. I prefer to use SQL scripts and use a tool called DbGhost. In this case, my SQL scripts are my source, so that is what is checked in (creation scripts...no update scripts at all).



- Assembly versions. This is still a bit of a mystery to me. However, I know it's important



- SF version. This one can be nasty. If you upgrade SF from one version to the next, on your development machine, the SF assemblies are in the GAC. Which means that if you want to use the newest version of SF for trunk or an experiment, but not in the production fix (uses an older version), it can get tricky. I'm not sure how to handle this at all. It may mean that the SF dlls need to be checked in also, which would allow proper deployment, but not solve the development issue. Fortunately, this hasn't been a problem as I'm almost always willing to just move all versions to the latest SF version and when I'm not, it usually isn't too long before I can get back on track.



That was a long post! I hope it was a helpful start!

I forgot my last requirement, it needs to be cheap/free

But seriously, as always thanks for the great posts, Ill be checking out my options soon.

Keith Chisarik

Hey Keith.

Sourcegear Vault is free for 1 user.

Subversion is open source and free...for as many users as you need. I'm using it with apache, remotely. Not the easiest to get working, but doable. Once it is setup, I've had not problems at all. Works great.

Here's my penny and a quarter (inflation has taken it's toll on the value of two cents  ):

http://www.visualsvn.com/server/

Any of these will take some energy to implement, but just be sure that you are on a solid platform and doing something that is reliable.  Greg has been using Subversion for a while now so I am sure that he has gone through most of the heartache, so if he recommends it, then I am sure it would be a good fit since it is free

I hadn't realized that VisualSVN had a server package. Nice. I use VisualSVN for integration within Visual Studio and it works great.

Man that looks REAL appealing... I found a nice video on their site.

http://www.visualsvn.com/visualsvn/demo/

Looks like I might FINALLY be able to kick VSS to the curb!!!

Keith Chisarik