DevOps is a hot topic right now. Many organizations are adopting this methodology as a means to deliver value faster and with fewer errors. Before we can dive into how to enable DevOps, we must first clarify its definition.
DevOps is the union of people, process, and products to enable continuous delivery of value to our end users. While each component of this definition is an important piece of DevOps, a solid set of tools is imperative to doing it effectively. Microsoft has a great offering in this area: TFS/VSTS. VSTS is a cloud-based offering for code development collaboration. TFS is simply the on-premises version of VSTS. These tools are everything you need to turn an idea into a working piece of software. In fact, VSTS versions, builds, and deploys itself every three weeks. In this article, we will discuss just a few things that Microsoft has implemented on its path to DevOps, and how VSTS and TFS can enable you and your organization to do the same.
For a comprehensive look at Microsoft’s seven-year journey to cloud cadence, watch this video from Aaron Bjork, a Principal Group Program Manager on the VSTS team. He discusses not only the steps that were taken at Microsoft, but what steps you can take to move forward with DevOps in your own organization.
A key piece of the Microsoft adoption of DevOps has been 1ES, or One Engineering System. With this system, development and testing are a unified piece of the build process as opposed to two separate pieces. Specifically, many teams within Microsoft are using VSTS to build, deploy, track, and version their code. This means that Microsoft has an opportunity to be its own first customer – the first ring of deployment for VSTS is internal, so they dogfood their own product before ever deploying to users.
This system means that developers are no longer throwing code over the wall to QA for testing. For example, within Microsoft’s VSTS team, there are no longer designated QA individuals or Dev individuals. Instead, each person is an engineer, responsible for developing and testing their code. Additionally, someone from each VSTS feature team is on call while the software is running. Because of these responsibilities, code was engineered in such a way that it would be easier to test, which resulted in an increase in quality.
Furthermore, with everyone on a team using the same engineering system, collaboration and integration is easier. Again, TFS/VSTS are everything you need to turn an idea into a working piece of software. With everyone using this system, everyone one the team was able to take advantage of tools such as the Kanban board, the build system, the integrated Git support, and so much more.
For a more in-depth look at 1ES, watch Martin Woodward, a Principal Group Program Manager on the VSTS team, discuss the end-to-end practices within Microsoft.
CI and CD are abbreviations for Continuous Integration and Continuous Delivery. Continuous Integration is the process of automating the build and testing of code every time a team member commits code to a shared repository. CI then kicks off Continuous Delivery. Continuous Delivery is the process to deploy, configure, and test from a build to production. Before this automation, it was very difficult to release quality code. This meant that errors were frequent, and users did not see value for a long time.
With TFS/VSTS, these processes are seamlessly integrated into your pipeline. Builds, tests, and deployments are all automated and have full traceability throughout. You can deploy code from any Git repository or service, including VSTS, GitHub, Subversion, or even your own private repo. Not only this, you can deploy anywhere. Yes, anywhere. With the hundreds of extensions in the Marketplace DMS is ready to help you get where you want to go. Sky is the limit.