Source Code and Building Full Version and Interim QA Release

spatterson · Post by **spatterson** » Thu Nov 08, 2007 3:43 pm

I have an application directory that up until now, I have copied all of the directory contents forward to a new directory for the next version of the application. This has worked fine in the past due to the low volume of changes that two developers and two QA persons can do. Now, move forward in time and add two developers and more QA and I find the application being worked on faster and objects changing to where we want to be able to get some items to QA sooner rather than later so that they can look at them before the release date.

So, I was thinking about using a directory where all development was done and then creating other directories where I would promote changes to. So, if I am working on a piece of code and someone else works on a report and they get the report done, they can promote this to the appropriate build directory and do a build so that QA can take a look at it. I also need to be able to do interim builds incase of bugs or maintenance releases that come up between the last full version release and when the next full version release is scheduled for.

Example on what I would like:
$/DevCode/
$/BuildCode Ver 1.0/
$/BuildCode Ver 2.0/
$/BuildCode Ver 3.0/

Current
$/App Ver 1.0/
$/App Ver 1.1/
$/App Ver 1.2/
$/App Ver 1.3/
$/App Ver 2.0/
$/App Ver 2.1/

Is the only way to promote something from the Dev area to copy it at the file system, check out the file from the Build area, overwrite the file with the one that you changed, and then check it back in the Build area?

Now, in Visual Source Safe, I was able to build a utility to do my promotions for me which would do this exact functionality behind the scene, and do my labeling according to the version of the file. Has anyone built a utility like this, or is there some functionality that is similar in Vault that I am missing?

Thanks,
Scott

Beth · Post by **Beth** » Thu Nov 08, 2007 3:49 pm

Branching is what you are going to want to use here. We have a few articles that will give you what you want from that.

<a href=http://support.sourcegear.com/viewtopic.php?t=193> Best Practices for Managing Branches</A>
<a href=http://support.sourcegear.com/viewtopic.php?t=9>Basics of using Label, Cloak, Share, Pin, Branch and Merging </A>
<a href=http://support.sourcegear.com/viewtopic.php?t=15> How to label as part of a build script </A>

Also, you will want to make liberal use of labels.

spatterson · Post by **spatterson** » Thu Nov 08, 2007 4:18 pm

Thanks for the quick response, I think I might have read these already and tried to play with them.

In the first example, I want to be able to create my 2.0 early on in my release cycle so that I can create interim releases that contain functionality that I want the QA department to look at before the end of the release cycle. This says to wait until all of the work is done on the 2.0 version and then create a branch of the code. Now, what I didn’t try was to create a branch that was 2.0 and change something in the DEV directory and merge into the 2.0 directory. Is that a possibility?

Second option has a lot of stuff in it that we need to test out and see if we can put a process in place using those tricks to get what we want.

Scott

Beth · Post by **Beth** » Thu Nov 08, 2007 4:25 pm

Is that a possibility?

It is, but it's a bad idea.

What I would suggest is that when you have a point that you will build and send it to QA, I would suggest labeling at the folder level. Then you can perform a Get on that label at any time and build it. If something needs to be fixed, you can return to that, make the fix, promote the label and build again.

Another possibility is to make the branch and have the developers work in the branch for 2.0, and when you are ready to merge back to trunk for QA to look, then merge and label and have QA look at a build from the truck. The merge doesn't destroy the branch so your developers can keep going. Doing it this way though, you will have a lot of merging happening.

spatterson · Post by **spatterson** » Thu Nov 08, 2007 4:34 pm

OK, we’ve been testing and playing and it seems like the merge from Dev to the build director does work, why is that a bad idea to use? Is that like crossing the streams in Ghost Busters, or worse?

Scott

Beth · Post by **Beth** » Thu Nov 08, 2007 4:41 pm

What I'm thinking is that you might want to merge back and that will get confusing. I would say you should try to keep the merging in one direction. It will work regardless of what you do, but you can get yourself turned around and have changes flying everywhere and there will be "cats and dogs living together. Mass hysteria."

EDIT: I guess I had better quote that.