Chapter 2
Azure DevOps
Since Microsoft first introduced what would become Visual Studio Team System (VSTS) back in 2004 (code name Burton), development teams have begun improving the way they plan, track, and manage their software development projects. No longer are they tracking code changes in meaningfully named zip files or Microsoft Visual SourceSafe, bugs, and requirements in Microsoft Excel, and performing automated builds using batch files. Team Foundation Server, a component of VSTS, integrated those pillars of software development and even tossed in reporting so that everyone could stay informed. The game of software development had changed forever; it had gone professional. In this chapter, I will provide a brief history of Microsoft’s application lifecycle management (ALM) and DevOps products and introduce Azure DevOps Services, Azure DevOps Server, and Visual Studio.
A Brief History
In its first iteration, this stack of tools was marketed as only providing support for the software development lifecycle (SDLC). This lifecycle included everything to do with developing a software product, such as requirements, architecture, coding, testing, configuration management, and project management. In the subsequent release of VSTS 2008, Microsoft (and the rest of us) refactored its thinking to regard these tools as having much broader capabilities for supporting application lifecycle management (ALM). To further this point, Microsoft also added tools for database developers to the VSTS family. ALM includes everything that is part of the application lifecycle, not just development. ALM combines business management with software engineering. Scrum, or any other agile framework, process, or methodology, is encompassed by ALM.
With the 2010 version, Microsoft doubled down on their support for ALM. They introduced Microsoft Test Manager to allow teams to create and manage their testing effort. Hierarchical work items enabled a richer breakdown of the planned work. Product Backlog item (PBI) work items could now be linked to multiple child task work items. By using Lab Management, teams could configure environments of virtual machines and automate the build, deploy, test cycle against complex environments. It was during the 2010 product cycle that Microsoft gave us the first official Scrum process template, thus acknowledging and formalizing their support for Scrum. Also in 2010, the Microsoft Developer Division began development of a software-as-a-service (SaaS) offering based on Team Foundation Server.
The 2012 version continued the tradition of providing strong ALM tooling, especially in the area of agile (Scrum) planning and management capabilities. Feedback became a first-class concern with the introduction of Feedback Manager and storyboards. Microsoft also continued their migration of capabilities from desktop clients, like Team Explorer, to the browser. The web portal, Team Web Access, now included a team project landing page and rudimentary dashboard. The concept of a team was enhanced, allowing multiple teams per project—each with their own members, backlogs, and iterations. Scrum teams were given an interactive task board so that they could plan and track their tasks during a Sprint. Microsoft introduced their cloud-based Team Foundation Service preview, publicly revealing their intentions to start providing Team Foundation Server as a service.
In 2013 Microsoft introduced additional collaboration features such as portfolio management (hierarchical backlog levels), Kanban support, work item charts, and team rooms. Test management and execution continued to migrate from the Microsoft Test Manager desktop client to the browser, with the ability to create test plans, test suites, and test cases. Microsoft also saw the writing on the wall and started including Git support in both the Visual Studio client as well as Team Foundation Server. This reveals the world’s (including Microsoft’s) fascination with Git. Additionally, you could browse, comment on, diff, and view history of both Team Foundation Version Control (TFVC) as well as Git version control repositories. Release Management was finally added, due to Microsoft’s acquisition of the InRelease product from InCycle Software. On the cloud front, Microsoft officially released Visual Studio Online—their set of Azure-hosted development services. Microsoft would rename this product a few more times in the coming years.
The 2015 version continued to add polish to the team experience by allowing multiple, customizable dashboards and enhanced Kanban board capabilities. Additionally, more and more functionality was moved, or at least duplicated, from the Visual Studio IDE (Team Explorer) and Microsoft Test Manager to the web portal. It was clear that Microsoft saw the browser as the future of their ALM tools. Developers also got a new build system with a completely rewritten architecture—one that was not based on XAML. Team Foundation Server extensions continued to emerge on the Visual Studio Marketplace. Microsoft, in an attempt to remove the confusion about whether Visual Studio Online is an IDE in the cloud or a set of development services, renamed Visual Studio Online to Visual Studio Team Services—and VSTS was back—at least in acronym form!
By 2017, Microsoft had essentially stopped referring to ALM in its marketing materials, in lieu of the new, trendy term DevOps. As such, they continued to invest in more and more engineering features, such as code search, package management, as well as Git, build, and release improvements. Microsoft also continued to provide love to agile teams, with a new work item user experience, the ability to follow a work item, Kanban board live updates, as well as dashboard and widget improvements. Additional extension points meant that the community could inundate us with awesome extensions. Microsoft continued their cadence of updating the cloud-hosted Visual Studio Team Services every three weeks, and their on-premises Team Foundation Server about every 3-4 months with new features and bug fixes.
The year 2018 saw many additional features added/moved to the web portal from the venerable desktop clients. More papercuts were fixed and small improvements made to the agile experience, including a new work item form with an optimized look and feel for mobile devices. The bulk of improvements applied to the engineering tools, however. Code repositories, building, testing, and releasing saw many enhancements. This version also saw the further deprecation and removal of features that had become antiquated or irrelevant, and/or didn’t align with Microsoft’s roadmap. Also, this was the first time that Team Foundation Server was released without a “companion” version of Visual Studio. This wasn’t a big deal, but it just felt weird.
Microsoft renamed things again in 2019. The cloud-based Visual Studio Team Services was renamed Azure DevOps Services and the on-premises Team Foundation Server was renamed Azure DevOps Server. Although the industry wasn’t ready for yet another name, when the dust settled, it was nice to be able to refer to both the on-premises and cloud-based products as simply Azure DevOps. Finally having “DevOps” in the product name made it easier to demonstrate to the industry that, yes, Microsoft did have a DevOps solution. At the same time, Microsoft also defined and named the Azure DevOps services themselves: Azure Boards, Azure Test Plans, Azure Repos, Azure Pipelines, and Azure Artifacts.
Over the past 15 years, the SDLC, then ALM, and now DevOps tools have proven themselves capable of helping organizations manage the entire lifespan of their application development, reduce their cycle times, and eliminate waste. Azure DevOps does this by integrating different teams, platforms, and activities with the goal of enabling a continuous flow of business value, which includes every aspect of the application’s lifecycle, from when it first begins as an idea or need, all the way to its retirement. This lifecycle can include initiating the project, defining and refining requirements, design, coding, testing, packaging, releasing, deploying, and even operating, including monitoring.
In today’s fast-paced, startup, open source, mobile, app store ecosystem, the lifecycle of a software idea can be quite short. Scrum can be used to start quickly and deliver the vision incrementally, and Azure DevOps can be used to safeguard that work and the quality of the product. Both can reduce risk and waste. On the other hand, some organizations and products have a very long lifecycle, such as line-of-business (LOB) systems. These may need more emphasis on governance and operations and less on time to market. Regardless, the tools you will learn about in Azure DevOps support both ends of this spectrum.
In this chapter, I will look more closely at the various Azure DevOps services, always with a focus on those tools that can empower a Scrum Team to deliver value continuously. I will also devote Chapter 3 to Azure Boards and Chapter 7 to Azure Test Plans.
Delivering Continuous Value
For the most part, our industry has emerged from building one-tier, two-tier, and n-tier applications that are internally managed by an organization. On the whole, we now build richer, more immersive applications powered by continuous services. These applications are delivered across a broad spectrum of connected systems—from mobile devices to traditional laptop and desktop computers. In parallel with this trend, software development practices are continuing to emerge that seek to enable a continuous flow of value.
Note The term flow, which you will learn about in Chapter 9, is the movement and delivery of customer value through a process. Regardless of the underlying goals and motivations, teams want fast, smooth flow that creates value quickly while minimizing risk and avoiding cost of delay, and to do so in a predictable fashion.
Business conditions are demanding shorter and shorter cycle times, rapidly realizing the concept released to market. This is putting dramatic pressure on organizations and teams to deliver value rapidly and continuously without lowering quality or generating lethal technical debt. If your organization and team are not experiencing this yet, then you will be soon or you will be working for a competitor who is. In order to compete, companies must broaden their focus from merely improving their development practices to improving the entire value stream. This reality has been the impetus behind the main themes of the DevOps movement, as well as the tools in Azure DevOps.
Smell It’s a smell when management expects that a tool (by itself) will be able to radically reduce cycle times or enable continuous delivery of value. It takes a combination of improving the existing process and practices as well as solid tooling. In fact, sometimes it takes the removal of a tool. A few years ago, one of my clients asked how establishing a specific branching strategy in Team Foundation Server would help them reduce their cycle time from 47 days to 7 days. I told them it wouldn’t and that if they pursued this course of action, it would most likely increase their cycle time. The solution (as it almost always is) would be for them to radically change their processes, practices, and (most importantly) their culture to achieve such an extreme degree of improvement.
Here are the main themes for the tools in Azure DevOps:
■ Agile software development Agile techniques and methods, such as Scrum, have helped software development teams improve dramatically in the past two decades. They have fundamentally transformed the industry consensus as to the right way to develop software by implementing inspection and adaptation and shortening feedback loops. Azure DevOps continues to add and improve its tooling to support agile software development, regardless of the flavor of framework, methodology, or process you are following.
■ Quality enablement A shift away from traditional quality control (post-development testing) toward ensuring that quality is defined and delivered as a first-class requirement—even before coding begins.
■ DevOps An integration of development and operations to enable faster feedback cycles, reductions in time to resolve bugs and outages, and a focus on pushing smaller packages of functionality into production more frequently.
■ Continuous delivery (CD) The rapid flow of incremental business value through the entire technical value stream. CD is made possible through agile methods, quality enablement, proper tooling, and other practices.
The continuous delivery of value requires a tuned orchestration of people, practices, and tool usage. This goes beyond just managing changes to code using version control. The full value of the tools in Azure DevOps cannot be realized unless work items, version control, builds, tests, and releases are used correctly. In other words, your team should consider using all of the Azure DevOps services together, not separately. This orchestration, resulting in a continuous delivery of value, can be seen in Figure 2-1.
FIGURE 2-1 Achieving a continuous delivery of value.
When people view a diagram like Figure 2-1, they don’t usually think about subsequent cycles. They tend to step through a diagram like this once, understand each phase, and file it away. In reality, teams rarely begin with a greenfield environment. Startups tend to be the exception and, even then, that field turns brown very quickly. After working software is deployed, it affects every part of the cycle. Maintenance work becomes integrated into the Product Backlog alongside new features and ideas. Needless to say, it can be challenging to build a responsive, modern application on top of existing technology, manage operations, and try to deliver value while keeping the existing application up and running.
Let’s break down software delivery into three parts: plan, develop, and deliver. The Scrum framework helps with the planning part by instructing us on how to plan and manage work. Smart developers using modern tools and practices have no problem with developing the product. It’s the delivery part of that value stream that has been the challenge—mostly because of impediments beyond the control of the team. For example, team members may deliver a potentially releasable Increment, but operations struggle to get it deployed and running in as timely a fashion. This is just one of many potential impediments.
Current agile and lean concepts have helped to improve the way that teams deliver software. As an industry we’re getting better, but many gaps still exist. Fortunately, the tools in Azure DevOps, when employed by a Professional Scrum Team, can close these gaps.
Delivering the product is supported by a variety of functions that need to be integrated carefully in order to make delivery happen. For example, many organizations still consider quality an afterthought—something tested into a product after the developers are done. This bolting-on of last-minute fixes doesn’t improve quality and can actually produce a suboptimal product and, worse, generate technical debt that must be repaid (with interest) at some point.
The list of impediments keeping a team from achieving continuous delivery can go on and on. The only solution is for such a team to start inspecting their impediments and removing them, one at a time on a regular basis. Teams must be relentless and take every opportunity to improve their practices to improve the entire value stream. Doing so may include impediments that exist beyond the Scrum Team. Organizations must give these teams the freedom and authority to make these changes and do what they can to ensure those changes persist.
The combination of Professional Scrum and Azure DevOps is powerful. High-performance Professional Scrum Teams know how to apply agile practices while using tools so that the net result is effective. Through constant inspection and adaptation, waste is identified and eliminated. This may mean starting to use a new feature in the tool or stopping the use of a wasteful feature. Teams that blindly use new, shiny tools without thinking and experimenting are just asking for a drop in productivity. At the same time, teams that think that all planning and management tools are wasteful are also missing the boat. For teams that only use manual whiteboards and sticky notes to manage their work, I hope they never have to “roll back” their task board or recover from a disaster, like a new janitor accidentally cleaning that board. In addition, these teams cannot trace PBIs to source code to releases, never mind the inability to obtain any metrics relating to their flow.
Azure DevOps Services
In September 2018, Microsoft renamed Visual Studio Team Services and Team Foundation Server to Azure DevOps Services and Azure DevOps Server, respectively. With this new Azure DevOps name, Microsoft now had an official “DevOps” tool, or suite of tools—even though they always did. Now it was official. Now it was in the name. At the same time, they productized the individual services, as you can see in Figure 2-2. For example, instead of referring to “the agile tools inside Visual Studio Team Services,” people could now just refer to “Azure Boards.” It made it easier to have a conversation with existing users as well as others in the marketplace who were looking to leave their existing DevOps tools.
FIGURE 2-2 Enabling the various Azure DevOps services.
Taken together, the various Azure DevOps services provide an integrated DevOps solution that enables software development teams of all sizes to quickly deliver continuous, high-quality value. It provides both individual developers, an entire Scrum Team, or a Nexus of Scrum Teams with the ability to build business and consumer applications—on any platform, using any language.
Note Nexus is a simple framework that implements Scrum at scale across multiple teams to deliver a single integrated product. It can be applied to 3–9 Scrum Teams that are working in a common development environment and are focused on producing a combined increment every Sprint with minimal dependencies. You can download and read the Nexus Guide at www.scrum.org/resources/scaling-scrum. I will cover Nexus in more detail in Chapter 11 , “Scaled Professional Scrum.”
Azure DevOps assists everyone on the team in collaborating more effectively while building and sharing institutional knowledge. What’s more, artifacts and data from each of the services are aggregated, stored, and made available for querying and reporting. Analytics provides a concise data model and reporting platform that you can use to answer quantitative questions about the past or present state of your product or process. These queries and reports can provide real-time transparency and traceability, as well as historical trending of the progress and quality of both the product and process.
Software products are developed and delivered by people, not by processes, practices, or tools. Processes and practices need to adapt and evolve to accommodate changes in scope and culture. Azure DevOps provides an environment that can be adapted to a Scrum Team’s uniqueness and enhances it with proven agile practices that can be adopted at any pace. Over time, the team, as well as the organization, will become more productive by using these tools. This assumes that the culture allows this to happen. “Organizational gravity,” as it’s been referred to, can easily pull the team back into dysfunctional, waterfall behaviors if overt effort is not made to protect and sustain those improvements. I lovingly refer to organizations that take a waterfall approach to develop complex products as “waterfallian.”
Professional Scrum involves more than just coding. It involves the whole range of planning, testing, and management activities. Azure DevOps enables a Scrum Team to incrementally adopt proven practices with out-of-the-box support for lightweight requirements, backlog management, task boards, code reviews, continuous integration and deployment, continuous feedback, and more.
These tools help connect the Scrum Team and stakeholders while helping optimize the development process and reduce risk. The Scrum Team can focus on delivering value and receiving feedback from stakeholders. The tools can enable this cooperation directly or indirectly so that transparency is maximized and expectations are met.
I will now take a quick look at each of the services that constitute Azure DevOps.
Azure Boards
Azure Boards is the service that helps teams and organizations plan, track, and manage their work. In other words, it’s the service that teams use to visualize and manage their software development efforts. It provides a rich set of capabilities, including native support for Scrum and Kanban boards, customizable dashboards, and integrated reporting.
The Azure Boards service provides access to work items and related features like these:
■ Product Backlog View and manage your Scrum Team’s Product Backlog items in an ordered list, as in Figure 2-3.
FIGURE 2-3 Backlogs page on the Azure Boards hub.
■ Sprint Planning Drag and drop items from the Product Backlog to the Sprint Backlog to create the forecast and plan the Sprint.
■ Sprint Backlog View and manage the forecasted work and the plan for the current Sprint.
■ Task board View and manage the task work items that constitute the plan for delivering the forecasted Product Backlog items.
■ Kanban board Visualize and manage your team’s workflow.
■ Queries and charts Create work item queries and charts for reporting or bulk editing.
I will dive deeper into Azure Boards in Chapter 3, “Azure Boards.”
Azure Repos
Azure Repos is the service that provides version control tools that teams can use for collaborating and managing changes to their code and other files. Azure Repos supports Git in a standard way so that teams can use whatever clients and tools they choose, such as Git for Windows, Git for Mac, third-party Git services, and tools such as Visual Studio and Visual Studio Code.
The Azure Repos service provides features like these:
■ Browser-based Easily visualize and manage repositories, branches, commits, pushes, and tags directly in the browser, as in Figure 2-4.
FIGURE 2-4 Files page on the Azure Repos hub.
■ Multiple repositories Create, import, and manage one or more repository per project.
■ Pull requests Review code, add comments, and vote on changes prior to it being pulled into a branch.
■ Branch policies Require pull requests, a minimum number of reviewers, linked work items, build validation, and other quality practices to further protect branches from low-quality changes.
■ Team Foundation Version Control (TFVC) Support for the legacy, centralized version control until you are ready to migrate to Git.
I will not be covering Azure Repos in any depth in this book.
Azure Pipelines
Azure Pipelines is the service that a team can use to automatically build, test, and deploy their code. Azure Pipelines can pull code from many different repositories, as well as build almost any application type in almost any language and deploy it to almost any target platform. Through the use of visual designers or a straight coding experience, teams can create complex pipelines to automate the orchestration drudgery once and for all.
The Azure Pipelines service provides build and release features like these:
■ Robust pipelines Pick from hundreds of tasks available in Azure Pipelines and the Azure DevOps Marketplace to build, test, package, deploy, or perform other custom functions, as in Figure 2-5.
FIGURE 2-5 Pipelines page on the Azure Pipelines hub.
■ Hosted agents Use convenient, Microsoft-hosted agents on Windows, Unix, or macOS to build, test, and deploy applications as needed.
■ Continuous Integration Trigger a pipeline to run a build whenever a code change is detected.
■ Continuous Delivery Trigger a pipeline to create and deploy a release when a build successfully completes.
■ Configuration as Code Use YAML files to configure the pipelines, placing them under version control alongside code.
■ Queries and charts Use analytics to view pipeline reports and dashboard widgets such as duration, test failures, and pass rate reports.
I will not be covering Azure Pipelines in any depth in this book.
Azure Test Plans
Azure Test Plans is the service that helps teams and organizations plan, manage, and execute their testing efforts. It supports teams of all sizes and types regardless of whether they are practicing manual, automated, or exploratory testing to drive collaboration and quality. The browser-based experience enables defining, executing, and charting the results of a team’s tests.
The Azure Test Plans service provides access to testing-related work items and related features like these:
■ Test Case Management Organize your tests into test plans, test suites, and test cases, as in Figure 2-6.
FIGURE 2-6 Executing a manual test in the Azure Test Plans hub.
■ Manual Testing Specify the specific steps and expected results in a test case to instruct the person executing the test and also to collect artifacts and telemetry of the test run.
■ Automated Testing Select a pipeline and test assembly to automatically run the automated test associated with the test case.
■ Exploratory Testing Use the browser-based extension to track your exploratory testing session and also to collect artifacts and telemetry.
■ Charts and reports Use the charts, runs, and progress reports to track quality metrics related to the testing effort.
I will dive deeper into Azure Test Plans in Chapter 7, “Planning with Tests.”
Azure Artifacts
Azure Artifacts is the service that a team can use to create and share Maven, npm, NuGet, and Python package feeds from public and private sources. Formerly known as package management, Azure Artifacts can be fully integrated with Azure Pipelines to pull from or publish to, enabling the ultimate in reusability. By sharing binary packages, and not source code, teams limit complexity as well as the number of dependencies.
The Azure Artifacts service provides useful features like these:
■ Upstream sources Enable a single feed to store both the packages that your team produces and the packages your team consumes from other feeds in your organization as well as from “remote feeds” such as npmjs.com, nuget.org, Maven Central, and PyPI, as in Figure 2-7.
FIGURE 2-7 Specify upstream sources in Azure Artifacts.
■ Release views Filter the feed to a subset of packages that meet criteria defined by the view.
■ Universal packages Store one or more files together in a single unit that has a name and a version.
■ Immutability After a particular version of a package is published to a feed, that version number is permanently reserved.
I will not be covering Azure Artifacts in any depth in this book.
Azure DevOps Server
When Microsoft renamed Visual Studio Team Services to Azure DevOps Services in 2019, they also renamed Team Foundation Server to Azure DevOps Server. Azure DevOps Server is the on-premises version of the cloud-hosted Azure DevOps Services. It is updated regularly, including major updates every year or two. Both offerings provide the same great integrated, collaborative environment that supports the essential services, such as agile tools for work planning and tracking, Git, continuous integration, continuous delivery, test planning and execution, and package feeds.
Whereas Azure DevOps Services is an Azure-hosted SaaS offering, Azure DevOps Server is an on-premises offering that’s built on SQL Server. Companies usually choose the on-premises Azure DevOps Server when they want their data to stay within their network.
Tip Although both Azure DevOps offerings provide the same essential services, it is recommended that organizations and teams use the cloud-hosted Azure DevOps Services. Not only does the cloud-hosted offering provide a scalable, reliable, and globally available hosted service, but it’s backed by a 99.9 percent SLA, monitored by Microsoft’s 24/7 operations team and available in local data centers around the world. Your organization can transition from capital expenditures (servers and access licenses) to operational expenditures (subscriptions). It also means that you can give your administrator a break from having to continually upgrade, configure, and back up your on-premises instance. For more details on Azure DevOps Services data protection, visit https://aka.ms/AzureDevOpsSecurity. Only in situations where data cannot be stored offsite—for compliance or SLA reasons—should you consider Azure DevOps Server.
For the examples and guidance in this book, I will be talking about and using Azure DevOps Services. If your organization or team is using a current version of Azure DevOps Server, you should be fine following along with the guidance. If you are using an older Team Foundation Server instance, it’s time to upgrade—and not just for the sake of the examples in this book!
Migrating to Azure DevOps Services
If your organization or team is using the on-premises Azure DevOps Server or the legacy Team Foundation Server, you will likely want to migrate to the cloud-based Azure DevOps Services. Personally, I think you should do so as soon as possible so that the flow of features and bug fixes comes much more quickly—and without effort on your part.
When your team decides to make the move to the cloud, you have a couple of choices:
■ Manually Start fresh by creating a new organization and new projects and by manually bringing over the relevant work items, code, and pipeline definitions from your existing environment.
■ Using the Data Migration Tool Use the migration tool created by Microsoft to perform a high-fidelity migration of an entire project collection.
A flexible way to move to Azure DevOps Services is to manually copy your most important assets and start relatively fresh. You can be picky about the projects you bring over, as well as the assets in each project. Unfortunately, this approach can be difficult if your team is in the middle of a large project. Advance planning can help. Open source tools or tools from the Azure DevOps Marketplace that leverage the public APIs can be helpful as well.
Another option is to use the high-fidelity data migration tool created and maintained by the Azure DevOps product team at Microsoft. This tool operates at the SQL Server database level so that it can provide a high-consistency migration to Azure DevOps Services. In other words, you will get everything migrated, as is. This is the best option if you want to move your existing on-premises instance to the cloud in its entirety. You may have to upgrade your existing Team Foundation Server or Azure DevOps Server instance to the latest version before using this migration tool. You can find requirements and more details in a downloadable Migration Guide available at https://aka.ms/AzureDevOpsImport.
Tip When migrating to Azure DevOps Services either manually or by leveraging tooling, your team should consider abandoning Team Foundation Version Control (TFVC) and moving to Git. If you haven’t heard by now, Git has become the standard version control tool in our industry. It’s what Microsoft uses internally and so should you and your team. Also, it’s clear that all Azure Repos and Azure Pipelines innovation will focus on Git and that TFVC is on life support.
Visual Studio
A number of different client applications and tools can connect to and interact with Azure DevOps. Many are provided by Microsoft as well as the Azure DevOps partners and community. Even more can be created using Azure DevOps public APIs. The most popular clients from Microsoft are Visual Studio, Visual Studio Code, and Excel. I will cover Excel in Chapter 5, “The Product Backlog.”
Many different audiences use Visual Studio. They differ depending on the makeup of the team, the software products they are building, and the speed at which they deliver and maintain those products. To support various audiences, Visual Studio is available in different editions. The editions range in price from free (Community edition) to thousands of dollars (Enterprise edition). For a thorough comparison of the Visual Studio editions, visit https://visualstudio.microsoft.com/vs/compare.
Smell It’s a smell when I see members of a professional software development team using the Community edition of Visual Studio. Although it is functionally equivalent to the Professional edition and the (free) price is tempting to management, it tends to reflect their inability to value what the team does or how they do it. This is not to mention the fact that the Community edition’s EULA disallows enterprise organizational users from using it for developing or testing—except for a narrow list of situations. It also could be that the Community edition was temporarily installed for evaluation, training, or experimentation purposes, which are valid use cases.
All Visual Studio editions include the coding and testing tools that most teams need to develop, analyze, debug, test, collaborate, and deploy modern applications in a number of languages on a number of platforms. Each installation of Visual Studio includes Team Explorer, which is a plug-in that connects Visual Studio to projects in Azure DevOps Services (or Azure DevOps Server). It allows you to manage source code, work items, and other artifacts. The operations available to you depend on which version control system—Git or TFVC—was selected when the project was created. You can see Team Explorer in Figure 2-8.
FIGURE 2-8 Here, Visual Studio Team Explorer is connected to the Fabrikam project.
Fabrikam Fiber Case Study
Most Developers on the Fabrikam Fiber Scrum Team have a Visual Studio Professional edition subscription, which allows them to develop, debug, and test as they progress through the Sprint. A couple of Developers, however, have a Visual Studio Enterprise edition subscription. They needed some more advanced features, such as IntelliTrace, Microsoft Fakes, and Live Unit Testing. Because Paula (the Product Owner) and Scott (the Scrum Master) aren’t involved in the actual development effort, they won’t need Visual Studio. Instead, they have chosen to interact with Azure DevOps using a browser, Excel, and Microsoft Power BI Desktop.
Visual Studio is not the only integrated development environment (IDE) that can connect to Azure DevOps. A number of other IDEs can interact with Azure DevOps using plug-ins, such as these:
■ Visual Studio Code Use the Azure DevOps extension to connect to Azure DevOps Services to monitor builds and manage pull requests and work items.
■ Team Explorer Everywhere Install a plug-in for Eclipse to connect to and interact with Azure DevOps Services or Azure DevOps Server.
■ Android Studio Access and manage Azure DevOps Services or Azure DevOps Server Git repositories by installing the plug-in for Android Studio.
■ IntelliJ Access and manage Azure DevOps Services or Azure DevOps Server Git repositories by installing the plug-in for IntelliJ IDEA.
■ Visual Studio for Mac No plug-in or extension is required to connect to and interact with Azure DevOps Services or Azure DevOps Server Git repositories.
Visual Studio Subscriptions
The preferred way to obtain Visual Studio and access to Azure DevOps is through a Visual Studio subscription. Formerly known as MSDN subscriptions, they enhance an organization or team’s investments by providing a comprehensive set of resources to create, deploy, and manage applications on most platforms and devices, including Android, iOS, Linux, macOS, Windows, web, and the cloud. Subscriptions also provide a cost-effective way for organizations to obtain software, services, training, and other resources for your development and testing needs.
Several Visual Studio subscription options are available:
■ Cloud subscription Allows you to essentially rent Visual Studio, Azure DevOps, and the subscriber benefits you need without a long-term contract
■ Standard subscription The familiar subscription model where you are buying Visual Studio and not simply renting like in the cloud subscription
■ Standalone license A one-time purchase of Visual Studio without access to major version upgrades or access to Azure DevOps
For most organizations, the standard subscription model of Professional or Enterprise edition makes the most sense. Both provide the latest versions of Visual Studio, with product updates for as long as the subscription is active. Both also provide access to Azure DevOps Services or Azure DevOps Server. Professional edition provides access to the basic features of all Azure DevOps services except for Azure Test Plans. Enterprise edition provides access to everything. For more information on the various subscription models, visit https://visualstudio.microsoft.com/vs/pricing-details.
The cloud subscriptions are particularly interesting because they allow the renting of Visual Studio and Azure DevOps on a month-to-month basis. Organizations and teams can now start and stop projects whenever they need, with flexibility and the convenience of having the development tools consolidated on the same bill with other Microsoft Azure cloud services such as virtual machines and storage. Although an annual cloud subscription may cost less than a perpetual license, the licensing rights end when you stop paying for the subscription. In other words, there is no perpetual use rights allowing you to continue using Visual Studio after the subscription has expired.
Note Speaking of as-needed subscriptions, Microsoft also offers Visual Studio Online, a cloud-powered development environment for long- or short-term projects. You can work with these environments from Visual Studio, Visual Studio Code, or a browser-based editor. There is support for Git repos, extensions, and a built-in command-line interface so that you can edit, run, and debug your applications from any device. For more information on Visual Studio Online, visit https://online.visualstudio.com.
Azure DevOps Access Levels
Access levels grant or restrict access to select features in the web portal. The level of access you have is directly related to the type of license you have purchased. An administrator will manage who can access the Azure DevOps Services organization (or the Azure DevOps Server) by adding them as users, and also selecting their access level and permission.
Here are the supported access levels:
■ Stakeholder Provides partial access to features. Can be assigned to an unlimited number of users for free without the need for a license or subscription.
■ Basic Provides access to most features. Assigned to users with a Basic license or Visual Studio Professional subscription.
■ Basic + Test Plans Provides access to all of the Basic features plus those in Azure Test Plans. Assigned to users with a Basic + Test Plans license or Visual Studio Enterprise, Visual Studio Test Professional, or MSDN Platforms subscription.
There is also a Visual Studio subscription access level, which will automatically select the correct set of features based on the user’s type of Visual Studio subscription. The system recognizes the user’s subscription—Visual Studio Enterprise, Visual Studio Professional, Visual Studio Test Professional, or MSDN Platforms—and enables any other features that are included in their subscription level. These access levels will apply in each Azure DevOps organization in which that user is a member, whether they created the organization or were added by someone else.
Note Access levels are not the same as access or permissions. Access indicates that a particular user can sign into Azure DevOps and, at a minimum, view information. Access levels grant or restrict access to select features. They enable administrators to provide their users with access to the features they need and pay only for those features. Permissions, granted through security groups, provide or restrict users from performing specific tasks in Azure DevOps. Administrators need to understand each of these terms and how they relate to each other.
Each Azure DevOps Services organization gets five Basic licenses for free, which means that five users will be able to use Azure Boards, Azure Repos, Azure Pipelines, and Azure Artifacts without having to purchase a license. If, for example, an organization has five developers with Visual Studio Professional subscriptions and five developers using Visual Studio Code (free), then the five free Basic licenses can be used by the Visual Studio Code developers.
Fabrikam Fiber Case Study
All Developers on the Fabrikam Fiber Scrum Team who have a Visual Studio subscription will automatically be assigned their set of features when they sign in to Azure DevOps Services. Those with Visual Studio Professional subscriptions will be assigned the Basic access level. Those with Visual Studio Enterprise will also be able to use Azure Test Plans as well as some other features, such as self-hosted pipelines. Paula (the Product Owner) and Scott (the Scrum Master) will each use one of the five free Basic licenses to access Azure DevOps Services. They will consider upgrading to the Test Plans license if they start to become more involved in testing and using Azure Test Plans.
Stakeholder Access
Stakeholders are users with free but limited access to the features in Azure DevOps. The Stakeholder access level allows users to add and modify work items, manage build and release pipelines, and view dashboards. They can also check project status and provide direction, feedback, feature ideas, and business alignment to a team.
If a stakeholder needs access a feature that supports the daily work of the Scrum Team, they should have at least Basic access, if not Basic + Test Plans. This might include them needing to change the priority of an item within a backlog or creating queries or charts. If a stakeholder needs to perform these tasks, or even access code, tests, builds, or releases, then this would, according to Scrum’s definition, make them a Scrum Team member and no longer a stakeholder. Regardless, they would need a proper license and access level at that point.
Fabrikam Fiber Case Study
Paula (the Product Owner) has opted to give certain users and managers Stakeholder access. Some of those individuals are a member of the Readers permission group and cannot change any information. In other cases, where there has been a history of collaboration and trust, those stakeholders have been added to the Contributors permission group, allowing them to directly add and edit work items. Paula knows that this is actually a way to take the strain off the Scrum Team by having stakeholders (users) create and update their own Product Backlog items.
GitHub and the Future
In 2018 Microsoft acquired GitHub, the world’s leading software development platform, for $7.5 billion. GitHub has over 40 million users and is at the heart of the open source community. The synergies between GitHub and Azure DevOps are numerous. Together, GitHub and Azure DevOps provide an end-to-end experience for development teams to easily collaborate, build, and release code.
It’s clear that Microsoft intends to make GitHub the home for every developer, not just open source developers. As such, they are intent on making integration with GitHub a first-class priority. To achieve this, Azure DevOps and GitHub share the same leadership, insights, and tooling inside Microsoft. It’s also apparent that Microsoft is investing in and innovating GitHub at a higher rate than they are in Azure DevOps.
This acquisition raises several questions about the future of Microsoft owning two separate but similar products with a growing overlap of features. For example, are we to use Azure Repos or GitHub repositories? Today the two platforms are not at feature parity, so the messaging is about integration, not migration. I suspect that will flip in the future.
One thing is certain—all professional software developers need to learn Git, whether or not they plan on using GitHub.
Chapter Retrospective
Here are the key concepts I covered in this chapter:
■ DevOps The union of people, process, and products to enable continuous delivery of value to our end users. Scrum is a process framework and fits within the boundaries of process-agnostic DevOps. High-performance Scrum Teams know that a balance of Scrum and DevOps practices are required to deliver complex software products efficiently.
■ Azure DevOps Microsoft’s suite of developer services that support teams to plan work, collaborate on code development, and build, test, and deploy applications.
■ Azure DevOps Services Microsoft’s cloud-based Azure DevOps offering. Formerly known as Team Foundation Service, Visual Studio Online, and Visual Studio Team Services.
■ Azure DevOps Server Microsoft’s on-premises Azure DevOps offering. Formerly known as Team Foundation Server.
■ Azure Boards The Azure DevOps service that helps teams and organizations plan, track, and manage their work.
■ Azure Repos The Azure DevOps service that provides version control tools that teams can use for collaborating and managing changes to their code and other files.
■ Azure Pipelines The Azure DevOps service that a team can use to automatically build, test, and deploy their code.
■ Azure Test Plans The Azure DevOps service that helps teams and organizations plan, manage, and execute their testing efforts.
■ Azure Artifacts The Azure DevOps service that a team can use to create and share Maven, npm, NuGet, and Python package feeds from public and private sources.
■ Visual Studio Subscription The preferred way of licensing Visual Studio and gaining access to Azure DevOps.
■ Access levels Used to grant or restrict access to select features in the web portal. Access levels are different from access and permissions, which restrict access to Azure DevOps and what tasks can be performed.
■ Stakeholder access Users with free but limited access to the features in Azure DevOps. If appropriate, stakeholders (in Scrum) can make use of the free Stakeholder access level to increase transparency.