I was recently onsite at a client location working with them on a TFS implementation along with a complete redesign of their ALM processes with an Agile adoption thrown in, just to keep things simple. The client is a medium-sized company with about 200 developers worldwide including some off-shore contractors. In the afternoon of the second day of the engagement I was at the white board talking about source control and builds, trying to get a better idea of how they currently managed their build process and what code branching strategy they used. I kept getting this strange, confused look from the developers and development managers in the room. I was obviously under a false assumption. That it took me almost two full days to realize it was embarrassing. I stopped and finally asked the question I should have asked much earlier, “How do you build your solutions and how do they get deployed?” The answer, given the size of the company shocked me and (re)taught me a valuable lesson about assumptions.
|Me:||What is your current process of managing builds and code promotion?|
|Developer:||We do a local build and then copy the output to a test server… most of the time. Sometimes it goes straight to production.|
|Me:||By local build, do you mean “F5”?|
Again, because of the size of the company I was taken completely by surprise. I should not have been. At that point the discussion changed and we approached it from a different angle. I found that the major reason they were using the system they were, besides an obvious process issue, was a lack of resources.
Like many organizations where software development is not the primary line of business (and even some where it is), the development staff is seen essentially as a cost center. Allocating resources to development always comes secondary to supporting the main line of business, but in IT resource allocation, coming second often means coming never. To the development teams’ credit, they (like developers are wont to do) found a way. It wasn’t the best way, or even a good way, but it did get the job done – sort of.
I have already addressed the power of leveraging Azure for testing, but what about builds? Even better, what about the cornerstone of creating quality software: continuous integration builds? That too is not only possible with Azure, it is easily achievable. Leveraging a build with Azure comes in two distinct flavors: With Visual Studio Online and without.
If your source control is already hosted in VSO, using the hosted build services of Azure is simplicity in itself. All the details are described in the online Azure documentation. It’s fairly straightforward and involves simply linking an Azure cloud service or web site to your Visual Studio Online account.
Once your source control is integrated, A Hosted Build Controller will be available for your builds. The wizard will even go so far as create a continuous integration build definition for you. The hosted build service provides a flexible set of installed software to support your builds:
- Windows Server 2012 R2, 64-bit environment, with Windows PowerShell
- Team Foundation Build (Team Foundation Server 2013)
- Visual Studio
- Visual Studio 2013 Update 2 RC
- Visual Studio SDK 2013 RTM
- Visual Studio 2012 Ultimate Update 4
- Visual Studio SDK 2012 RTM
- Visual Studio 2010 SP1
- The .NET Framework
- .NET 4.5.1
- .NET 4.5
- .NET 3.5 SP1
- Microsoft Azure
- SDK 2.3
- SDK 2.2
- SDK 2.1
- SDK 2.0
- SDK 1.8
- SDK 1.7
- Other components
- Apache ANT 1.9.3
- Apache Maven 3.1.1
- Java Standard Edition Development Kit 1.7 U51
- Microsoft Office Developer Tools for Visual Studio 2013 Update 1
- Node.js 0.10.26
- Node.js Tools 1.0 Alpha for Visual Studio 2013
- SharePoint 2010 and SharePoint 2013
- SQL Server Data Tools for Visual Studio 2010, Visual Studio 2012, and Visual Studio 2013
- TFS Build Extensions
- TypeScript 1.0
- WIX Toolset 3.7
- Web Deploy 3.0
- Windows Phone SDK 8.0
If you need something installed on the build server that is not on the list, you will need to configure your own build server. The good news here is that you can also create your own build server in Azure, configure it with all the special bits you need and leverage it for your VSO projects with no extra configuration required. From the Azure instance, simply install and configure TFS build to connect to your VSO TFS instance and you are done.
It’s a bit trickier to set up a build server on Azure linked to an on-premise TFS instance, but only because of setting up the network link and, if applicable, the Active directory link. I won’t address the process of linking Azure with a local instance of Active Directory or extending a network from local to Azure, but it is not overly complicated. You can check out Keith Mayer’s TechNet blog and Brien Posey’s article in Redmond Magazine for details on extending Active Directory. Microsoft’s online Azure documentation has clear instructions on how to create network connectivity between your on premise network and Azure. Once the active directory and/or networking configurations are taken care of, the whole process of creating and deploying build servers is simple and the servers are configured just as they would be for an on-premise server.
Where it gets even more interesting is building and then publishing or deploying to Azure. Not because it’s harder, but because it’s not. Firing up an environment to publish a web application is relatively simple. The first step is creating a new web site in Azure and then downloading the publishing profile from the Azure portal in the context of our new web site:
After downloading the profile, just add it to the solution and modify the build definition to use it by adding some MSBuild arguments to handle the work.
Azure doesn’t simplify the process of deploying technologies other than web sites, it just makes it simpler to acquire the resources, which often times is 90% of the battle. In the case of non-web site applications, the process is pretty much the same as with on-premise resources with the notable exception of not requiring IT involvement or the requisition of new hardware.
With the resources and flexibility that is offered by Azure, the roadblocks to creating a sustainable build environment are essentially removed. We can now easily create and manage builds, including continuous integration builds without involving IT. We can than move forward to a continuous deployment scenario that after all, is not only the next logical step, but also the only viable step that makes sense. Continuous Integration for our code helps stabilize out development efforts. Continuous deployment helps stabilize our development and testing efforts and eventually our production deployment efforts. While we probably do not want to continuously deploy CI builds, the option is certainly open if we wanted. However, we can setup a nightly build to be continuously deployed. How many times have the QA teams not been able to perform required testing because there was no build deployed or because no one was available to go through the manual steps in order to perform a deployment or no environment was available?
A World Without Rules
OK, maybe I couldn’t figure out any other way to get a Matrix reference to work and maybe a “world without rules” takes it a bit too far, but I am not completely off course. Even if we haven’t achieved a development world without rules, we are very close to having a world without infrastructure limitations. A world were nothing prevents us from creating, testing and deploying our software in the most efficient way possible. In this new world we can be responsive to our customers’ needs while working on the next cool thing without being sidetracked by resource blockers or the imposed limitations of hardware acquisition and limited IT manpower and resources.
So even if “A World without Rules” is a fantasy, a world without barriers is not. The way has been cleared for development teams to be free from the ball and chain that is local un-scalable resources, in both personnel and technology. It is just too easy to leverage Azure in our efforts to achieve automation and as a result, more consistent quality.
A question may remain about the affordability and the cost of Azure. While I do not claim to be an accountant, I have battled my way through many finance meetings so I have this tidbit to offer: Taking in to account the loss of developer productivity plus internal IT costs against the overall cost of maintaining Azure assets for build and QA deploy scenarios, I would say Azure has the potential of being essentially free.