Visual Studio Team System 2010 Development Edition: Overview
Taking a break from my series on new TFS 2010 features, I thought it would be a good idea to also give a high level overview of what exactly is new in the VSTS 2010 Development edition. This should really give you a flavor for all the cool new stuff we’ve enabled for developers and development teams.
If you haven’t already downloaded the VSTS 2010 beta 1, then check out the download page, as well as Brian Keller’s blog post for step by step instructions on how to quickly download and install VSTS 2010 Beta 1.
First off here’s a list of the major themes that we went after for VSTS 2010 Development edition, I know it’s a long list and each area really talks to a given problem area that we wanted to address in this release.
- Say No to “No Repro”
- Choose the Right Tests
- Prevent Code Defects
- Write Faster Code
- Same Tool, Different Developers
- One Tool to Many Databases
If I could sum up VSTS 2010 Development edition in a few short words, it would really be that we enable developers and development teams to write better, faster code in less time…
Say No to “No Repro”
One of the main problem areas that we really wanted to address in VSTS 2010 Development edition was to reduce the time spent by each developer on trying to reproduce a bug that came in from the test team, business analyst, a customer, or from the production environment. How many times have you been in that situation, where you get into those discussions of “well, it works on my box”, and then you waste the workday back and forth with testers or your support folks, trying to reproduce the issue, so that ultimately you can fix that given defect.
The cost of finding and fixing a code defect increases dramatically as you transition from your development to test, to staging, to production environments. With the introduction of our new historical debugging feature we alleviate that pain by recording what the application was doing during its execution, so that later, we can review that execution in Visual Studio. You can now step back in time, through your debugger, to see what exactly was happening in the application prior to the bug occurring. You will be able to access a call stack from a specific point in time and drill in from there. You will also have access to a larger number of execution points which can also be drilled into, comparing variables, call stacks, etc. to ultimately help find the root cause of the issue without having to actually rerun the application or more specifically reproduce the problem.
John Cunningham’s blog has also of additional details on the new features we’ve enabled for the Historical debugger for VSTS 2010 Beta1.
Choose the Right Tests
How many times have you made a code change and prior to actually checking in that change to your source control system, had to run a slew of test suites, to ensure you have not broken anything elsewhere in the application. With the addition of our new Test Impact Analysis tool, we can now tell you, which specific test cases are impacted by your code changes, to allow you to quickly locate and run the right test cases.
This feature brings tremendous productivity gains to developers by pin-pointing the exact unit tests to run as opposed to having to run the entire suite of tests. It also allows developers to have a quick and easy way to ensure the quality of their code changes prior to checking into their source control systems.
John Cunningham’s blog has a lot of additional details on the new features of the Test Impact Analysis in Beta 1
Prevent Code Defects
In VSTS 2008 Developer Edition Code Analysis (and earlier editions), we enabled developers to analyze/clean their code before it goes out into test, staging or production environments. This really speaks to the value of adding quality into the development lifecycle a lot earlier, which cuts down on time & resources that would have been spent later finding and fixing those issues if they occurred in the test, integration or staging environments.
A common request that we’ve heard from users of Code Analysis, is that we provide a lot of data about defects but they struggle to determine which area to tackle first based on the issues detected. In VSTS 2010, we have introduced a new notion of Code Analysis Rules Sets which helps users to determine which rules they should focus on, based on their project type and the work that they are trying to complete.
So instead of running the whole gamut of rules over the code base, we can scope down to a set of rules that are to be run based on a given task. For example, if users are getting ready to release their app, instead of running all rules, they can run the Release Rule Set instead which is made up of rules that have to be addressed prior to releasing the application(each rule set is customizable according to the development team’s coding standards/requirements). Again this is another productivity gain for developers as they are ensuring quality earlier in the development lifecycle.
Write Faster Code
Same Tool, Different Developers
When the original VSTS 2005 Database Edition was released, it revolutionized the way in which database developers managed their database schemas and really started the journey of modernizing database development. The new database features have been so popular with developers and we’ve found so much overlap between database and development edition customers that we decided to include all of the database development functionality to the development edition.
In VSTS 2010 Development edition, we have combined both editions’ functionality into 1 single edition, with 1 installer, which is available to all VSTS 2010 and VSTS 2010 Development users.
One Tool to Many Databases
In VSTS 2010 Development edition, we built out a very rich extensibility platform (known as a Database Schema Provider) to enable 3rd parties to extend Visual Studio Team System with offline design, development, testing and change management of non SQL Server databases. At Tech Ed 2008, IBM demoed an early prototype of the DB2 Database Schema Provider integrated into VSTS 2010. And in February of this year, Quest announced that they are building an Oracle DSP to allow Oracle developers to work within VSTS 2010 to manage their database changes right alongside their application changes.