Microsoft Dynamics CRM is an interesting and powerful business application. A core out-of-the-box (OOTB) benefit of Dynamics CRM is the ability to extensively tailor the application to address business needs, and here there are two approaches to consider: development or customization. Determining which approach to take is the key to maximizing the benefits of Dynamics CRM while keeping costs low.

Dynamics CRM is a basic web user interface fronting a SQL Server database that manages relational data. However, it is flanked by a built-in array of basic analytical tools and extensive administrative features, such as auditing, which give it enterprise-level credentials. Throw in a customizable user interface (UI), and you have a tool that is capable of supporting both small businesses and multinational corporations. So it would be logical to assume that Dynamics CRM has a developer-friendly, structured architecture to support customizations.

However, the reality is a little more complicated and brings up some curious paradoxes about Dynamics CRM. Read More…

Today I want to talk about a process we created for building out machines using Virtual Machine Manager (VMM) as part of our daily build process within Team Foundation Server (TFS).

As part of our nightly build process, we actually recreate the entire environment from scratch. We don’t use snapshots; we actually delete and provision a series of VMs. This may sound like overkill and I’ve seen other approaches that use snapshots and revert each night…and I think that’s great. Use what works for you. However, we wanted something that could not only exercise our code base, but also our scripts that we use for building our environment. In a way, this allows us to test both pieces at the same time.

At this point I should throw in the disclaimer that this blog post builds on one written by my colleague David Baber: Driving PowerShell With XML. We use the same XML-driven framework to build out our machines. In reality the process of removing and creating VMs is treated as just one “step” in our build-out process. Executions of other steps obviously follow, but this post is primarily concerned with standing up that environment. What happens next is up to you. Read More…

We recently started working on a new iOS project.  As part of this adventure, I asked the team if we could build a case study around XCode and TFSPreview.com. TFSPreview, if you’re not aware, is Microsoft’s Team Foundation Server 2012 as a service, hosted in Azure.

This isn’t your normal pairing.  Mac developers aren’t exactly flocking to the Microsoft stack and the Microsoft development tools haven’t exactly catered to the predominantly OSS community working on Macs.  In recent years, though, that has changed.  ASP.Net is now OSS, first class Azure tools ship for the Mac, even the Nodejs for Azure tutorials feature Chrome on a Mac.  It’s a brave new world out there!

Starting with this post and continuing over the next few months, I’m going to be sharing some of our experiences building iOS/XCode apps on TFSPreview using the cross-platform (yes, they used Java – who are these guys?!) git-tf plugin.

Read More…