Editorial Note: VSTS has been renamed to AzureDevOps.
Any non-trivial software development that is being done by a team of developers requires certain support for successful collaboration. This support is in the form of versioning the code, creating the components and their releases, managing the process of development, and managing issues that may block such software development.
These support activities are provided by services and software that is either individually installed, or available enterprise wide. In 2006, Microsoft provided an integrated set of services to support version control, build process and process management. That product popular is Microsoft Team Foundation Server (TFS). It is an on premises installed product which provides development support for the entire organization.
Over the years, similar to the the other sectors of the IT industry, development activities are moving to the cloud. Microsoft, which is one of the major vendors of cloud computing with the brand Azure, realized the importance of this migration early on. It started offering the same set of services it was offering on-premises (TFS), now from Azure cloud. After many changes in the brand name of these services, Microsoft has zeroed it down to “Microsoft Visual Studio Team Services (VSTS)” (previously known as Visual Studio Online).
Advantages of VSTS
By having these services in the cloud, Microsoft has relieved us of the responsibility to install and maintain Team Foundation Server on our premises. It is also offering these services with optimal hardware so that our infrastructure cost is avoided. Since the VSTS services are available on the internet, they can be easily used by teams that are distributed across multiple locations, without having any additional cost of VPN and overheads of security.
Create your VSTS Account
Anyone who has Microsoft credentials can create an account on VSTS. If you do not have these credentials, you can simply create one similar to a new outlook account. You can create your VSTS account for free and add four more team members without incurring any cost. Moreover, if any team member has an MSDN Subscription, then it is an added benefit as MSDN subscribers are not counted in the four accounts. Accounts that have more than 5 team members (that are not MSDN Subscribers) are charged. To create such an account, open the URL https://www.visualstudio.com and then click on Get Started for Free button.
Figure 1: Getting started with VSTS
You will need to provide your Microsoft credentials followed by a name for your VSTS account, a name for your first project, mode of version control for that project (for the time being you may select Team Foundation Version Control), the process you want to adopt for that project (Agile or Scrum or CMMI) and optionally change the region where your data should be kept.
Figure 2: Create VSTS Account
Your VSTS account will be created and a new team project will be added to the account. I just mentioned a phrase ‘Team Project’. Let us first understand that concept.
Understanding Team Project
Team Project is a logical container for all the entities related to the unit of software that you are developing. For example, if a team of developers is developing an employee management system for my company SSGS, then that team, requirements for that software, tasks, code, build definitions, rules of working together etc. is all put into a logical container called the Team Project. It is given a name, in our case say, ‘SSGS EMS’ and it also works as filtering criteria for queries and reports.
Services offered under VSTS
Let us now check the various services that VSTS offers.
Source and Version Control:
This service facilitates the following features:
1. Multiple team members can work on the same code without a chaos of multiple copies of code on the server. Teams can work collaboratively to integrate various code files into a coherent component.
2. Creation of multiple versions of code which can be accessed in parallel. While some team members are working on current release, a few other team members can start working on the code for next release without affecting each other’s code.
3. Store snapshots of code that is called ‘Labels’ so that it can be revisited any time in future.
4. Secure the code in such a way that un-authorized persons cannot access that code.
5. Make code available to the build service so that binaries can be compiled out of that code.
Figure 3: Code under VSTS Source and Version Control Service
VSTS has two modes for source and version control. A traditional mode is centralized repository where code created by many developers is stored at the server. This mode is also called as Team Foundation Version Control. A new decentralized or distributed version control service called Git is also integrated with VSTS. This allows each developer to keep his / her own repository of code and merge those with others as and when required. We can set one mode as default mode for our team project. We can also add repositories that are in different mode than the default mode, for the same repository.
Operations in Team Foundation Version Control:
Check-out: This operation informs VSTS that you intend to edit the code that is targeted by this operation. VSTS allows multiple team members to check-out the same code at the same time, and then provides the tools for doing conflict resolution.
Get Latest: Transfers the latest versions of requested files to you if they do not exist with you.
Get Specific Version: Transfers the files of requested version to you if files of that version do not exist with you.
Check-in: This operation transfers the files that you have edited since the last check-in to VSTS, and creates a new version of those files. It also creates a data structure called ChangeSet that has collective information about those files, notes and comments that you may have added with the check-in operation. Created Change-Set is given a unique ID.
Operations in Git supported by VSTS:
Clone Repository: This operation clones the entire repository from a remote repository so that all versions of all files in that repository are now in your local repository.
Commit: When code is committed, a new version of it is created in the local repository.
Push: This operation shares your committed code with others in your team
Fetch: Downloads the code that is shared (Pushed) by other team members but does not apply that to your code.
Merge: Applies fetched code to your code
Pull: It is a combination of Fetch and Merge operations.
To know more about the VSTS Git feature browse the MSDN page https://www.visualstudio.com/en-us/docs/git/gitquickstart
Both of these lists are non-exhaustive, and there are many other operations like labelling, shelving, branching, merging, code review, pull request that I have not been able to provide details about. More information about these operations will covered in a separate article.
Build Management:
Build is a process that fetches a set of files that you want to compile together; usually from source control, and compiles them. It may optionally do some quality checks, execute unit tests, label the source files, copy output to a specified location and any other task that you may want to execute as part of that process. Build process is automated so that it can be recreated number of times without additional efforts and errors. It can be triggered automatically at a certain schedule, or against the event of check-in if needed.
VSTS provides an infrastructure in the cloud where the build process can execute. Build process requires certain prerequisites to run, and that is provided by an agent that needs to be installed on the computer where that build process is to run. We can use a hosted agent, which is the one that is provided by VSTS in the cloud, so that we need not create any infrastructure and install agent to run our build.
We can define as many build processes as we need. Each build definition is a tasks based workflow of various activities. Each task performs an activity using some tool like Visual Studio, unit test engine, PowerShell or even third party tools like SonarQube. These tools and their tasks should be installed on the computer where the build process is to run. When you install the agent, they are installed if they are available by default. Refer to https://marketplace.visualstudio.com/search?target=VSTS&category=Build%20and%20release&sortBy=Downloads to get more build tasks that you can install.
Figure 4: Build Definition
For each build definition, we can set an automation trigger. A very common trigger is Continuous Integration (CI). This trigger is used to start the build for every check-in that happens for any code that is part of the scope. Another common build automation trigger is scheduled build. This trigger starts the build at scheduled time on selected day(s) of the week.
Figure 5: Continuous Integration Trigger
When using hosted build agent, we do not have access to the file system of the computer on which that agent is running. Storing the output of the build (binaries and other related files) on a share on the file system is not a valid option in such cases. VSTS provides a feature called artefact for such outputs. We can create a named artefact which will represent the created output. We can browse that named artefact to ensure that the desired output is created by the build. Release management service can use that named artefact to deploy it to the destination server or Azure service.
Release Management Service (RM):
This service of VSTS offers the following features:
1. Automated deployment of built components to destination server or Azure services.
2. Multi-stage deployment either serially or in parallel. For example a product may have to be deployed first to Testing environments. After testing, it may have to be deployed to a staging server to check performance and do UAT. Finally it may have to be deployed to a production environment. RM can do these deployments automatically as configured one after the other.
3. Provide a workflow for authorization of deployment to the next stage. Extending my earlier example, it may be necessary that a team member authorizes deployment to staging environment when the testing is completed satisfactorily.
Figure 6: Release Definition with multiple environments
Release Management service uses the same agent that is used by the build service of VSTS. Similar to build definition, a release definition also is a tasks based workflow of activities. Those tasks in turn use commands, command scripts, DACPACs and PowerShell scripts in conjunction with WinRM for deployment of components to remote machines either to Azure or any other cloud.
Work Item Tracking Service:
This service supports the management of requirements, efforts, tests, bugs etc. and also facilitates teams to become agile. Work Item is a physical form of abstract entities in the project context that need to be tracked over a period of time. Candidate entities for work items are requirements, tasks, test cases, bugs, risks and many more. Every process that is supported by VSTS (through the canned process template that is to be used at the time of creating a team project) encapsulates set of appropriate work item types.
Work items have fields that store certain kind of data. Examples of fields are Title, Assigned To, Created Date, Description, Iteration etc. Values of these fields can be assigned at the time of creation, or later. Many of the fields also allow changing these values, as the details of that work item change. Work items also pass through many states. For example a bug may pass through the states of New when it is created to Active when triaging is done and it is accepted to be fixed, and then onwards to Resolved when a developer creates a bug fix, and finally to Closed when the tester accepts the bug fix as valid. These states and their allowed transitions are also part of the work item type definition.
Figure 7: Work Items on KANBAN board
Work items can be linked to each other to form a hierarchy. Such hierarchy will provide traceability and will also make the dependencies transparent. Work items may also have links to external artefacts like ChangeSets, Builds and any other document that may be available using a URI.
Figure 8: Work Items Hierarchy
Work items can be queried using a query designer that is provided as part of VSTS. This query designer can provide us results for queries that can be a flat list, or a tree of parent-child related work items, or work items related with complex relationships. These results are the filtered lists of work items with or without hierarchy.
Work item tracking service also provides us the tools for Agile planning and monitoring. It can facilitate building up a product backlog, set the team capacity, build a sprint backlog and validate it using capacity balancing tool. VSTS also has tools for showing burndown of efforts and an interactive task board.
Conclusion:
In this introduction to VSTS, I have given you an overview of the services that are currently available, who can use those and how they can be used. In the next articles, I intend to go deep into each service to show how they can be used effectively.
This article has been editorially reviewed by Suprotim Agarwal.
C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.
We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).
Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.
Click here to Explore the Table of Contents or Download Sample Chapters!
Was this article worth reading? Share it with fellow developers too. Thanks!
Subodh is a Trainer and consultant on Azure DevOps and Scrum. He has an experience of over 33 years in team management, training, consulting, sales, production, software development and deployment. He is an engineer from Pune University and has done his post-graduation from IIT, Madras. He is a Microsoft Most Valuable Professional (MVP) - Developer Technologies (Azure DevOps), Microsoft Certified Trainer (MCT), Microsoft Certified Azure DevOps Engineer Expert, Professional Scrum Developer and Professional Scrum Master (II). He has conducted more than 300 corporate trainings on Microsoft technologies in India, USA, Malaysia, Australia, New Zealand, Singapore, UAE, Philippines and Sri Lanka. He has also completed over 50 consulting assignments - some of which included entire Azure DevOps implementation for the organizations.
He has authored more than 85 tutorials on Azure DevOps, Scrum, TFS and VS ALM which are published on
www.dotnetcurry.com.Subodh is a regular speaker at Microsoft events including Partner Leadership Conclave.You can connect with him on
LinkedIn .