From the Blogosphere
Three Microsoft Developer Tool Integration Insights By @WesleyCoelho | @DevOpsSummit #DevOps
The DevOps movement further highlights the need to connect a diverse set of people, processes, and tools
Sep. 12, 2015 01:00 PM
Three Microsoft Developer Tool Integration Insights
If you're part of a substantial development organization standardized on Microsoft development tools, chances are you'll need to integrate Microsoft Team Foundation Server (TFS) and Visual Studio with third-party tools. The DevOps movement further highlights the need to connect a diverse set of people, processes, and tools, including the business stakeholders and the operations space. When establishing a modern end-to-end development practice you'll almost certainly need to hit the integration button. Here are a few insights to set you on the right path:
1: Visual Studio IDE Plugins Are Not Always the Best Option
The Microsoft Visual Studio Integrated Development Environment (IDE) is highly extensible, with thousands of plugins for every imaginable purpose. Want to tweet right from your IDE? There's a plugin for that. One of the more common IDE integrations brings work items into Visual Studio from a diverse range of third-party development management tools like JIRA, Rally, VersionOne, IBM RTC, HP Quality Center, etc. This allows developers to code in Visual Studio, enjoying its integrated UI experience with the ability to receive, view, and update work items that are actually managed in an external tool.
This kind of integration does the job for simple missions. But Microsoft already has slick native work item integration for Visual Studio built in - the integration for TFS. The advantage of using TFS integration for Visual Studio is that it's already natively integrated with other Microsoft components such as version control and builds.
How does this help someone using something like VersionOne or HP instead of TFS? An alternative to integrating VersionOne to Visual Studio at the IDE UI level is to instead integrate VersionOne with TFS at a data level by synchronizing your VersionOne instance with an instance of TFS. This allows developers to take advantage of all the native TFS to Visual Studio integration while still having the ability to manage their project in VersionOne, Rally, HP, JIRA, or whatever the external system might be.
2: Take Advantage of the Most Common Integration Patterns
When bringing together a tool stack that involves managing work items that span multiple tools, it's not easy to know where to start. At Tasktop we call these integration use cases or scenarios "integration patterns." Review some of the more common integration patterns to help you prioritize the ones that create the most value for your organization. Here are some of the more common integration patterns:
- Defect Unification. Developers using TFS are interacting with a QA team using a separate tool. This is problematic because QA reports defects in one system, but developers manage their backlog of defects to fix in TFS. Address this by synchronizing defects in TFS with the external system used by QA, e.g., HP Quality Center.
- Requirements Traceability. Requirements are defined in a specialized tool, but developers are using TFS to break the requirements down into stories, then implement them. Furthermore, traceability is necessary between the stories and the original requirements. Address this by synchronizing the external requirements into TFS for implementation.
- Agile Plan Orchestration. With TFS, teams often develop using an agile process that is quite detailed and separate from the Project and Portfolio Management (PPM) tools the Project Management Office (PMO) uses to track overall project process. However, there's a need to connect the PMO with development to communicate status and priorities across teams. This can be eased by synchronizing only high-level work items from the PPM tool into TFS, where they can be broken down into bite-sized units of work while reporting only the progress of the high-level work item back into the PPM tool used by the PMO.
3: Adopt Visual Studio Online in Baby Steps with a Hybrid Approach
As the IT world moves toward the Azure cloud, using Microsoft Visual Studio Online is an increasingly popular way to access development tooling as a service. However, many organizations have substantial existing TFS infrastructure and can't switch to the cloud overnight. Custom extensions to TFS that can only be applied on-premises are another potential speed bump to adopting VSO. To ease the transition to the cloud, start with a hybrid approach in which new projects hosted on VSO are synchronized to the TFS mothership installation on-premises. This allows teams or individuals to incrementally adopt VSO while still allowing access via TFS and still supporting existing infrastructure such as cross-project reporting or continuous integration and release tooling.