Migrating from VSS to TFS

Beware!!! This is not a technical article about how to migrate VSS to TFS.
This is a story about my experience of migrating to TFS.

When we first met with TFS we were using Visual Source Safe 6.0.

Advisors from Microsoft came and introduced the brand new source version control system of Mirosoft, TFS. Future of the source version controls was TFS. Moreover TFS was not just another source version control system. We could even use TFS to manage projects instead of our own project management system. It also had the shelve option when you are leaving work at night. TFS brought everything we needed. They urged us to migrate to TFS because Microsoft itself was migrating to TFS. Because it was newer and better, we should quit VSS and use TFS instead.

One of my colleagues, Yakup, also told us that he used TFS in his previous company. They were pleased with its incremental get ability. For larger projects it was an ache in the stomach to get the latest version of your project in the morning. VSS was checking every file and calculating checksums in order to decide if they were the latest versions. It was taking too much time. TFS was keeping history of your workspace to decide if you have the latest version or not. It was much faster than VSS to get the latest version of a project.

As a punishment to his act of recommending TFS to us, Yakup was chosen to install TFS :-)

After a humble installation (on a poor virtual machine) we started using TFS. Its performance was satisfying. Our project managers investigated project management aspects of TFS but they were not satisfied with them because TFS was not able to keep how much time we spent for each task/bug. They had to report to higher administration of how much a project costed in terms of our salaries :-)

Still we decided to use TFS because of a few reasons. Microsoft advised us to use it, it was new, software companies were going to use it and we did not want to be backwards amongst others, and TFS had the ability of incremental get.

We had two branches, Development and Production. We were developing new projects in Development branch. After finishing a project we were checking out Production branch, moving newly added codes from Development to Production with the help of a folder comparison tool, and finally we were checking in Production branch completely.

Parallel development on the same project still was a big problem. Developers were using each others methods in the Development branch. But some of the methods they use for a feature, say feature X, were happening to be implemented for another feature originally, say feature Y, and because feature Y was still being developed those methods did not exist in the Production branch. Therefore deployment date of feature X was being postponed to the deployment date of feature Y. There were delays on project plans just because we were not able to calculate such usages of other features.

Finally, we realized that TFS was not a brand new source version control system. It solved none of our big problems. We were still having difficulties in parallel development.

In fact we were not aware of the power of TFS, branching and merging ability. The way we used TFS was just like the way we used VSS.

The main purpose of this writing is to make you aware of this single mistake: we did not try to learn conceptual facts about source version control systems. We were just happy with the old VSS. We did not realize the need of some other development methodology for our large scale projects for which parallel development is unavoidable.

In my example, the software project was the whole banking system of a bank. As you may easily guess, all the products of a bank needs software development behind. Competition between banks forces them to present new products to their customers continually in order to keep customers loyal to themselves. Each department of a bank invents new products every once in a while and requests software supply for those new inventions. Therefore huge software projects for banking systems need continuous development to present new products one after one (new account types, new bill payment systems, new investment methods, new credit cards...)


to be continued...
continuing (after a long while)...

Our software development pattern is like this: we have a number of products, and we continually add new features to them. Version release rate is once a month, but bug fix release intervals are shorter.

Thus we adopted such a branching structure:
For every feature request or bug fix, we start a new branch from code repository. Number of branches became, well..., a little too many :-)
In order to manage these branches, in such big numbers, we developed a command line tool using .net APIs of TFS.

Although we have so much branches, we do not encounter merge conflicts that much. This is mostly because a business department makes one or two requests for a certain amount of time (say a year). Plus not all products' codes need to change for one feature. Thus merge conflicts occur occasionally.

Additionally, branching for every request provides us flexibility in releasing features. We can release a feature immediately after development finishes or at a later time. We can even freeze the development if the business department wishes. Newly developed codes are not lost (they stay in the branch) and they do not interfere with other developments (we did not merge the branch to the trunk). If we want to release a feature, we simply merge the branch to the trunk.

We also used the build engine of TFS to check the health of our codes. After every checkin, we start builds and do code analysis, and we also report analysis results to the developers. If a build fails, we alarm all the team, not just the developer who checked in the code. Because the code they are going to get from TFS is going to be dirty, they should not get the latest version until somebody makes sure that the code on the server builds.

In summary, if you are not familiar with source version control concepts, and want to migrate from VSS to any modern source version control tool, not just TFS. I suggest you to search for branching strategies in accordance with your development model.