Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Microsoft tools choices for DevOps

Alva Powell, CTO at The Center for Autism and Related Disorders, discusses which Microsoft tools his organization uses for DevOps.

As CTO of a Microsoft development and operations (DevOps) organization, how are choices made about new products...

and upgrades and when to use Microsoft tools or not?

Day to day, I manage a software development team and an IT operations staff for The Center for Autism and Related Disorders [CARD], roughly 20 to 25 people. We are developing four different products right now for internal and external consumption.

We use a splattering of Microsoft tools, such as Microsoft Project and SharePoint. For development, we use Microsoft back-end-to-end in the development tools. The truth is, however, that we have to use other tools to build apps for multiple platforms.

Mostly we evaluate tools based on business need, but sometimes new features in the Microsoft tools we use drive our evaluations. The development team keeps track of advances.

We have started moving from Visual SourceSafe to its replacement, Team Foundation Server [TFS], but it is a slow process. SourceSafe is -- or was -- a set of source control tools that build a library of files. Moving all our source repositories is kind of a pain, but we have to do it to get to TFS. The benefit, when we get this done, is that it [TFS] has all the development tools inside and rolls files up into Microsoft Project. Then we can push that out to SharePoint.

This year, we are looking at moving to SQL Server 2012. We are on SQL Server 2008 R2 right now, but 2012 promises better performance [and] thanks to an optimizer, better SharePoint integration by [making it a shared service].

Both of these projects [TFS and SQL Server 2012 migration] are major projects that are a lot more involved than just changing out the development tools.

We do have to complement our Microsoft toolbox with other types of tools. Our iPad application development projects are an example. We have used [Xamarin] MonoTouch to get around some of [Apple's] virtual machine barriers. Our technical architect says MonoTouch gives us a cross between Microsoft and pure, straight-up iOS development. The code is all written in C# , but you actually do it in Visual Studio. Then you pass it [the code] over to app dev on the Mac, where it's compiled and deployed to the iPad. Therefore, you can't do the straight-out deployment through Windows, but they do a lot of the development on a Windows box and then push it over to a Mac box and do the final deployment.

With these projects and others, our goal is to be a totally transparent IT shop, so any of the senior staff or in-house customers can basically jump on SharePoint and see exactly where any project is at any time. They can see what's going on with development, which resources were allocated, which resources have been shifted, what the timelines are, how we're tracking to the timelines and more. If we succeed, I will never get a question about whether a project is on-track, off-track, derailed or anything like that. We're getting close, which is a big accomplishment, as CARD's IT department is only about two-and-a-half-years old.

Dig Deeper on Visual Studio Tools for Office (VSTO)