Continuous Delivery with Visual Studio Team Services
Microsoft’s stack of software development tools, or Visual Studio Application Lifecycle Management (ALM), has evolved significantly in the past couple years. Some evidence of the progress can be seen in the acceleration of updates to Azure and the .NET framework. Even Windows 10 takes notes from Microsoft’s adaptation of evergreen packages.
The strategy and potential for Microsoft’s new ALM is wrapped up in their investment in Azure’s infrastructure as a service (IaaS). Before Microsoft Azure was released in 2008, the Cloud was seen as a major threat for disrupting the Windows Server OS infrastructure. Microsoft was slow to turn away from their decades of investing in on premise server solutions. In reaction to this misjudgment, Microsoft has reverted several of their ancient (closed source) practices.
At the Connect(); event last year, Microsoft unveiled the future of an open source .NET on Mac and Linux. The cross-platform framework is just the centerpiece of a larger cultural change for Microsoft. Their new development ecosystem allows any piece of the Microsoft technology stack from planning and developing, to building and testing, to deployment and telemetry to be replaced by any preferred third party option. The interoperability between components in Visual Studio 2015, Azure, and Visual Studio Online is liberating for the developers who can benefit from the massive infrastructure and platform, but can’t give up one of their favorite tools.
This year at Connect();, Microsoft continued to expand the tooling freedom for developers. The keynote blasted off with a native .NET core Hello World running natively on Ubuntu and then dived in with over 80 sessions of hands on code, demos, and Q&A. Along with the emphasis on tooling for new languages and platforms, there was an explosion of talk about services to support the “DevOps Era”. In order to clarify the tools intended for DevOps, Microsoft rebranded their “Visual Studio Online” (which sounds like an online IDE), to “Visual Studio Team Services”. This emerging buzz word has earned its own conferences, wiki page, and an entire department from Microsoft. Donovan Brown, one of the leading tech evangelists for DevOps at Microsoft coined a definition which Microsoft has adopted as their own:
DevOps is the union of people, process, and products to enable continuous delivery of value to our end users
By this definition, it is clear that utilizing DevOps is not about using any specific tool or tech, but creating a culture of collaboration between developers, QA, and IT in order to dramatically shorten the feedback loop and release more rapidly. In traditional development, moving software from source code on one developer’s machine, to the hands of testers and customers, was a significant process on its own. With the power of a global, matured cloud, thousands of servers can be spun up and configured through code checked into version control. In the mobile first, cloud first world, continuity is not only available, but expected.
Visual Studio Team Services provides a strong foundation for a software team to dip their code into DevOps. Shifting development methodology is always uneasy, therefore incremental adoption is often recommended for an evolving team. Several techniques have been published on how to establish a DevOps culture, such as The Three Ways, and Incremental DevOps. While discovering how your team can incorporate these practices, beginning by adopting continuous integration (CI) and delivery (CD) may help to build the DevOps environment.
Continuous Delivery is the practice of automating a path to allow checked-in code to roll through build, test and deployment while maintaining guidance from QA and IT teams. By creating this path, especially with the organizational tools in Visual Studio Team Services, the foundation is laid for every member of a project to collaborate, communicate, and ultimately to contribute to the value delivered to the end users.
CD can sometimes stand for Continuous Deployment, but interchanging these terms is dangerous. Continuous Deployment means that the automated path pushes code all the way into production. Because automated testing is imperfect, skipping manual QA approval after exploratory smoke tests can lead to trouble. In the scope of DevOps, Continuous Delivery fits better, utilizing the collaboration between fine-toothed QA and code committing developers to ensure that an application in staging is ready for production.
Delivering faster requires a more efficient process by either abstracting or automating in order to reduce the work required to produce the same result. The end product is never for the computers, software is made for and created by people. The future development trends will continue to push away from machine language towards our intraspecies communication. Manually “compiling” and “publishing” will soon be as outdated as waiting in line with your punch cards to run a program on the community mainframe.
Software development is an industrial art growing at a snail’s pace. It does not follow Moore’s law nor is there “One True Path”. Programming languages are building upon decades of binary layers abstracting functional patterns from the latest paradigms. Businesses must continue to match their methodology to the newest tools in a race to bring concepts to computation. When deciding how to manage your business development, the Artefact Group’s post-agile manifesto puts it simply:
If it works, do it. If it doesn’t, don’t.