Looking to migrate your existing Visual Source Safe (VSS) projects to MS Team Foundation Server (TFS)? Thankfully, there are a number of options available, should you plan to do a “straight” migration (meaning, take what you have in VSS and replicate it in TFS). Migrating to TFS, however, does present an opportunity to evaluate how you utilized VSS and how you may do it differently.
There are a number of aspects to consider when reflecting on how VSS was used and how you’ll utilize TFS going forward:
Were all your software assets stored in VSS?
If they weren’t, why not? Should they be?
Did you use a branching/tagging scheme?
VSS had issues here– is this fact causing you to overlook how you’ll address these features going forward in TFS?
What directory structure did you use for VSS projects?
Was this structure effective and consistent across projects?
Before you indiscriminately take what’s in VSS and migrate it to TFS, take some time to carefully consider what aspects of your utilization of VSS worked and which didn’t and then carefully map a path that exploits the positive aspects of your process within the Team System platform.
If you’re looking for TFS integration with Eclipse clients, there is currently one viable option and one to come: a commercial plug-in and an open source project with an anticipated tool.
The commercial plug-in is called Teamprise and is quite mature. The Teamprise plug-in runs about $500 USD and scales nicely with more licenses. For example, 10 licenses go for about $2,300 USD.
The VSTS Tools for Eclipse project aims to be an open source alternative; however, they admit they “have a long way to go before we have a working product.” Nevertheless, this promises to be a practicable solution eventually.
What is code quality exactly? You may not know how to define it, but you know it when you see it. One thing is sure, though, high code quality usually correlates to fewer defects. Ensuring the quality of your Java code is a two-step process: write tests at all levels, early and often; and continually monitor quality metrics.
Are you currently using code metrics? If the answer is no, why not? This survey gives four typical answers; however, are there others not listed? Take a moment and provide an answer as to why you aren’t using metrics.
TestNG, an annotation-based testing framework, draws on some of the shortcomings of JUnit. Glover touched on this subject in his article, “JUnit vs. TestNG”; part of his popular “In pursuit of code quality” series on IBM developerWorks.
Implementing test categorization with TestNG is quite easy. With TestNG’s group annotation, logically dividing tests by category is as easy as applying the proper group annotation to a desired test. Running a particular category then is a matter of passing in the corresponding group name to a test runner, such as Ant.
More often than not, the number one objection for not implementing practices like developer testing is the perceived increase in developmental costs. If you find yourself thinking the same thing, I’ve got news for you: you’re absolutely correct– quality does increase costs.
There is a common saying that states there aren’t any free lunches in life. There aren’t free lunches in software development either. In fact, in a well regarded paper from 2001, entitled “Software Defect Reduction Top 10 List ” the authors state, based upon empirical data, that it often costs:
50 percent more per source instruction to develop high-dependability software products than to develop low-dependability software products.
Based upon that data alone, writing tests is a complete waste of money, right? The one thing that people often miss, though, is the second half of the cost equation. While quality upfront costs more compared to ignoring it, the long term cost is where quality becomes worth while. As they eloquently state in the next sentence:
…the investment is more than a worth it if the project involves significant operations and maintenance costs.
Introducing quality in early cycles is just like making financial investments– you pay now because later you expect greater returns. In the case of software, those greater returns are applications that can change quickly. This means that software systems which make investments in early quality will deliver verifiable features faster over the course of their life span than those systems which defer quality.
Indeed, quality has a cost, in terms of time and money; however, it pays substantial dividends in the long run. If you are developing business critical software, which isn’t going to be thrown out in short order, are you investing wisely?
Are you currently maintaining a COBOL application? I’m certainly not; in fact, I’d probably struggle to count, on one hand, the number of people I know who could recognize COBOL. Yet, COBOL applications are still running today. Moreover, in an article entitled “COBOL: The New Latin ” the author states:
“the use of COBOL is growing…by about a billion lines per year.”
Yes, that does read a billion, but why should you care? The author believes you should care because COBOL skills could yield some large amounts of cash for skilled COBOL programmers; however, I look at this scenario a bit differently.
If COBOL is still out there running; in fact, running business critical applications judging by its formidable growth, what does that mean for the code you’re writing today? If history is any indication, the code you write today will most likely be around a long, long time, especially if it has any business value to it.
That means the practices and decisions you put into place today will affect someone, most likely not yourself in the future– in some cases the far out future. This also implies that the decisions of the past are affecting you now.
Clearly, software applications that achieve business value are far from ephemeral flashes in a pan– so what are you doing today to ensure these systems can still run tomorrow? Not only does software live a lot longer than intended, it’s also entropic– without an insightful software process that encourages quality, software systems will become more complex and harder to change.
Latin is often labeled a dead language, yet, I had to take a year of it in high school– and I didn’t attend high school 2,000 years ago. Spoken languages never really die, they survive in texts and are carried forth by academics. Programming languages rarely die either. They linger as applications that go on and on until the cost to maintain them overtakes the cost to rewrite them. And, it seems clear, as demonstrated by the growth of COBOL code, that this means applications can last “in aeternum”, which in Latin means “for eternity.”
Does your team use Visual Source Safe? Does your team plan on using VSS this year? Chances are, you are– at least based upon the data from VSoft Technologies, who found that the majority of their survey respondents (about 400) are still using VSS or planning on using it.
If you answered yes to either of the above questions, there are two pieces of data (which conflict to those who have to manage budgets) to consider:
“Team Foundation can support teams of up to 2000 users whereas Visual SourceSafe is recommended for teams of twenty or less.”
In another MSDN article entitled “Choosing Between Microsoft Visual Studio Team System and Microsoft Visual SourceSafe“, there is a telling graph, which charts the cost of VSS versus Team Foundation Server. In that graph, it’s quite clear that the cost of using VSS beyond 10 users is exorbitantly higher than TFS; in fact, at twenty users, VSS is more than twice as expensive as TFS.
Graduating from VSS to TFS isn’t a one day affair; however, the migration process may be worth while– especially if your team has more than 20 people….or is that 10 people?
