My First Blog Video – Intro to Branching
"Hi. My name is Jeff Fattic. In this first video of my ALM with TFS series, I’m going to discuss branching. This demonstration is being recorded using the Visual Studio 2010 Beta 2 VPC which can be downloaded from MSDN.
Branching is an extremely beneficial feature of software configuration management systems. The primary benefit is enabling parallel development efforts through isolation. I think organizations using TFS are often intimidated by the idea of parallel efforts, so I wanted to create this video to at least address the ease of creating a branch in TFS.
I will be using the Source Control Explorer window for the majority of this demonstration. In my example scenario, the folder labeled MAIN is where the initial solution was added to source control. In my branching strategy (of which there are several), MAIN is the most stable version of the application. No active development is allowed in MAIN and it is highly protected by quality gates like a nightly build that executes a suite of automated unit tests. Some teams will opt to apply other quality gates and set security on this folder.
Above MAIN, notice the folder named Dev1. Two of my developers are completing work on another feature that will be released to QA shortly. I don’t want to start coding my feature and potentially put their code in an incomplete or unstable state. Therefore I am going to create a new development branch for two other developers and myself to work in.
First, I’ll right-click MAIN and select “Branching and Merging” and then “Branch…”. The Branch from MAIN dialog window appears. Notice the textbox labeled “Source Branch Name:” is prepopulated with the server location of the MAIN folder. I’m then presented with the option to branch from a particular version such as a particular date. In this case, however, I’m going to select “Latest Version”. Next, it requires I specify a target branch location. I want this branch to be another development branch so I will put it parallel to Dev1 by entering “$/TailspinToys/Dev/Dev2”. Finally, I can enter a description and then click “Branch”.
Notice the new icon representing branched folders. A somewhat hidden new feature of TFS 2010 is the branch properties window. Go to the properties window by right-clicking the folder and selecting Properties… from the context menu. From here you can define an owner or elaborate on the description. You can also visualize the parent and child branches directly related to the selected branch. Finally, you can also set security – say to prevent Team A from accidentally using the new dev branch.
I’ve now created what amounts to a snapshot copy of the contents of MAIN. This allows my team add new features or resolve bugs without stepping on each other. Merging branches, which I’ll cover in a future post, allow me to sync changes between branches with a lot of control.
Like branching strategies, there are several ways to organize your physical folders as well, but I think this is the most flexible. The first decision I usually have to defend is the generic naming of my development branches, however I’m a big believer in reusing development branches. Feature development ends when it is released to production (the release branch). This frees up my branch to be used by another feature. After all, it has been reverse-integrated with MAIN on its way down to a release branch. I know others often archive branches, but I’ve never seen anyone pull from them. They are quickly outdated and the last version of that branch should be retrievable by getting the specific changeset created when it was reverse-integrated to MAIN.
Recommended branching strategies can be found on CodePlex at http://tfsbranchingguideii.codeplex.com/. I strongly agree with the guidance that organizations should begin with the Basic Branching Strategy. It can be difficult to dive into something that is too complex and end up with unused or frequently outdated branches. It’s also strange that so many organizations I’ve worked with think there systems require something way more customized and complex. Usually this indicates problems elsewhere (poorly organized solutions and/or overly coupled architecture) and branching won’t really resolve them although it might hide them for a brief time.
My name is Jeff Fattic and thanks for watching my video. Look for more details on branching and other cool features in Visual Studio 2010."