Visual Studio Team System 2010

Visual Studio Team System 2010 Overview

The marketplace has begun to mature and accept Application Lifecycle Management (ALM) as a proven discipline for creating high quality applications in a reliable fashion. However, existing solutions in the marketplace have not kept pace with the changing needs of technical users and the expanding inclusion of non-technical users as part of the lifecycle. The third generation of Visual Studio Team System – Visual Studio Team System 2010 – will address the needs of these customers with a robust and streamlined solution.

Every customer today faces a similar set of business problems:

• How do we build high quality applications that deliver real business value?
• How do we embrace the Application Lifecycle Management model effectively?
• How can we ensure that all members of the team – both technical and non-technical – are part of the process?
• How can we get the most value from our existing code assets?
• How do we make powerful modeling tools available to everyone in the application lifecycle?

Our ALM tooling specifically addresses these questions and helps customers create high quality applications that deliver value to the business. We are evolving the market beyond the first generation of ALM tooling, by:

• Building quality into the lifecycle
  • Ensuring architectural consistency through the lifecycle
  • Eliminating “No-Repro” bugs
  • Ensuring smooth build handoffs and high quality builds
  • Incorporating performance in the lifecycle
• Driving efficiency into the test effort
  • QA Team aligned with Business Analysts, Architects, and Developers
  • Eliminating tedious tasks
  • Improving setup and deployment of tests
  • Choosing the right tests
• Ensure Complete Testing
  • Focused test planning and progress tracking
  • Transparently see the quality of requirements and level of testing
  • Finding the gaps in testing and fill them
  • Ensuring changes are properly tested

The following sections highlight specific feature of Visual Studio Team System 2010 that address the common business needs.

Modeling that Works with Code

For most businesses only about 20% of the code being written today is for new applications; the majority of work is being done on existing code bases. A typical issue encountered when working on existing code is not having good tools to help the architect or developer understand the system. This can make it challenging to not only understand what needs to be done to make the required changes, but it makes it equally challenging to understand the broader impact of the changes. Often it isn’t until much later that an unexpected bug is discovered as a result of a change. Our modeling tools have tight integration into the actual code of the application. This means that a developer or architect can use models to explore existing code assets. The new Architecture Explorer in Visual Studio Team System gives developers and architects the capability of creating a full architectural picture of existing code; understanding how they fit together; understanding how they “work.” This leads to better information about how to use, re-use, or even whether or not to discard existing code. The Architecture Explorer provides architects and developers a mechanism for visualizing code assets in a number of ways including graphs, stacked diagrams and dependency matrices. The introduction of the Architecture Layer Diagram means that a developer or architect can use models to enforce constraints on code as well. The Architecture Layer Diagram can be coupled to code making it an active diagram that can be used for validation. For example, when an architect designs a system where the presentation layer should not talk to the data layer, you want to be able to enforce that model at check-in. VSTS 2010 can do that. These capabilities delivered in VSTS 2010 are part of the Microsoft’s overall modeling story. Learn more about modeling by watching the Trends in Software Modeling webcast featuring Jeffrey Hammond (Forrester Research), Cameron Skinner (Microsoft, Visual Studio Team System), and Clemens Reijnen (Sogeti).

The new Architecture Explorer enables individuals to create a visual representation of existing code assets. The Architecture Layer Diagram enables validation of code against a visual representation of the architecture.

Eliminating “No-Repro” Bugs

From the design of the application through to the actual writing of the code, one of the most difficult problems has always been that of the bug that can’t be reproduced – the “no-repro” bug. There are a lot of factors that drive these types of bugs and we have worked to create tools to help isolate the issue and enable faster fixes. One way this is solved in Visual Studio Team System 2010 is with the use of a tool that can specify the exact state of the build used by a tester and allow a comparison to the state of the build used by the developer when trying to reproduce the bug. It is often the subtle differences between these two that create the no-repro state, and a new tool within Visual Studio Team System 2010 has been designed to specifically address this. This tool – the Microsoft Test Runner – is a standalone tool that a tester uses to guide them through a series of steps to complete a test case. When the test case is started the Microsoft Test Runner takes a snapshot of the system data, including OS version and Service Pack and other pertinent system data. As the test is being run the tester can use the tool to capture images of the application under test, or even partial or full screen video of the test being run. If an issue is discovered, the tester can create a new bug in Team Foundation Server and attach these artifacts. When attached, the screen capture video is fully indexed with the test steps as bookmarks, making it easier for the developer to see what went wrong on the tester’s machine. All of these artifacts help to eliminate the no-repro scenario, and help build a better bridge between development and test.

The Microsoft Test Runner enables testers to follow a set of defined validation steps and easily create an actionable bug, including system information, screen images and even a fully indexed screen capture video of the steps that were followed.

Identify the Test Impact

As developers make changes to the code, it is critical for them to effectively test their changes, not only to prove the new code functions as expected, but also to ensure there is no unexpected downstream effect. Test impact analysis and test prioritization identify the tests that must be run to validate the code changes. This helps developers quickly check-in code with confidence by running only the necessary tests, and reduces the churn created by unexpected failures. The new Test Impact View window enables a developer to view a list of tests that need to be run as the result of a code change. The developer can toggle between an Impacted Tests view and a Code Changes view. The Impacted Tests view provides a list of tests that need to be run and which code changes are covered by each of the tests. The Code Changes view provides a list of code changes and which tests must be run in order to validate each of them. These two views provide a easy way to discover what tests must be run in order to validate the changes to the code base without having to run all of the tests. This ensures that all changes are tested effectively. content taken by http://msdn.microsoft.com/en-us/vstudio/bb725993.aspx

Microsoft ready to Bang Google with Bing

Microsoft ready to Bang Google with Bing
From: Wisdom Talks Wisdom Talks :: Talks about Anything June 01, 2009

Now after Wolfram Alpha, Microsoft has showcased a new search engine, Bing, which will specifically focus on travel, shopping, health and local business results. The Redmond-based giant is marketing the new website as a ‘decision engine’ that pro Read more at Wisdom Talks Wisdom Talks :: Talks about Anything »

Microsoft SharePoint "14" is now Microsoft SharePoint 2010

Microsoft SharePoint "14" is now Microsoft SharePoint 2010
By sptblog on Announcements


You have probably seen the news announcement today where we announced the public beta for the new Microsoft Exchange Server 2010. As part of that announcement, we also talked about some of the names for the "14" wave of products including Microsoft Office 2010 and Microsoft SharePoint Server 2010. I wanted to answer some questions that I think will inevitably pop to the top of your mind:
What happened to the Office piece of the name? We love MOSS. . . .
The first thing you’ll notice is that the MOSS acronym goes away with the new name since Office is no longer in the SharePoint official name. No one should worry that SharePoint doesn’t work great with Office 2010 since we removed Office from the name, just like people didn’t worry whether SharePoint was a great portal product when we removed Portal from the 2007 name.
The primary reason why we took Office out of the name - lots of folks associate the name Office with the Office client. We wanted to take the opportunity to reestablish the Office name and brand to be synonymous with the client suite. I say "Give the people what they Want" so everyone should immediately think of Microsoft Office = Office apps.
Don’t try to acronym Microsoft SharePoint Server to MSS since MSS is already taken by Microsoft Search Server. Just remember, SharePoint is SharePoint is SharePoint.
What about Windows SharePoint Services?
When you read through the announcement, you may be wondering what happened to Windows SharePoint Services. While we didn’t announcement anything new for WSS, and I want to assure you that we’re definitely working on a new v4 version of the product. It’s too early to drill into any of the details but WSS is getting a lot of new features and will be a great release. We’ll talk more about WSS at a later date.
So, what was announced?
Here are my key takeaways from the interview with Chris Capossela:
• Exchange 2010 will lead the way for the 2010 (previously referred by its codename "14") wave of technologies and it will be available in the second half of 2009. You can download a beta today.
• Using Office Web applications, customers will be able to create, edit and collaborate on Office documents through a browser.
• IT professionals will be able to choose to either deploy and manage on-premises or hosted as a service.
• For developers, we are working on Open APIs, deep support for industry standards and developer tool support with Visual Studio 2010.
You can read the entire interview here.
Thomas Rizzo
Sr. Director
SharePoint

Announcing SharePoint Server 2010 Preliminary System Requirements

Announcing SharePoint Server 2010 Preliminary System Requirements
By rriley


We’ve heard loud and clear that you want system requirements information as early as possible to assist in your budgeting and planning, so today we’re happy to announce (and confirm) some preliminary system requirements for SharePoint Server 2010:
1. SharePoint Server 2010 will be 64-bit only.
2. SharePoint Server 2010 will require 64-bit Windows Server 2008 or 64-bit Windows Server 2008 R2.
3. SharePoint Server 2010 will require 64-bit SQL Server 2008 or 64-bit SQL Server 2005.
In addition to the requirements listed above we also wanted to share with you some preliminary detail about SharePoint Server 2010 browser compatibility.
To ensure the best possible experience across multiple browsers we’re focusing our SharePoint 2010 engineering efforts on targeting standards based browsers (XHTML 1.0 compliant) including Internet Explorer 7, Internet Explorer 8 and Firefox 3.x. running on Windows Operating Systems. In addition we’re planning on an increased level of compatibility with Firefox 3.x and Safari 3.x on non-Windows Operating Systems. Due to this focus Internet Explorer 6 will not be a supported browser for SharePoint Server 2010.
So, what can you do today to get into the best shape for SharePoint Server 2010?
1. Start by ensuring new hardware is 64-bit. Deploying 64-bit is our current best practice recommendation for SharePoint 2007.
2. Deploy Service Pack 2 and take a good look at the SharePoint 2010 Upgrade Checker that’s shipped as part of the update. The Upgrade Checker will scan your SharePoint Server 2007 deployment for many issues that could affect a future upgrade to SharePoint 2010.
3. Get to know Windows Server 2008 with SharePoint 2007, this post is a great starting point.
4. Consider your desktop browser strategy if you have large population of Internet Explorer 6 users.
5. Continue to follow the Best Practices guidance for SharePoint Server 2007.
6. Keep an eye on this blog for updates and more details in the coming months.
Below are a few common Q&A’s (which we’ll add to as required)
Q: What about Internet Explorer 6 and SharePoint 2010 publishing sites?
A: The Web Content Management features built into SharePoint 2010 will provide a deep level of control over the markup and styling of the reader experience. These features will enable customers to design pages that are compatible with additional browsers for viewing content, including Internet Explorer 6. A standards based browser such as Internet Explorer 7, Internet Explorer 8 or Firefox 3.x will be required to author content.
Q: Is Internet Explorer 6 officially supported by Microsoft?
A: Official Microsoft Product Support for Internet Explorer 6 follows the lifecycle of the Operating System with which it was shipped. In order for customers to receive product support through the Mainstream Support and Extended Support phases, they need to have installed a supported Service Pack. For example, customers who are using Windows XP must transition to Service Pack 3 by July, 2010 and are eligible to receive support for Internet Explorer 6 until April, 2014.
You can find additional information on Microsoft’s Support Lifecycle Policy including specific dates, product information and support offerings here: http://support.microsoft.com/gp/lifepolicy.
Q: Why are you only supporting the 64-bit versions of SQL Server 2005 or 2008 for SharePoint Server 2010?
A: This decision was based on our current test data for SharePoint Server 2010 and real world experience from customers running SharePoint Server 2007 with 32-bit SQL Server. SharePoint performance and scalability can benefit significantly from 64-bit SQL Server and the throughput increases are significant enough for us to make the difficult decision to only support SharePoint Server 2010 on 64-bit SQL Server 2005 or 2008. It has been our strong recommendation for some time that SharePoint Server 2007 customers take advantage of 64-bit SQL Server due to the inherent performance and scale benefits it can provide.
Q: Where can I find more information on the advantages of 64-bit hardware and guidance on how to migrate SharePoint from 32-bit to 64-bit.
A: These two TechNet articles are a good starting point;
Advantages of 64-bit hardware and software (Office SharePoint Server 2007)
Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)