An amusing little video before this general session was a spoof on the Fab 5 from Queer Eye for the Straight Guy. In the video, five guys (the A5 – Architect 5?) come running to thre rescue of a software development team that has been holed-up in a conference room trying to architect their application.
Rick LaPlante spoke about the three principles behind creating Visual Studio 2005 Team System:
He also spoke of the mantra the team adopted for Team System:
“Our process, your process, no process, productivity day one out of the box.”
He spoke to the existence of role-specific silos that exist in the IT life cycle and how they create friction in the system. He supplied an anecdote of a talk he once gave where the audience self-segregated themselves into the same silos that existed within their company. Operations people were grouped together. Architects were grouped together. Developers were grouped together. Etc.
Visual Studio Team System aims to:
- Reduce complexity
- Facilitate communication
- Create a vibrant third-party ecosystem
Lori Lamkin then joined Rick on stage to kick-off a walkthrough demonstration of Visual Studio Team System using a fictitious company (Adventure Works) web site. She demonstrated how Team System enables you to enter requirements and track the associated work items using Microsoft Excel.
Enter Jim Dial, who is playing the role of infrastructure architect. He used the work item he received from Lori to kick-off work on designing the updates to the Adventure Works site. He used the Distributed System Designers (formerly known as Whitehorse) to modify the current logical datacaenter diagram. He demonstrated how the designers enable the infrastructure architect to define server settings and constraints. This included adding the external Web service the application will use. Jim then assigned the work item over to the solution architect, David Keogh.
Distributed System Designers
David Keogh picked-up where Jim left off by modifying the application design using the same set of design tools as Jim did. The tools enabled David to see how the various components of the application communicate with each other and to verify that the application doesn’t violate any of the constraints Jim placed on the datacenter architecture. Next, David generated the projects that the developers would need to implement the application. David then resolved the work item to indicate the architecture work was complete.
Using the work item tracking system, Lori was able to monitor the status of the architect’s work. She was able to use the same data in Microsoft Project to update the schedule. She showed how different teams can use the tools of their choice (Borland Caliber RM) to work with the same data, which is stored by Team Foundation Server. She demonstrated data synchronicity across Microsoft Excel, Microsoft Project and Borland Caliber RM. Lori then assigned work items to the developer, Eric Lee.
Eric demonstrated work he was already doing using the Class Designer. With the new work he received from Lori, he used the shelving feature of the new source control system to save his current work on the server without impacting the current build sources. He then opened the project that David created earlier and used the new Snippet feature to insert pre-written code. Next, he added some unit tests (which were generated for him) to his project to test the functionality of his code. He also demonstrated the test management functionality that’s built-in to Visual Studio Team System. After running some tests, he was able to view code coverage results that showed him which lines were covered using highlighting in the source code. When he went to check-in his new code, he was warned of a policy violation. His team has instituted a policy requirement that all code must undergo static analysis prior to check-in. He used custom methodology help that was integrated in Visual Studio Help to learn more about this requirement. After running static analysis, he discovered that his code had a security problem. He associated the check-in with the work requirement he received from Lori. He also showed that you can override policy if need be, but doing so is made visible to others.
Now back to Lori. She was able to once again see status without pestering anyone.
Now we fast forward to the next day. Enter Tom Arnold. Tom is reviewing the auto-generated build status report from the nightly build. In the report, he was able to see which build verification tests were run and which ones passed. In his work item queue he found that he had some work items assigned to run some load tests on the new application. Before doing the load tests, he ran a UI test on the rich client portion of the new application. Since Team System doesn’t include UI testing, he used an integrated version of Compuware TestPartner to run the test. Rick noted that the level of integration enables third-parties to be first-class citizens of Team System. Tom then recorded a web test that he would later use to load test the new web application. He then showed how he could customize the load test to account for stuff like variations in load. After running the load test he was able to log bugs and attach the actual test results so that Eric could see what he was seeing.
Now back to Eric. Eric has the bug Tom found in load testing. He was able to view the test results from Tom. To help locate the source of the bug, Eric used a wizard to quickly and easily set up the ASP.NET application for profiling in seconds. Once the profiled application was running, Eric ran the same test as Tom and gathered some performance data. Eric then used the performance reports (summary, functions, caller/callee, callstack and trace) to drill-down to the offending function. He was then able to open the source from the report and he identified the problem in his code. He then used AVIcode Intercept to instrument the application with specific performance counters and set limits to alert operations when an application is un-healthy.
Now it’s Lori’s turn. She used the Project Site to look at the key metrics she uses to manage the project. She reviewed reports that were automatically generated based on data that was collected automatically during the course of her team working. She was able to drill-down in the reports to see a lot more data that revealed her team may not be ready to ship. While the customary data indicated the product was ready, the reports showed that her team needed to improve their code coverage.
Rick revealed that over 15 partners are making announcements of their support with tools that will build on Team System. He also outlined the developer roadmap that showed Visual Studio 2005, Team System and SQL Server 2005 all shipping in 2005.