By Keith Chisarik - 10/15/2008
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.
|
By Trent L. Taylor - 10/15/2008
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.
|
By Greg McGuffey - 10/15/2008
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:
/branches
/REL-3.0.4
/NetCode
/SqlScripts
/SetupScripts
/Docs
/tags
/REL-3.0.4.9
/NetCode
/SqlScripts
/SetupScripts
/Docs
/trunk
/NetCode
/SqlScripts
/SetupScripts
/Docs
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:
/branches
/TRY-gpm-Searches
/NetCode
/SqlScripts
/SetupScripts
/Docs
/REL-3.0.4
/NetCode
/SqlScripts
/SetupScripts
/Docs
/tags
/REL-3.0.4.9
/NetCode
/SqlScripts
/SetupScripts
/Docs
/trunk
/NetCode
/SqlScripts
/SetupScripts
/Docs
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!
|
By Keith Chisarik - 10/15/2008
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.
|
By Ivan George Borges - 10/15/2008
Hey Keith.Sourcegear Vault is free for 1 user.
|
By Greg McGuffey - 10/15/2008
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.
|
By Bill Cunnien - 10/16/2008
Here's my penny and a quarter (inflation has taken it's toll on the value of two cents ):http://www.visualsvn.com/server/
|
By Trent L. Taylor - 10/16/2008
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 
|
By Greg McGuffey - 10/16/2008
I hadn't realized that VisualSVN had a server package. Nice. I use VisualSVN for integration within Visual Studio and it works great.
|
By Keith Chisarik - 10/16/2008
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!!!
|
By Bill Cunnien - 10/16/2008
"Setup source control in 7 minutes"Yeah, right! Don't believe it! It took me nearly 10 minutes!! 
|
By Trent L. Taylor - 10/16/2008
Cool 
|
By Greg McGuffey - 10/16/2008
Looks like I might FINALLY be able to kick VSS to the curb!!!
A happy day indeed!
Let me know if you have any problems or questions.
|
By Keith Chisarik - 10/17/2008
Just a final thanks, I am up and running and have my biggest current project ripped out of VSS and into subversion with three developers working on the trunk and a BRANCH for my current production version... awesome!I love the flexibility of the product too, many more features than I ever had with VSS, I scared some of my guys when I showed the them "Blame" button
|
By Trent L. Taylor - 10/17/2008
That is an important button...and there is no arguing about who screwed something up! (it just sucks when it proves that you (meaning me) screwed it up )
|
By Ivan George Borges - 10/17/2008
Hey guys, I have been using the Vault tool for a while, but after the links posted here about the VisualSVN client and server I just thought it would be worth setting up a test.I had tried SVN a year ago or so, and for me it was such a pain to set the server and then working with it, etc., that I just went to Vault. This VisualSVN Server solved it, it is amazing. Then I installed the Client and here goes some impressions: - The integration with VS has been working fine. To be honest, VS seems to be working a lot faster.
- I like the Update process better, making it easy to work offline with the notebook when needed. New files added to the solution while offline are found a lot easier then with Vault.
- The price is good, US$49.00 each seat. There is a discount policy apparently for quantities. Vault is something near US$200.00.
- It is a file system based source control, so there has been some need to create command line batch files using svnadmin to produce backups, Vault is based on SQL Server, but no big deal.
So, so far so good.
|
By Edhy Rijo - 10/17/2008
Hummm, guess it is time to move to VisualSVN, I did a quick look at the demo video and I liked what I saw too. Still need to digest Greg's long post about branches, man, too many things too fast .
|
|