Azure Devops
0 likes1,035 views
Azure DevOps Services is a cloud-hosted platform that provides scalable and globally available services with a high SLA. Azure DevOps Server is installed on-premises and runs on SQL Server, allowing customers to keep their data within their network. Key differences include simplified management and automatic updates with Services, while Server provides access to SQL Server reporting and on-premises data storage. Customers should consider their data security, management, and reporting needs to determine which platform best fits their requirements.
![-greeter "$(Build.RequestedFor)" -trigger "$(Build.Reason)"
Arguments
Finally, save the build pipeline.
Next you'll add the arguments to your script.
Param(
[string]$greeter,
[string]$trigger
)
Write-Host "Hello world" from $greeter
Write-Host Trigger: $trigger
1. Go to your Files in Azure Repos (the Code hub in the previous navigation and TFS).
2. Select the HelloWorld.ps1 file, and then Edit the file.
3. Change the script as follows:
4. Commit (save) the script.
Now you can see the results of your changes. Go to Azure Pipelines and select Queued. Notice under the
Queued or running section that a build is automatically triggered by the change that you committed.
Now you can see the results of your changes. Go to the Build and Release page and select Queued. Notice
under the Queued or running section that a build is automatically triggered by the change that you
committed.
1. Select the new build that was created and view its log.
2. Notice that the person who changed the code has their name printed in the greeting message. You also
see printed that this was a CI build.](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-55-638.jpg)
![Next steps
Param(
[string]$greeter,
[string]$trigger
)
Write-Host "Hello world" from $greeter
Write-Host Trigger: $trigger
Write-Host "Now that you've got CI/CD, you can automatically deploy your app every time your team
checks in code."
2. Commit (save) the script.
3. Select the Builds tab to see the build queued and run.
4. After the build is completed, select the Releases tab, open the new release, and then go to the Logs.
Your new code automatically is deployed in the QA stage, and then in the Production stage.
In many cases, you probably would want to edit the release pipeline so that the production deployment
happens only after some testing and approvals are in place. See Approvals and gates overview.
You've just learned how to create your first pipeline in Azure. Learn more about configuring pipelines in the
language of your choice:
.NET Core](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-62-638.jpg)
![az devops team list-member --team
[--org]
[--project]
[--skip]
[--top]
Parameters
Example
az devops team list-member --team "Fabrikam Team" --top 5 --output table
ID Name Email
------------------------------------ ----------------- --------------------------
3b5f0c34-4aec-4bf4-8708-1d36f0dbc468 Christie Church fabrikamfiber1@hotmail.com
19d9411e-9a34-45bb-b985-d24d9d87c0c9 Johnnie McLeod fabrikamfiber2@hotmail.com
8c8c7d32-6b1b-47f4-b2e9-30b477b5ab3d Chuck Reinhart fabrikamfiber3@hotmail.com
d291b0c4-a05c-4ea6-8df1-4b41d5f39eff Jamal Hartnett fabrikamfiber4@hotmail.com
bd30c189-db0f-4dd6-9418-5d8b41dc1754 Raisa Pokrovskaya fabrikamfiber5@hotmail.com
Show team details
az devops team show --team
[--org]
[--project]
Parameters
Example
command. To get started, see Get started with Azure DevOps CLI.
team: Required. Name or ID of the team to show.
org: Azure DevOps organization URL. You can configure the default organization using
az devops configure -d organization=ORG_URL . Required if not configured as default or picked up using
git config . Example: --org https://dev.azure.com/MyOrganizationName/ .
project: Name or ID of the project. You can configure the default project using
az devops configure -d project=NAME_OR_ID . Required if not configured as default or picked up using
git config .
skip: Optional. Number of members to skip.
top: Optional. Maximum number of members to return.
The following command lists the first five members of the team named Fabrikam Team and returns the details
in table format.
You can view details about a team in your organization with the az devops team show command. To get started,
see Get started with Azure DevOps CLI.
team: Required. Name or ID of the team to show.
org: Azure DevOps organization URL. You can configure the default organization using
az devops configure -d organization=ORG_URL . Required if not configured as default or picked up using
git config . Example: --org https://dev.azure.com/MyOrganizationName/ .
project: Name or ID of the project. You can configure the default project using
az devops configure -d project=NAME_OR_ID . Required if not configured as default or picked up using
git config .
The following command shows information about the team in your organization named Fabrikam Team and
returns the details in table format.](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-156-638.jpg)
![2. Open Work > Backlogs > Board.
3. Choose the board you want to configure and then choose Team settings to configure the board and
set general team settings.
For example, from the Kanban board ...
4. Choose a tab under Cards or Board to configure the cards and Kanban board columns and swimlanes.
![Common configuration dialog team settings]../.../boards/boards/media/customize-cards/common-
config-141.png)
Team administrators can fully customize the team's Kanban boards associated with the product and portfolio
backlogs. You configure a Kanban board by first defining the columns and WIP limits from the common
configuration dialog. For guidance, see Kanban basics.](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-165-638.jpg)
![Group rules with lesser permissions
Example 1: Group rule gives me more access
Example 2: Group rule gives me the same access
Work with GitHub
Problem
Solution
Other areas where permissions might be applied
tfssecurity /a+ Identity "81e4e4b5-bde0-4f2c-a7a5-4d25c2e8a81f" Read "Project Collection Valid Users"
ALLOW /collection:{collectionUrl}
tfssecurity /a- Identity "3c7a0a47-27b4-4def-8d42-aab9b405fc8a" Write n:"[Project1]Contributors"
DENY /collection:{collectionUrl}
Use the public sproc
Example usage: Use prc_pSetAccessControlEntry or prc_pRemoveAccessControlEntries to add or remove
ACEs directly from the security tables if TFSSecurity doesn't work for you.
For more information, see Use TFSSecurity to manage groups and permissions for Azure DevOps.
Group rule types get ranked in the following order: Subscriber > Basic + Test Plans > Basic > Stakeholder. Users
always get the best access level between all the group rules, including Visual Studio (VS) subscription.
See the following examples, showing how subscriber detection factors into group rules.
If I have a VS Pro subscription and I'm in a group rule that gives me Basic + Test Plans – what happens?
Expected: I get Basic + Test Plans because what the group rule gives me is greater than my subscription. Group
rule assignment always provides the greater access, rather than limiting access.
I have a Visual Studio Test Pro subscription and I'm in a group rule that gives me Basic + Test Plans – what
happens?
Expected: I get detected as a Visual Studio Test Pro subscriber, because the access is the same as the group rule.
I'm already paying for the Visual Studio Test Pro, so I don't want to pay again.
See the following troubleshooting information for when you're trying to deploy code in Azure DevOps with
GitHub.
You can't bring the rest of your team into the organization and project, despite adding them as organization and
project members. They receive emails but when signing in they receive an error 401.
You're likely signed into Azure DevOps with an incorrect identity. Complete the following steps.
1. Close all browsers, including browsers that aren't running Azure DevOps.
2. Open a private or incognito browsing session.
3. Go to the following URL: https://aka.ms/vssignout.
A message displays that says, "Sign out in progress." After you sign out, you're redirected to
dev.azure.microsoft.com.
4. Sign in to Azure DevOps again. Select your other identity.
Area path permissions](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-223-638.jpg)
![Traceability
What is a team?
A team is an organizing unit used
to support a number of team-
configurable tools to plan and
manage work and facilitate
collaboration.
Add team members
Add organizations-Azure DevOps
Services | Azure DevOps Server--
to a team to enable users to share
code, plan and track work, and
access other team assets and
resources.
Add a team
As your organization grows,
consider moving from your default
team of one to two or more teams
to support feature-focused groups
within your org.
Add a team admin
Add users to the team admin role
to enable them to Manage teams
and configure team tools. Team
settings can only be configured by
a team or project admin.
Support Stakeholders
Members within your org who
don't have a license or contribute
to developing the code base can
track project priorities and provide
direction, feature ideas, and
business alignment to a team.
Team dashboards
Share progress, status, and
guidance with your team using
configurable team dashboards.
Team welcome page
Provide in-project guidance
through the Welcome page and
other pages you format using
Markdown.
Setup a team hierarchy
By configuring your teams and
backlogs into an hierarchical
structure, program owners can
more easily track progress across
teams, manage portfolios, and
generate rollup data.
Set team defaults
Several Agile tools reference the
team's default area path, iteration
path, and activated sprints to
automatically filter the set of work
items they display. Understand
how defaults are used]
(../organizations/settings/about-
teams-and-settings.md).
Select team sprints
Select your team's sprints to gain
access to sprint backlogs and task
boards.
Configure team settings
Configure, customize, and manage
all team-related activities
Team alerts
As changes occur to work items,
code reviews, source control files,
and builds, your team can
automatically receive email
notifications for alerts that you
define.
Team groups
A team group is created when you
create a team. Use this group in
queries or to set permissions for
your team.](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-277-638.jpg)
![Search from a different page
TIP
TIP
Special characters
Escape the special characters ( , ) , [ , ] , : , * , and ? by enclosing them in a phrase delimited with
double-quotes.
Include special characters in a search string, or search specifically for special characters, according to the
following rules:
CodeA23?R finds files containing words that start with CodeA23
Have any alphanumeric character next, and end with R. For example, CodeA234R and CodeA23QR.
Search for any special character that isn't a part of the query language.
"flatten()" finds the literal string flatten(). Search for a literal occurrence of the double-quote character " by
preceding it with the escape character and enclosing the search string in double-quotes.
""react-redux"" finds the literal string "react-redux".
You can search from any of the following pages:
The Projects page for the organization: starts a search across all projects.
The Project overview page: automatically applies a filter to search within the selected project.
The Boards page for a project: automatically displays recent work items and backlogs accessed by the user.
Azure Repos, Pipelines, Test Plans, or an Artifacts page for a project: automatically displays functional filters
for code searches.
The wiki page for a project: automatically go to a wiki page you recently opened.
Use the content type filter to access a page that you recently accessed.
For more information about searching and filtering in Azure Boards, see Filter backlogs, boards, and plans.
For more information about searching wikis, see Provisioned vs. published wiki.
No results found for ...
If there's a large number of hits when using a wildcard search, such as when using a very simple wildcard search string,
you may see a message that no matching files were found. In this case, narrow your search to reduce the number of
matches. For example, specify more characters of the word(s) you want to find, or add a condition or filter to limit the
number of possible matches.](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-354-638.jpg)
![Search from a different page
TIP
TIP
Special characters
Escape the special characters ( , ) , [ , ] , : , * , and ? by enclosing them in a phrase delimited with
double-quotes.
Include special characters in a search string, or search specifically for special characters, according to the
following rules:
CodeA23?R finds files containing words that start with CodeA23
Have any alphanumeric character next, and end with R. For example, CodeA234R and CodeA23QR.
Search for any special character that isn't a part of the query language.
"flatten()" finds the literal string flatten(). Search for a literal occurrence of the double-quote character " by
preceding it with the escape character and enclosing the search string in double-quotes.
""react-redux"" finds the literal string "react-redux".
You can search from any of the following pages:
The Projects page for the organization: starts a search across all projects.
The Project overview page: automatically applies a filter to search within the selected project.
The Boards page for a project: automatically displays recent work items and backlogs accessed by the user.
Azure Repos, Pipelines, Test Plans, or an Artifacts page for a project: automatically displays functional filters
for code searches.
The wiki page for a project: automatically go to a wiki page you recently opened.
Use the content type filter to access a page that you recently accessed.
For more information about searching and filtering in Azure Boards, see Filter backlogs, boards, and plans.
For more information about searching wikis, see Provisioned vs. published wiki.
No results found for ...
If there's a large number of hits when using a wildcard search, such as when using a very simple wildcard search string,
you may see a message that no matching files were found. In this case, narrow your search to reduce the number of
matches. For example, specify more characters of the word(s) you want to find, or add a condition or filter to limit the
number of possible matches.](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-368-638.jpg)
![IMPORTANT
[Info @08:23:59.539] Table name Size in MB
[Info @08:23:59.539] dbo.tbl_Content 38984
[Info @08:23:59.539] dbo.tbl_LocalVersion 1935
[Info @08:23:59.539] dbo.tbl_Version 238
[Info @08:23:59.539] dbo.tbl_FileReference 85
[Info @08:23:59.539] dbo.Rules 68
[Info @08:23:59.539] dbo.tbl_FileMetadata 61
SET TEMP={location on disk}
TFS 2018 imports need to use the SqlPackage.exe version from the 140 folder or higher.
If you installed SSDT for Visual Studio, you'll find your SqlPackage.exe version in one of the following folder
paths:
If you installed SSDT and integrated it with an existing installation of Visual Studio, your SqlPackage.exe
folder path is similar to
C:Program Files (x86)Microsoft Visual Studio 14.0Common7IDEExtensionsMicrosoftSQLDBDAC130 .
If you installed SSDT as a standalone installation, your SqlPackage.exe folder path is similar to
C:Program Files (x86)Microsoft Visual. Studio2017SQLCommon7IDEExtensionsMicrosoftSQLDBDAC130 .
If you already have an installation of SQL Server, SqlPackage.exe might already be present, and your folder
path is similar to %PROGRAMFILES%Microsoft SQL Server130DACbin .
Both versions of SSDT that you can download from SQL Server Data Tools include both the 130 and 140 folders
and their SqlPackage.exe versions.
When you generate a DACPAC, keep two considerations in mind: the disk that the DACPAC will be saved on and
the disk space on the machine that's generating the DACPAC. You want to ensure that you have enough disk
space to complete the operation.
As it creates the package, SqlPackage.exe temporarily stores data from your collection in the temp directory on
drive C of the machine you're initiating the packaging request from.
You might find that your drive C is too small to support creating a DACPAC. You can estimate the amount of
space you'll need by looking for the largest table in your collection database. DACPACs are created one table at a
time. The maximum space requirement to run the generation is roughly equivalent to the size of the largest
table in the collection's database. If you're saving the generated DACPAC to drive C, you also need to take into
account the size of the collection database as reported in the DataMigrationTool.log file from a validation run.
The DataMigrationTool.log file provides a list of the largest tables in the collection each time the validate
command is run. For an example of table sizes for a collection, see the following output. Compare the size of the
largest table with the free space on the drive that hosts your temporary directory.
Before you proceed with generating a DACPAC file, ensure that your collection is detached.
Ensure that the drive that hosts your temporary directory has at least as much free space. If it doesn't, you need
to redirect the temp directory by setting an environment variable.
Another consideration is where the DACPAC data is saved. Pointing the save location to a far-off remote drive
could result in much longer generation times. If a fast drive such as a solid-state drive (SSD) is available locally,
we recommend that you target the drive as the DACPAC save location. Otherwise, it's always faster to use a disk
that's on the machine where the collection database resides rather than a remote drive.](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-401-638.jpg)
![SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database
Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract
/p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory
SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True"
/targetFile:C:DACPACFoo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true
/p:IgnorePermissions=true /p:Storage=Memory
Configure your collection for import
ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;
USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'
ALTER DATABASE [Foo] SET RECOVERY SIMPLE;
USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'
Now that you've identified the target location for the DACPAC and ensured that you have enough space, it's time
to generate the DACPAC file.
Open a Command Prompt window and go to the SqlPackage.exe location. To generate the DACPAC, replace the
placeholder values with the required values, and then run the following command:
Data Source: The SQL Server instance that hosts your Azure DevOps Server collection database.
Initial Catalog: The name of the collection database.
targetFile: The location on the disk and the DACPAC file name.
A DACPAC generation command that's running on the Azure DevOps Server data tier itself is shown in the
following example:
The output of the command is a DACPAC file that's generated from the collection database Foo called
Foo.dacpac.
After your collection database has been restored on your Azure VM, configure a SQL login to allow Azure
DevOps Services to connect to the database to import the data. This login allows only read access to a single
database.
To start, open SQL Server Management Studio on the VM, and then open a new query window against the
database to be imported.
Set the database's recovery to simple:
Create a SQL login for the database, and assign that login the 'TFSEXECROLE':
Following our Fabrikam example, the two SQL commands would look like the following:](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-402-638.jpg)
![ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;
USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'
ALTER DATABASE [Foo] SET RECOVERY SIMPLE;
USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'
NOTE
Configure the import specification file to target the VM
database.
To start, open SQL Server Management Studio on the VM, and then open a new query window against the
database to be imported.
Set the database's recovery to simple:
Create a SQL login for the database, and assign that login the 'TFSEXECROLE':
Following our Fabrikam example, the two SQL commands would look like the following:
Be sure to enable SQL Server and Windows authentication mode in SQL Server Management Studio on the VM. If you
don't enable authentication mode, the import will fail.
Update the import specification file to include information about how to connect to the SQL Server instance.
Open your import specification file and make the following updates:
1. Remove the DACPAC parameter from the source files object.
The import specification before the change is shown in the following code:
The import specification after the change is shown in the following code:
2. Fill out the required parameters and add the following properties object within your source object in the
specification file.](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-422-638.jpg)
![The database metadata size is currently {Metadata Size}GBs. This is above the recommended size of {Warning
Size}GBs. It's recommended that you consider cleaning up older data as described in [Cleaning up old data]
(/azure/devops/server/upgrade/clean-up-data).
Database metadata size above maximum supported size
The database metadata size is currently {Metadata Size}GBs. This is above the maximum supported size of
{Metadata Limit}GBs.
Resolve collation warnings
No native support
The collection database's collation '{collation}' is not natively supported in Azure DevOps Services.
Importing your collection will result in your collation being converted to one of the supported Azure DevOps
Services collations. See more details at https://aka.ms/AzureDevOpsImportCollations
No native support, no internet connection
The following warning means that your database is approaching the limit for total metadata size. Metadata size
refers to the size of your database without including files, code, and other binary data. We recommend that you
reduce the size of your database before import. Reducing the size provides the additional benefit of speeding up
your import.
The warning DOES NOT mean that your collection is too large for import, rather its metadata size is larger than
the vast majority of other databases.
Unlike the previous warnings, the following error WILL block you from moving forward with your migration.
It indicates that the volume of metadata in your collection is too large. To proceed with the import, you need to
reduce the size below the indicated limit.
Collation warnings refer to your collection database's collation. Collations control the way string values are
sorted and compared. Collections that aren't using either SQL_Latin1_General_CP1_CI_AS or
Latin1_General_CI_AS will generally receive one of the warning messages.
Receiving the following warning means that you need to consider collation implications before performing the
import.
This warning DOES NOT mean that you can't import your collection.
This warning requires you to acknowledge acceptance of the warning. Accepting the warning allows the data
migration tool to continue import preparations.
When you import a non-supported collation into Azure DevOps Services, the collation is transformed to a
supported collation. While this transform generally works without issue, unexpected results post import or
import failures could occur.
For instance, customers may notice different ordering for strings containing non-English characters. Non-
English characters like 'é' may become equivalent to the English 'e' after import. It's important that you
complete and verify a dry run import when importing a collection with a non-supported collation.
If the data migration tool can't connect to the internet, it can't validate conversion of your collation. It's only a
warning, so you can continue with your migration process. However, when you run the prepare command, an
internet connection is required and collation conversion is validated at that time.](https://image.slidesharecdn.com/2159ed1f8798a5c39ae0a98c42f3fb41-220610173504-2b24bad3/95/Azure-Devops-433-638.jpg)
Azure Devops
- 1. Contents Get started Start using Azure DevOps What is Azure DevOps? Overview of services Compare Azure DevOps hosted vs. on-premises Get started for end users Sign in to the web or a client Code with Git Set up continuous integration and delivery Plan and track work Add and run manual tests Follow work and pull requests Get started as a Stakeholder View permissions Get started for administrators Sign up for Azure DevOps Create an organization or project collection Manage your project Manage your organization or collection Add users to a project or team Manage teams and configure team tools Change individual permissions Grant or restrict permissions to select tasks Security best practices Key concepts Plan your organizational structure Source control Clients and tools Software development roles
- 2. Troubleshooting Troubleshoot connection TF31002: Unable to connect Troubleshoot access and permissions Allowed address lists and network connections Get support or provide feedback Reference Navigate in Team Explorer FAQs Service limits Features index Resources Azure CLI Integration overview Cross-service integration overview GitHub integration Deploy to Azure Web portal navigation Navigation Open a service, page, or setting Add an artifact or team artifacts Use breadcrumbs, selectors, and directories Open another project or repo Set favorites Filter basics Search your repo, work items, or wiki Manage or enable features Search Get started with search Search code Search work items Migrate & import Migrate data to Azure DevOps Services
- 3. Migrate data to Azure DevOps Services Migrate options Import Import large collections Process templates Post-import Troubleshooting FAQs, migration and process models Permissions & access Permissions and access (Security) About access levels Status & security Service status Data protection Data location Credential storage IDE Client Resources Visual Studio IDE Visual Studio Code Visual Studio for Mac Resources Settings, security, & usage Manage projects Marketplace & extensibility DevOps Resource Center What is DevOps? What is Agile? What is Git?
- 5. What is Azure DevOps? 6/9/2022 • 3 minutes to read • Edit Online Choose Azure DevOps Services Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Azure DevOps provides developer services for allowing teams to plan work, collaborate on code development, and build and deploy applications. Azure DevOps supports a collaborative culture and set of processes that bring together developers, project managers, and contributors to develop software. It allows organizations to create and improve products at a faster pace than they can with traditional software development approaches. You can work in the cloud using Azure DevOps Services or on-premises using Azure DevOps Server. For information on the differences between the cloud versus on-premises platforms, see Azure DevOps Services and Azure DevOps Server. Azure DevOps provides integrated features that you can access through your web browser or IDE client. You can use one or more of the following standalone services based on your business needs: Azure Repos provides Git repositories or Team Foundation Version Control (TFVC) for source control of your code. For more information about Azure Repos, see What is Azure Repos?. Azure Pipelines provides build and release services to support continuous integration and delivery of your applications. For more information about Azure Pipelines, see What is Azure Pipelines?. Azure Boards delivers a suite of Agile tools to support planning and tracking work, code defects, and issues using Kanban and Scrum methods. For more information about Azure Boards, see What is Azure Boards?. Azure Test Plans provides several tools to test your apps, including manual/exploratory testing and continuous testing. For more information about Azure Test Plans, see Overview of Azure Test Plans Azure Artifacts allows teams to share packages such as Maven, npm, NuGet, and more from public and private sources and integrate package sharing into your pipelines. For more information about Azure Artifacts, see Overview of Azure Artifacts. You can also use the following collaboration tools: Customizable team dashboards with configurable widgets to share information, progress, and trends Built-in wikis for sharing information Configurable notifications Azure DevOps supports adding extensions and integrating with other popular services, such as: Campfire, Slack, Trello, UserVoice, and more, and developing your own custom extensions. Azure DevOps Services supports integration with GitHub.com and GitHub Enterprise Server repositories. Azure DevOps Server supports integration with GitHub Enterprise Server repositories. For more information, see the Azure DevOps and GitHub integration overview. Choose Azure DevOps Services when you want the following outcomes: Quick set-up Maintenance-free operations Easy collaboration across domains Elastic scale
- 6. Choose Azure DevOps Server Next steps Related articles Rock-solid security To learn more about data protection in Azure DevOps Services, see Data protection overview. Azure DevOps Services also gives you access to cloud build and deployment servers, and application insights. We've made it easy for you to start for free and try out our services. Sign up for free by creating an organization. Then, either upload your code to share or source control. Begin tracking your work using Scrum, Kanban, or a combination of methods. You can use all the services included with Azure DevOps, or choose just what you need to complement your existing workflows. Azure Boards. Plan, track, and discuss work across your teams. Azure Pipelines. Continuously build, test, and deploy to any platform and cloud. Azure Repos. Get unlimited, cloud-hosted private Git repositories for your project. Choose on-premises Azure DevOps Server when: You need your data to stay within your network. Your work tracking customization requirements are met better with the on-premises XML process model over the inheritance process model. The on-premises model supports modification of XML definition files. When you deploy Azure DevOps Server, you can also configure the following servers or integration points: Build server supports on-premises and cloud-hosted builds. SQL Server and SQL Analysis Server support SQL Server Reports and the ability to create Excel pivot charts based on the cube. Start for free by downloading Azure DevOps Server Express. Then, either upload your code to share or source control. Or, begin tracking your work using Scrum, Kanban, or a combination of methods. To learn more about managing Azure DevOps Server, see the Administrative tasks quick reference. Sign up for Azure DevOps Services or Install Azure DevOps Server A tour of services Client-server tools Software development roles Azure DevOps pricing Azure DevOps release notes Azure DevOps blog
- 7. What features and services do I get with Azure DevOps? 6/9/2022 • 8 minutes to read • Edit Online Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 With Azure DevOps, you gain an integrated set of services and tools to manage your software projects, from planning and development through testing and deployment. Services are delivered through a client/server model. Many of them are delivered through an easy-to-use web interface that you can access from all major browsers. Some services, such as source control, build pipelines, and work tracking, can also be managed through a client. You access Azure DevOps Services through the left pane, as shown in the following image. To jump to information for each major service, see the associated articles. Dashboards Wiki Boards Repos Pipelines Test Plans Artifacts You access Azure DevOps Services through the top navigational bar, as shown in the following image. To jump
- 8. Dashboards to information for each major service, see the associated articles. Dashboards Code Work Build & Release Test Wiki Many of our services are either free for small teams or available through a subscription model or per-use model. You can do a hybrid approach where you use an on-premises deployment to manage your code and work. Then, you purchase cloud build or testing services on an as-needed basis. For information about client tools, see Tools. From Dashboards, you gain access to user-configurable dashboards.
- 9. Source control You can do the following tasks in Dashboards: Add, configure, and manage dashboards Configure widgets that you add to dashboards Quickly go to different areas of your project To learn more, see Dashboards. Source or version control systems allow developers to collaborate on code and track changes made to the code base. Source control is an essential tool for multi-developer projects. Our systems support two types of source control: Git (distributed) or Team Foundation Version Control (TFVC), a centralized, client-server system. Both systems enable you to check in files and organize files within folders, branches, and repositories. With Git, each developer has a copy on their dev machine of the source repository, including all branch and history information. Each developer works directly with their own local repository and changes are shared between repositories as a separate step. Developers commit each set of changes and do version control operations like history and compare without a network connection. Branches are lightweight. When developers need to switch contexts, they create a private local branch and can switch from one branch to another to pivot among different variations of the codebase. Later, they merge, publish, or dispose of the branch.
- 10. NOTE Git in Azure DevOps is standard Git. You can use Visual Studio with third-party Git services. You can also use third-party Git clients with Azure DevOps Server. With TFVC, developers have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and created on the server. From Repos, you gain access to your source control Git-based or Team Foundation Version Control (TFVC) repositories to support version control of your software projects. These repositories are private. From Code, you gain access to your source control Git-based or TFVC repositories to support version control of your software projects. These repositories are private.
- 11. Plan and track work From Azure Repos for Git, you can do the following tasks: Review, download, and edit files, and review the change history for a file Review and manage commits that have been pushed Review, create, approve, comment on, and complete pull requests Add and manage Git tags To learn more, see the overviews for Git or TFVC. Software development projects require ways to easily share information and track the status of work, tasks, issues, or code defects. In the past, perhaps you used one or more tools. Microsoft Excel, Microsoft Project, a bug tracking system, or a combination of tools, for example. Now, many teams have adopted Agile methods and practices to support planning and development. Our systems provide several types of work items that you use to track features, requirements, user stories, tasks, bugs, and issues. Each work item is associated with a work item type and a set of fields that can be updated, as progress is made. For planning purposes, you have access to several types of backlogs and boards to support the main Agile methods—Scrum, Kanban, or Scrumban. Product backlog: Used to create and rank stories or requirements. Kanban: Used to visualize and manage the flow of work as it moves from beginning, to in-progress, to done. Sprint backlogs: Used to plan work to complete during a sprint cycle, a regular two to four-week cadence that teams use when implementing Scrum. Task board: Used during daily Scrum meetings to review work that's completed, remaining, or blocked. Project managers and developers share information by tracking work items on the backlogs and boards. Useful charts and dashboards complete the picture and help teams monitor progress and trends. From Boards, you gain access to Agile tools to support planning and tracking work.
- 12. From Work, you gain access to Agile tools to support planning and tracking work. Specifically, you can do the following tasks: Add and update work items Define work item queries, and create status and trend charts based on those queries Manage your product backlog
- 13. Continuous integration and deployment Plan sprints by using sprint backlogs Review sprint tasks and update tasks through the task boards Visualize the workflow and update the status by using Kanban boards Manage portfolios by grouping stories under features and grouping features under epics See Backlogs, boards, and plans for an overview of each. The rapid and reliable release of software comes from automating as many processes as possible. Our systems support build, test, and release automation. You can define builds to automatically run whenever a team member checks in code changes. Your build pipelines can include instructions to run tests after the build runs. Release pipelines support managing deployment of your software builds to staging or production environments. Azure Pipelines provides an integrated set of features to support building and deploying your applications. Azure Pipelines provides an integrated set of features to support building and deploying your applications.
- 14. Manual and exploratory testing Use pipelines to implement continuous integration and continuous delivery. Build automation: Define the steps to take during build and the triggers that start a build. Release management: Supports a rapid release cadence and management of simultaneous releases. You can configure release pipelines that represent your environments from development to production. Run automation to deploy your app to each environment. Add approvers to confirm that the app has been successfully deployed in an environment. Create your release manually or automatically from a build. Then track your releases as they're deployed to various environments. To learn more, see Continuous integration on any platform. Test features support manual and exploratory testing, and continuous testing. Test Plans supports creating and managing manual tests. Test supports creating and managing manual tests.
- 15. Collaboration services Service hooks With test features, you gain access to the following features: Customization of workflows with test plan, test suite, and test case work items End-to-end traceability from requirements to test cases and bugs with requirement-based test suites Criteria-based test selection with query-based test suites Excel-like interface with the grid for easy creation of test cases Reusable test steps and test data with shared steps and shared parameters Sharable test plans, test suites, and test cases for reviewing with Stakeholders Browser-based test execution on any platform Real-time charts for tracking test activity To learn more, see Testing overview. The following services work across the previously mentioned services to support: Team dashboards Project wiki Discussion within work item forms Linking of work items, commits, pull requests, and other artifacts to support traceability Alerts and change notifications managed per user, team, project, or organization Ability to request and manage feedback Analytics service, analytic views, and Power BI reporting Dashboards Project wiki Discussion within work item forms Linking of work items, commits, pull requests, and other artifacts to support traceability Alerts and change notifications managed per user, team, project, or project collection Ability to request and manage feedback SQL Server Reporting Service hooks enable you to complete tasks on other services when events happen within your project hosted on Azure DevOps. For example, you can send a push notification to your team's mobile devices when a build fails. You can also use service hooks in custom apps and services as a more efficient way to drive activities in your projects.
- 16. Cloud-hosted services based on usage Azure cloud-hosted services Administrative services The following services are available as the target of service hooks. To learn about other apps and services that integrate with Azure DevOps, visit the Visual Studio Marketplace, Azure DevOps tab. For the latest set of supported services, see Integrate with service hooks. The following services support your DevOps operations: Cloud-based, Microsoft-hosted build and deployment agents On-premises self-hosted agents to support build and deployment To learn more, see Pricing. Azure provides cloud-hosted services to support application development and deployment. You can make use of these services solely or in combination with Azure DevOps. To browse the directory of integrated services, features, and bundled suites, see Azure products. For continuous delivery to Azure from Azure DevOps Services, see Automatically build and deploy to Azure web apps or cloud services. There are features and tasks associated with administering a collaborative software development environment. You complete most of these tasks through the web portal. To learn more, see About user, team, project, and organization-level settings.
- 18. Related articles Understand differences between Azure DevOps Services and Azure DevOps Server Client-server tools Software development roles Azure DevOps pricing Azure DevOps data protection overview
- 19. Compare Azure DevOps Services with Azure DevOps Server 6/9/2022 • 9 minutes to read • Edit Online Fundamental differences between Azure DevOps Services and Azure DevOps Server Scope and scale data Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 The cloud offering, Azure DevOps Services, provides a scalable, reliable, and globally available hosted service. It's backed by a 99.9% SLA, monitored by our 24/7 operations team, and available in local data centers around the world. The on-premises offering, Azure DevOps Server, is built on a SQL Server back end. Customers usually choose the on-premises version when they need their data to stay within their network. Or, when they want access to SQL Server reporting services that integrate with Azure DevOps Server data and tools. Although both offerings provide the same essential services, compared with Azure DevOps Server, Azure DevOps Services offers the following added benefits: Simplified server management. Immediate access to the latest and greatest features Improved connectivity with remote sites. A transition from capital expenditures (servers and the like) to operational expenditures (subscriptions). To determine which offering—cloud or on-premises—meets your needs, consider the following key differences. When you're choosing which platform you want, or if you're considering a move from on-premises to the cloud, consider the following areas: Scope and scale data Authentication Users and groups Manage user access Security and data protection Differences in specific feature areas Although Azure DevOps Services is a hosted version of Azure DevOps Server, there are some differences between features. Some Azure DevOps Server features aren't supported in Azure DevOps Services. For example, Azure DevOps Services doesn't support integration with SQL Server Analysis Services to support reporting. Two of the following other areas differ in their support: Process customization Reporting Are you on Azure DevOps Server and considering moving? Read Migration options to understand your options.
- 20. Azure DevOps Services scales by using organizations and projects Azure DevOps Server scales by using deployments, project collections, and projects Authentication Manage users and groups As your business grows, you may need to scale up your Azure DevOps instance. Azure DevOps Services differs slightly from Azure DevOps Server. There are currently only two options for scoping and scaling data: organizations and projects. Organizations in Azure DevOps Services get their own URLs (for example, https://dev.azure.com/fabrikamfiber ), and they always have exactly one project collection. Organizations can have many projects within a collection. We recommend that you create organizations in Azure DevOps Services wherever you would create collections in Azure DevOps Server. The following scenarios apply: You can purchase Azure DevOps Services users per organization - Paid users can access only the organization in which the payment is made. If you have users who need access to many organizations, Visual Studio subscriptions can be an attractive option. Visual Studio subscribers can be added to any number of organizations at no charge. We're also considering other ways to make access available to many organizations that are grouped into a single organization. You currently have to administer organizations one at a time. This process can be cumbersome when you have many organizations. Learn more: Plan your organizational structure in Azure DevOps. Azure DevOps Server offers the following three options for scoping and scaling data: deployments, project collections, and projects. In the simplest case, deployments are just servers. Deployments can be more complicated, however, which could include: Two-server deployment where SQL is split out on a separate machine High-availability farms with lots of servers Project collections serve as containers for security and administration, and physical database boundaries. They're also used to group related projects. Finally, projects are used to encapsulate the assets of individual software projects, including source code, work items, and so on. Learn more: Plan your organizational structure in Azure DevOps. With Azure DevOps Services, you connect over the public internet (for example, https://contoso.visualstudio.com ). You either authenticate with Microsoft account credentials or with Azure AD credentials, depending on your organization setup. You can also set up Azure AD to require features such as multi-factor-authentication, IP address restrictions, and so on. We recommend that you configure your organizations to use Azure AD rather than Microsoft accounts. This method provides a better experience in many scenarios and more options for enhanced security. Learn more: About accessing Azure DevOps Services with Azure AD. With Azure DevOps Server, you connect to an intranet server (for example, https://tfs.corp.contoso.com:8080/tfs ). You authenticate with Windows Authentication and your Active Directory (AD) domain credentials. This process is transparent and you never see any kind of sign-in experience.
- 21. Manage user access Security and data protection Process customization In Azure DevOps Services, you can use a similar mechanism to provide access to groups of users. You can add Azure AD groups to Azure DevOps Services groups. If you use Microsoft Accounts instead of Azure AD, you have to add users one at a time. In Azure DevOps Server, you provide users access to deployments by adding Active Directory (AD) groups to various Azure DevOps groups (for example, the Contributors group for an individual project). The AD group memberships are kept in sync. As users are added and removed in AD, they also gain and lose access to Azure DevOps Server. In both Azure DevOps Services and Azure DevOps Server, you manage access to features by assigning users to an access level. All users must be assigned to a single access level. In both the cloud and on-premises offerings, you can give free access to work item features to an unlimited number of Stakeholders. Also, an unlimited number of Visual Studio subscribers can have access to all Basic features at no additional charge. You pay only for other users who need access. In Azure DevOps Services, you must assign an access level to each user in your organization. Azure DevOps Services validates Visual Studio subscribers as they sign in. You can assign Basic access for free to five users without Visual Studio subscriptions. To give Basic access or higher to more users, set up billing for your organization and pay for more users. Otherwise, all other users get Stakeholder access. Azure AD groups give access to groups of users. Access levels are automatically assigned at first sign-in. For organizations that are configured to use Microsoft accounts for signing in, you must assign access levels to each user explicitly. In Azure DevOps Server, all use is on the honor system. To set access levels for users based on their licenses, specify their access levels on the administration page. For example, assign unlicensed users Stakeholder access only. Users with an Azure DevOps Server Client Access License (CAL) can have Basic access. Visual Studio subscribers can have either Basic or Advanced access, depending on their subscriptions. Azure DevOps Server doesn't attempt to verify these licenses or enforce compliance. Many entities want to know more about data protection when they consider moving to the cloud. We're committed to ensuring that Azure DevOps Services projects stay safe and secure. We have technical features and business processes in place to deliver on this commitment. You can also take steps to secure your data. Learn more in our Data Protection overview. You can customize the work-tracking experience in two different ways, depending on the supported process model: Azure DevOps Services: you use the Inheritance process model, which supports WYSIWYG customization Azure DevOps Server: you can choose the Inheritance process model or the On-premises XML process model, which supports customization through import or export of XML definition files for work-tracking objects Azure DevOps Server 2018 and earlier versions: you only have access to the On-premises XML process model
- 22. Analytics and reporting Visual Studio Team Services is now Azure DevOps Services VSTS FEATURE NAME AZURE DEVOPS SERVICE NAME DESCRIPTION Although the On-premises XML process model option is powerful, it can cause various issues. The main issue is that processes for existing projects aren't automatically updated. Azure DevOps Server 2013, for example, introduced several new features that depended on new work-item types and other process template changes. When you upgrade from 2012 to 2013, each project collection gets new versions of each of the "in the box" process templates that include these changes. However, these changes aren't automatically incorporated into existing projects. Instead, after you finish upgrading, you have to include the changes in each project by using the Configure features wizard or a more manual process. To help you avoid these issues in Azure DevOps Services, custom process templates and the witadmin.exe tool have always been disabled. This approach has enabled us to automatically update all projects with each Azure DevOps Services upgrade. Meanwhile, the product team is working hard to make customizing processes possible in ways that we can support easily and continuously. We recently introduced the first of these changes and more changes are on the way. With the new process-customization capability, you can make changes directly within the web user interface (UI). If you want to customize your processes programmatically, you can do so through REST endpoints. When you customize projects this way, they're automatically updated when we release new versions of their base processes with Azure DevOps Services upgrades. To learn more, see Customize your work-tracking experience. Azure DevOps Services and Azure DevOps Server offer many tools that give you insight into the progress and quality of your software projects. Included are the following tools: Dashboards and lightweight charts that are available in both the cloud and on-premises platforms. These tools are easy to set up and use. The Analytics service and Analytics widgets. The Analytics service is optimized for fast read-access and server-based aggregations. Microsoft Power BI integration, which supports getting Analytics data into Power BI reports and provides a combination of simplicity and power. OData support, which allows you to directly query the Analytics service from a supported browser, and then use the returned JSON data as you want. You can generate queries that span many projects or your entire organization. To learn more about the Analytics service, see our Reporting roadmap. Dashboards and lightweight charts that are available in both the cloud and on-premises platforms. These tools are easy to set up and use. SQL Server Reporting Services (SSRS) reports are available when Azure DevOps Server is configured with SQL Server Analysis Services. Many of the featured services in VSTS are now offered as standalone services in both Azure DevOps Services and Azure DevOps Server 2019. You can get services separately or all together as Azure DevOps Services. If you're an Azure DevOps subscriber, you have access to all of the services already.
- 23. Build & release Azure Pipelines Continuous integration and continuous delivery (CI/CD) that works with any language, platform, and cloud. Code Azure Repos Unlimited cloud-hosted private Git and Team Foundation Version Control (TFVC) repositories for your project. Work Azure Boards Work tracking with Kanban boards, backlogs, team dashboards, and custom reporting. Test Azure Test Plans All-in-one planned and exploratory testing solution. Packages (extension) Azure Artifacts Maven, npm, Python, Universal Package, and NuGet package feeds from public and private sources. VSTS FEATURE NAME AZURE DEVOPS SERVICE NAME DESCRIPTION NOTE Related articles Both Azure DevOps Services and Azure DevOps Server 2019 use the new navigation user interface, with a vertical sidebar to go to the main service areas: Boards, Repos, Pipelines, and more. To learn more, see Web portal navigation in Azure DevOps. You can disable select services from the user interface. For more information, see Turn a service on or off. You can still use visualstudio.com to access Azure DevOps Services. We've moved to the new dev.azure.com domain name as the primary URL for new organizations. That URL is https://dev.azure.com/{your organization}/{your project} . If you want to change your URL to be based on dev.azure.com as the primary, an organization administrator can do so from the organization settings page. Essential services Client-server tools Software development roles Pricing for Azure DevOps Services Pricing for Azure DevOps Server
- 24. Connect to a project in Azure DevOps 6/9/2022 • 7 minutes to read • Edit Online Prerequisites Connect from the web portal Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Learn how to connect to a project to share code, build apps, track work, and collaborate with team members. You can use any of the following clients: Web portal Visual Studio or Team Explorer Eclipse/Team Explorer Everywhere Android Studio with the Azure DevOps Services Plugin for Android Studio IntelliJ with the Azure DevOps Services Plugin for IntelliJ Visual Studio Code A project defines a process and data storage in which you manage your software projects from planning to deployment. When you connect to a project, you connect to an organization or project collection. One or more projects may be defined within a collection. There must be at least one project. For more information, see About projects and scaling your organization. If you don't have a project yet, create one. If you need to add a team, see Add teams. If you don't have access to the project, get invited to the team. From each of these clients, you can switch context to a different project and connect as a different user. If you work remotely, configure your client to connect to an Azure DevOps Proxy Server. To get started with a code base, set up Git or set up TFVC. https://dev.azure.com/OrganizationName/ProjectName http://ServerName/DefaultCollection/ProjectName http://ServerName:8080/tfs/DefaultCollection/ProjectName 1. If you're not a member of a security group, ask your Project Administrator to add you. 2. Open a browser and enter a URL that uses the following form: For example, to connect to the server named FabrikamPrime, type: http://FabrikamPrime/DefaultCollection. For example, to connect to the server named FabrikamPrime, type: http://FabrikamPrime:8080/tfs/DefaultCollection.
- 25. TIP The default Port is 8080. If you don't use default values, specify the port number and directory for your server. 3. When you access the server for the first time, a Windows Identity dialog box appears. Enter your credentials and choose OK. If you select Remember me, you won't have to enter your credentials the next time you connect. 4. Choose your project, team, or page of interest. From the project summary page, hover over a service and then choose the page you want. To choose another project, choose Azure DevOps. From the project summary page, hover over a service and then choose the page you want. To choose another project, choose the Azure DevOps logo.
- 26. Sign in with different credentials Open the web portal from Team Explorer To learn more about each page and the tasks you can do, see Web portal navigation. 1. Open your profile menu and choose Sign out. 2. Choose Sign in and enter your credentials. Open the web portal from the home page.
- 27. Connect from Visual Studio or Team Explorer Visual Studio 2019 If you haven't already, download and install a version of Visual Studio. If you're not a member of an Azure DevOps security group, get added to one. Check with a team member. You'll need the names of the server, project collection, and project to connect to. Visual Studio 2019 Visual Studio 2017 Visual Studio 2015 1. Select the Manage Connections button in Team Explorer to open the Connect page. Choose Connect to a Project to select a project to connect to. Connect to a Project shows the projects you can connect to, along with the repos in those projects.
- 28. Change sign-in credentials Visual Studio 2019 2. Select Add Azure DevOps Server to connect to a project in Azure DevOps Services. Enter the URL to your server and select Add. 3. Select a project from the list and select Connect. Visual Studio 2019 Visual Studio 2017 Visual Studio 2015 1. From Connect, choose the Connect to a Project link to sign in with different credentials. 2. Select a different user or select Add an account to access a project using different credentials.
- 29. Use different Visual Studio credentials User accounts and licensing for Visual Studio 3. Sign in using an account that is associated with an Azure DevOps project, either a valid Microsoft account or GitHub account. You can run Visual Studio with credentials different from your current Windows user account. Find devenv.exe under the Program Files (86) folder for your version of Visual Studio. Select Shift and right-click devenv.exe, then select Run as different user. To connect to a project, you need your user account added to the project. The Organization owner for Azure DevOps Services or a member of the Project Administrators group usually adds user accounts. To learn more, see Add organization users and manage access or Add or remove users or groups, manage security groups. Azure DevOps Services provides access to the first five account users free. After that, you need to pay for more users. For on-premises TFS, each user account must have a TFS client access license (CAL). All Visual Studio subscriptions and paid Azure DevOps Services users include a TFS CAL. Find out more about licensing from the Team Foundation Server pricing page. You can also provide access to Stakeholders in your organization who have limited access to select features as described in Work as a Stakeholder.
- 30. Configure Visual Studio to connect to Azure DevOps Proxy Server What other clients support connection to Azure DevOps? If your remote team uses a Azure DevOps Proxy Server to cache files, you can configure Visual Studio to connect through that proxy server and download files under Team Foundation version control. 1. First, make sure that you've connected to Azure DevOps Server as described in the previous section. 2. From the Visual Studio Tools menu, select Options, then select Source Control > Plug-in Selection. Select Visual Studio Team Foundation Server. 3. For Visual Studio Team Foundation Server, enter the name and port number for the Azure DevOps Proxy Server. Select Use SSL encryption (https) to connect. Make sure you specify the port number that your administrator assigned to TFS Proxy. To associate a file type with a compare or merge tool, see Associate a file type with a file-comparison tool or Associate a file type with a merge tool.
- 31. Requirements and client compatibility Determine your platform version Next steps Besides connecting through a web browser, Visual Studio, Eclipse, Excel, and Project you can connect to a project from these clients: Visual Studio Code Visual Studio Community Eclipse: Team Explorer Everywhere Azure Test Plans (formerly Test Manager) Microsoft Feedback Client Some tasks or features aren't available when you connect to a later version of Azure DevOps Server than your client supports. For more information, see client compatibility. See Feedback and support. Learn more about how to: Work in web portal Work in Team Explorer Work in Office Excel or Project Troubleshoot connection If all you need is a code repository and bug tracking solution, then start with the Get Started with Azure Repos and Manage bugs. To start planning and tracking work, see Get started with Agile tools to plan and track work.
- 32. Quickstart: Code with Git 6/9/2022 • 11 minutes to read • Edit Online Install Git command-line tools Get your code I just created my organization in Azure DevOps, so I don't have any code The code is in my (or my organization's) Azure Repos Git repo The code is in another Git repo The code is on my local computer and not yet in version control Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 In this quickstart, learn how to share your code with others. After you create a new organization and project in Azure DevOps, you can begin coding with Git. To work with a Git repo, you clone it to your computer. Cloning a repo creates a complete local copy of the repo for you to work with. Cloning also downloads all commits and branches in the repo, and sets up a named relationship with the repo on the server. Use this relationship to interact with the existing repo, pushing and pulling changes to share code with your team. Install one of the following Git command-line tools: To install Git for Windows, including Git Credential Manager, see Install the Git Credential Manager. To install on macOS or Linux, check out the Installing Git chapter in the open-source Pro Git book. For macOS and Linux, we recommend configuring SSH authentication To get a copy of the source code, you clone the Git repo that contains the code. Cloning creates both a local copy of the source code so you can work with it. Cloning also creates all the version control information so Git can manage the source code. If you're just getting started with Azure Repos, your code might be in one of several places: I just created my organization in Azure DevOps, so I don't have any code The code is in my (or my organization's) Azure Repos Git repo The code is in another Git repo such as GitHub or another Azure Repos Git repo The code is on my local computer and not yet in version control If you just signed up for Azure DevOps Services, by default you have a project named MyFirstProject and a Git repo named MyFirstProject . If you want to work in that repo, you can clone it and then add your code to that repo. If you want to make a new repo, follow the steps in Create a new Git repo in your project. Then, clone the new repo and add your code there. If the code is in your (or your organization's) Azure Repo, you can clone the Git repo to your local computer and start working with it by jumping down to Clone the repo. If the code is in another Git repo, such as a GitHub repo or a different Azure Repo instance, you can import it into a new or existing empty Git repo. Follow the steps in Import a Git repo. Then, return to this article and jump down to Clone the repo.
- 33. Clone the repo to your computer If your code is not yet in version control, you have a couple of options: Create a new repository and add your code there. To create a new repository and add your code there, follow the steps in Create a new Git repo in your project. Then, come back to this article and jump down to Clone the repo. Add your code to an existing repository. To do add your code to an existing repository, jump down to Clone the repo. After the repository is cloned, we'll show you how to add your existing code to the repo. To work with a Git repo, you clone it to your computer. Cloning a repo creates a complete local copy of the repo for you to work with. Cloning also downloads all commits and branches in the repo and sets up a named relationship with the repo on the server. Use this relationship to interact with the existing repo, pushing and pulling changes to share code with your team. 1. From your web browser, open the team project for your organization and select Repos > Files. If you don't have a team project, create one now. 2. Select Clone in the upper-right corner of the Code window and copy the URL. 3. Open the Git command window (Git Bash on Git for Windows). Go to the folder where you want the code from the repo stored on your computer, and run git clone , followed by the path copied from Clone URL in the previous step. See the following example:
- 34. Work in a branch git clone https://FabrikamFiber01@dev.azure.com/FabrikamFiber01/FabrikamFiber01- 01/_git/FabrikamFiber01-01 cd fabrikam-web Git downloads a copy of the code, including all commits, and branches from the repo, into a new folder for you to work with. 4. Switch your directory to the repository that you cloned. Keep this command window open, as you'll use it in the following steps. git clone https://contoso-ltd.visualstudio.com/MyFirstProject/_git/contoso-demo cd contoso-demo 1. From your web browser, open the project for your organization, and select Code. If you don't have a project, create one now. 2. Select Clone in the upper-right corner of the Code window, and copy the URL. 3. Open the Git command window (Git Bash on Git for Windows). Go to the folder where you want the code from the repo stored on your computer, and run git clone , followed by the path copied from Clone URL in the previous step. See the following example: Git downloads a copy of the code in a new folder for you to work with. The download includes all commits and branches from the repo. 4. Switch your directory to the repository that you cloned. Keep the command window open (use it in the following steps). Git branches isolate your changes from other work being done in the project. The recommended Git workflow uses a new branch for every feature or fix that you work on. Create branches by using the branch command. This command creates a reference in Git for the new branch. It
- 35. git branch users/jamal/feature1 git checkout users/jamal/feature1 git checkout main git pull origin main git branch users/jamal/feature1 git checkout users/jamal/feature1 git pull origin main:users/jamal/feature1 git pull origin main:users/jamal/feature1 git checkout feature1 Work with the code also creates a pointer back to the parent commit so Git can keep a history of changes as you add commits to the branch. Git always adds new commits to the current local branch. Check what branch you're working on before you commit so that you don't commit changes to the wrong branch. Switch between local branches by using the checkout command. Git will change the files on your computer to match the latest commit on the checked-out branch. In this step, we'll create a working branch and make a change to the files on your computer in that branch. Use the branch command to create the branch and checkout to switch to that branch. In the following example, the new branch is named users/jamal/feature1 . When you create a branch from the command line, the branch is based on the currently checked-out branch. When you clone the repository, the default branch (typically main ) is checked out. Because you cloned, your local copy of main has the latest changes. If you're working with a previously cloned repository, ensure that you've checked out the right branch ( git checkout main ) and that it's up to date ( git pull origin main ) before you create your new branch. You can replace the first three commands in the previous example with the following command, which creates a new branch named users/jamal/feature1 based on the latest main branch. Switch back to the Git Bash window that you used in the previous section. Run the following commands to create and check out a new branch based on the main branch. Browse to the location of the repository on your local computer, make an edit to one of the files, and save it. If you're adding code from your local computer to the repository, you can add it here by copying it to the folder where you cloned the repository. In the following steps, we make a change to the files on your computer, commit the changes locally, and push the commit to the repo stored on the server. We can then view the changes. 1. Browse to the folder on your computer where you cloned the repo, open the README.md file in your editor of choice, and make some changes. Then save and close the file. 2. In the Git command window, go to the contoso-demo directory by entering the following command:
- 36. Review and merge your changes with a pull request cd contoso-demo git add . git commit -m "My first commit" git push origin users/jamal/feature1 3. Commit your changes by entering the following commands in the Git command window: The git add . command stages any new or changed files, and git commit -m creates a commit with the specified commit message. 4. Push your changes to the Git repo on the server. Enter the following command into the Git command window: Your code is now shared to the remote repository, in a branch named users/jamal/feature1 . To merge the code from your working branch into the main branch, use a pull request. Pull requests combine the review and merge of your code into a single collaborative process. After you’re done fixing a bug or new feature in a branch, create a new pull request. Add the members of the team to the pull request so they can review and vote on your changes. Use pull requests to review works in progress and get early feedback on changes. There’s no commitment to merge the changes because you can abandon the pull request at any time. This example shows the basic steps of creating and completing a pull request. 1. From your web browser, open the team project for your organization and select Repos > Files. If you kept your browser open after getting the clone URL, you can just switch back to it. 2. Select Create a pull request in the upper-right corner of the Files window. If you don't see a message like You updated users/jamal/feature1 just now, refresh your browser.
- 37. 3. New pull requests are configured to merge your branch into the default branch, which in this example is main . The title and description are pre-populated with your commit message. You can add reviewers and link work items to your pull request. You can review the files included in the pull request at the bottom of the New Pull Request window.
- 38. Select Create to create the pull request. 4. You can view the details of your pull request from the Overview tab. You can also view the changed files, updates, and commits in your pull request from the other tabs. Select Complete to begin the process of completing the pull request. 5. Select Complete merge to complete the pull request and merge your code into the main branch.
- 39. NOTE This example shows the basic steps of creating and completing a pull request. To learn more about pull requests, including voting and reviewing, commenting, autocomplete, and more, see Create, view, and manage pull requests. git clone https://dev.azure.com/contoso-ltd/MyFirstProject/_git/contoso-demo cd fabrikam-web 1. From your web browser, open the team project for your organization and select the Code page. If you don't have a team project, create one now. 2. Select Clone in the upper-right corner of the Code page and copy the Clone URL. 3. Open the Git command window, for example Git Bash on Git for Windows, and browse to the folder where you want the code from the repo that is stored on your computer. Run git clone followed by the path copied from the Clone URL in the previous section, as shown in the following example. Git downloads a copy of the code into a new folder for you to work with. The download includes all commits and branches from the repo. 4. Switch your directory to the repository that you cloned. Keep this command window open, because you'll use it in the following steps. Your changes are now merged into the main branch, and your users/jamal/feature1 branch is deleted on the remote repository. To delete your local copy of the branch, switch back to your Git Bash command prompt and
- 40. git checkout main git pull origin main git branch -d users/jamal/feature1 View history run the following commands. The git checkout main command switches you to the main branch. The git pull origin main command pulls down the latest version of the code in the main branch, including your changes and the fact that users/jamal/feature1 was merged. The git branch -d users/jamal/feature1 command deletes your local copy of that branch. Now you're ready to create a new branch, write some code, and do it again. 1. Switch back to the web portal, and select History from the Code page to view your new commit. 2. Switch to the Files tab, and select the README file to view your changes. 1. Switch back to the web portal, and select History from the Code tab to view your new commit. Two commits appear: the first commit, where the README and .gitignore were added upon repo creation, and the commit you just made.
- 41. Next steps 2. Switch to the Files tab, and select the README file to view your changes. Set up continuous integration & delivery or learn more about working with a Git repo.
- 42. Create your first pipeline 6/9/2022 • 26 minutes to read • Edit Online Prerequisites - Azure DevOps Create your first pipeline Get the Java sample code https://github.com/MicrosoftDocs/pipelines-java Create your first Java pipeline Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 This is a step-by-step guide to using Azure Pipelines to build a sample application. This guide uses YAML pipelines configured with the YAML pipeline editor. If you'd like to use Classic pipelines instead, see Define your Classic pipeline. Make sure you have the following items: A GitHub account where you can create a repository. Create one for free. An Azure DevOps organization. Create one for free. If your team already has one, then make sure you're an administrator of the Azure DevOps project that you want to use. An ability to run pipelines on Microsoft-hosted agents. You can either purchase a parallel job or you can request a free tier. Java .NET Python JavaScript Azure CLI (Java) To get started, fork the following repository into your GitHub account. 1. Sign-in to your Azure DevOps organization and go to your project. 2. Go to Pipelines, and then select New pipeline. 3. Do the steps of the wizard by first selecting GitHub as the location of your source code. 4. You might be redirected to GitHub to sign in. If so, enter your GitHub credentials. 5. When you see the list of repositories, select your repository. 6. You might be redirected to GitHub to install the Azure Pipelines app. If so, select Approve & install. 7. Azure Pipelines will analyze your repository and recommend the Maven pipeline template. 8. When your new pipeline appears, take a look at the YAML to see what it does. When you're ready, select Save and run.
- 43. Add a status badge to your repository NOTE 9. You're prompted to commit a new azure-pipelines.yml file to your repository. After you're happy with the message, select Save and run again. If you want to watch your pipeline in action, select the build job. You just created and ran a pipeline that we automatically created for you, because your code appeared to be a good match for the Maven template. You now have a working YAML pipeline ( azure-pipelines.yml ) in your repository that's ready for you to customize! 10. When you're ready to make changes to your pipeline, select it in the Pipelines page, and then Edit the azure-pipelines.yml file. Learn more about working with Java in your pipeline. Many developers like to show that they're keeping their code quality high by displaying a status badge in their repo. To copy the status badge to your clipboard: 1. In Azure Pipelines, go to the Pipelines page to view the list of pipelines. Select the pipeline you created in the previous section. 2. Select , and then select Status badge. 3. Select Status badge. 4. Copy the sample Markdown from the Sample markdown section. Now with the badge Markdown in your clipboard, take the following steps in GitHub: 1. Go to the list of files and select Readme.md . Select the pencil icon to edit. 2. Paste the status badge Markdown at the beginning of the file. 3. Commit the change to the main branch. 4. Notice that the status badge appears in the description of your repository. To configure anonymous access to badges for private projects: 1. Navigate to Project Settings 2. Open the Settings tab under Pipelines 3. Toggle the Disable anonymous access to badges slider under General Even in a private project, anonymous badge access is enabled by default. With anonymous badge access enabled, users outside your organization might be able to query information such as project names, branch names, job names, and build status through the badge status API.
- 44. NOTE Prerequisites Initialize your repository Because you just changed the Readme.md file in this repository, Azure Pipelines automatically builds your code, according to the configuration in the azure-pipelines.yml file at the root of your repository. Back in Azure Pipelines, observe that a new run appears. Each time you make an edit, Azure Pipelines starts a new run. In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases. We'll show you how to use the classic editor in Azure DevOps Server 2019 to create a build and release that prints "Hello world". We'll show you how to use the classic editor in TFS to create a build and a release that prints "Hello world". A self-hosted Windows agent. If you already have a repository in your project, you can skip to the next step: Skip to adding a script to your repo 1. Go to Azure Repos. (The Code hub in the previous navigation) 2. If your project is empty, you will be greeted with a screen to help you add code to your repository. Choose the bottom choice to initialize your repo with a readme file:
- 45. Add a script to your repository 1. Navigate to your repository by clicking Code in the top navigation. 2. If your project is empty, you will be greeted with a screen to help you add code to your repository. Choose the bottom choice to initialize your repo with a readme file: Create a PowerShell script that prints Hello world .
- 46. HelloWorld.ps1 Write-Host "Hello world" 1. Go to Azure Repos. 2. Add a file. 3. In the dialog box, name your new file and create it. 4. Copy and paste this script. 5. Commit (save) the file. 1. Go to the Code hub. 2. Add a file. TFS 2018.2 TFS 2018 RTM HelloWorld.ps1 Write-Host "Hello world" 1. In the dialog box, name your new file and create it. 2. Copy and paste this script.
- 47. Create a build pipeline 3. Commit (save) the file. In this tutorial, our focus is on CI/CD, so we're keeping the code part simple. We're working in an Azure Repos Git repository directly in your web browser. When you're ready to begin building and deploying a real app, you can use a wide range of version control clients and services with Azure Pipelines CI builds. Learn more. Create a build pipeline that prints "Hello world." 1. Select Azure Pipelines, it should automatically take you to the Builds page. 2. Create a new pipeline. For new Azure DevOps users, this will automatically take you to the YAML pipeline creation experience. To get to the classic editor and complete this guide, you must turn off the preview feature for the New YAML pipeline creation experience:
- 48. 3. Make sure that the source, project, repository, and default branch match the location in which you created the script. 4. Start with an Empty job. 5. On the left side, select Pipeline and specify whatever Name you want to use. For the Agent pool, select Hosted VS2017. 6. On the left side, select the plus sign ( + ) to add a task to Job 1. On the right side, select the Utility category, select the PowerShell task from the list, and then choose Add. 7. On the left side, select your new PowerShell script task. 8. For the Script Path argument, select the button to browse your repository and select the script you created.
- 49. 9. Select Save & queue, and then select Save. 10. Select Build and Release, and then choose Builds. 11. Create a new pipeline. 12. Start with an empty pipeline 13. Select Pipeline and specify whatever Name you want to use. For the Agent pool, select Default. 14. On the left side, select + Add Task to add a task to the job, and then on the right side select the Utility category, select the PowerShell task, and then choose Add. 15. On the left side, select your new PowerShell script task. 16. For the Script Path argument, select the button to browse your repository and select the script you
- 50. Publish an artifact from your build created. 17. Select Save & queue, and then select Save. A build pipeline is the entity through which you define your automated build pipeline. In the build pipeline, you compose a set of tasks, each of which perform a step in your build. The task catalog provides a rich set of tasks for you to get started. You can also add PowerShell or shell scripts to your build pipeline. A typical build produces an artifact that can then be deployed to various stages in a release. Here to demonstrate the capability in a simple way, we'll simply publish the script as the artifact. 1. On the Tasks tab, select the plus sign ( + ) to add a task to Job 1. 2. Select the Utility category, select the Publish Build Artifacts task, and then select Add. Path to publish: Select the button to browse and select the script you created. Artifact name: Enter drop . Artifact publish location: Select Azure Artifacts/TFS. 1. On the Tasks tab, select Add Task. 2. Select the Utility category, select the Publish Build Artifacts task, and then select Add.
- 51. Enable continuous integration (CI) Save and queue the build Path to Publish: Select the button to browse and select the script you created. Artifact Name: Enter drop . Artifact Type: Select Server. Artifacts are the files that you want your build to produce. Artifacts can be nearly anything your team needs to test or deploy your app. For example, you've got a .DLL and .EXE executable files and .PDB symbols file of a C# or C++ .NET Windows app. To enable you to produce artifacts, we provide tools such as copying with pattern matching, and a staging directory in which you can gather your artifacts before publishing them. See Artifacts in Azure Pipelines. 1. Select the Triggers tab. 2. Enable Continuous integration. A continuous integration trigger on a build pipeline indicates that the system should automatically queue a new build whenever a code change is committed. You can make the trigger more general or more specific, and also schedule your build (for example, on a nightly basis). See Build triggers. Save and queue a build manually and test your build pipeline. 1. Select Save & queue, and then select Save & queue. 2. On the dialog box, select Save & queue once more. This queues a new build on the Microsoft-hosted agent. 3. You see a link to the new build on the top of the page.
- 52. Choose the link to watch the new build as it happens. Once the agent is allocated, you'll start seeing the live logs of the build. Notice that the PowerShell script is run as part of the build, and that "Hello world" is printed to the console. 4. Go to the build summary. On the Artifacts tab of the build, notice that the script is published as an artifact. 1. Select Save & queue, and then select Save & queue.
- 53. 2. On the dialog box, select Save & queue once more. This queues a new build on the Microsoft-hosted agent. 3. You see a link to the new build on the top of the page. Choose the link to watch the new build as it happens. Once the agent is allocated, you'll start seeing the live logs of the build. Notice that the PowerShell script is run as part of the build, and that "Hello world" is printed to the console. TFS 2018.2 TFS 2018 RTM 4. Go to the build summary. 5. On the Artifacts tab of the build, notice that the script is published as an artifact.
- 54. Add some variables and commit a change to your script You can view a summary of all the builds or drill into the logs for each build at any time by navigating to the Builds tab in Azure Pipelines. For each build, you can also view a list of commits that were built and the work items associated with each commit. You can also run tests in each build and analyze the test failures. We'll pass some build variables to the script to make our pipeline a bit more interesting. Then we'll commit a change to a script and watch the CI pipeline run automatically to validate the change. 1. Edit your build pipeline. 2. On the Tasks tab, select the PowerShell script task. 3. Add these arguments. TFS 2018.2 TFS 2018 RTM
- 55. -greeter "$(Build.RequestedFor)" -trigger "$(Build.Reason)" Arguments Finally, save the build pipeline. Next you'll add the arguments to your script. Param( [string]$greeter, [string]$trigger ) Write-Host "Hello world" from $greeter Write-Host Trigger: $trigger 1. Go to your Files in Azure Repos (the Code hub in the previous navigation and TFS). 2. Select the HelloWorld.ps1 file, and then Edit the file. 3. Change the script as follows: 4. Commit (save) the script. Now you can see the results of your changes. Go to Azure Pipelines and select Queued. Notice under the Queued or running section that a build is automatically triggered by the change that you committed. Now you can see the results of your changes. Go to the Build and Release page and select Queued. Notice under the Queued or running section that a build is automatically triggered by the change that you committed. 1. Select the new build that was created and view its log. 2. Notice that the person who changed the code has their name printed in the greeting message. You also see printed that this was a CI build.
- 56. You've got a build pipeline. What's next? Create a release pipeline We just introduced the concept of build variables in these steps. We printed the value of a variable that is automatically predefined and initialized by the system. You can also define custom variables and use them either in arguments to your tasks, or as environment variables within your scripts. To learn more about variables, see Build variables. You've created a build pipeline that automatically builds and validates whatever code is checked in by your team. At this point, you can continue to the next section to learn about release pipelines. Or, if you prefer, you can skip ahead to create a build pipeline for your app. Define the process for running the script in two stages. 1. Go to the Pipelines tab, and then select Releases. 2. Select the action to create a New pipeline. If a release pipeline is already created, select the plus sign ( + ) and then select Create a release pipeline. 3. Select the action to start with an Empty job. 4. Name the stage QA. 5. In the Artifacts panel, select + Add and specify a Source (Build pipeline). Select Add. 6. Select the Lightning bolt to trigger continuous deployment and then enable the Continuous deployment trigger on the right.
- 57. -greeter "$(Release.RequestedFor)" -trigger "$(Build.DefinitionName)" 7. Select the Tasks tab and select your QA stage. 8. Select the plus sign ( + ) for the job to add a task to the job. 9. On the Add tasks dialog box, select Utility, locate the PowerShell task, and then select its Add button. 10. On the left side, select your new PowerShell script task. 11. For the Script Path argument, select the button to browse your artifacts and select the script you created. 12. Add these Arguments: 13. On the Pipeline tab, select the QA stage and select Clone. 14. Rename the cloned stage Production. 15. Rename the release pipeline Hello world.
- 58. 16. Save the release pipeline. 1. Go to the Build and Release tab, and then select Releases. 2. Select the action to create a New pipeline. If a release pipeline is already created, select the plus sign ( + ) and then select Create a release definition. 3. Select the action to start with an Empty definition. 4. Name the stage QA. 5. In the Artifacts panel, select + Add and specify a Source (Build pipeline). Select Add. 6. Select the Lightning bolt to trigger continuous deployment and then enable the Continuous deployment trigger on the right. TFS 2018.2 TFS 2018 RTM 7. Select the Tasks tab and select your QA stage. 8. Select the plus sign ( + ) for the job to add a task to the job. 9. On the Add tasks dialog box, select Utility, locate the PowerShell task, and then select its Add button. 10. On the left side, select your new PowerShell script task. 11. For the Script Path argument, select the button to browse your artifacts and select the script you
- 59. Deploy a release -greeter "$(Release.RequestedFor)" -trigger "$(Build.DefinitionName)" created. 12. Add these Arguments: 13. On the Pipeline tab, select the QA stage and select Clone. 14. Rename the cloned stage Production. 15. Rename the release pipeline Hello world. 16. Save the release pipeline. A release pipeline is a collection of stages to which the application build artifacts are deployed. It also defines the actual deployment pipeline for each stage, as well as how the artifacts are promoted from one stage to another. Also, notice that we used some variables in our script arguments. In this case, we used release variables instead of the build variables we used for the build pipeline.
- 60. Run the script in each stage. 1. Create a new release. When Create new release appears, select Create. 2. Open the release that you created. 3. View the logs to get real-time data about the release. 4. Create a new release.
- 61. Change your code and watch it automatically deploy to production When Create new release appears, select Create (TFS 2018.2) or Queue (TFS 2018 RTM). 5. Open the release that you created. 6. View the logs to get real-time data about the release. You can track the progress of each release to see if it has been deployed to all the stages. You can track the commits that are part of each release, the associated work items, and the results of any test runs that you've added to the release pipeline. We'll make one more change to the script. This time it will automatically build and then get deployed all the way to the production stage. 1. Go to the Code hub, Files tab, edit the HelloWorld.ps1 file, and change it as follows:
- 62. Next steps Param( [string]$greeter, [string]$trigger ) Write-Host "Hello world" from $greeter Write-Host Trigger: $trigger Write-Host "Now that you've got CI/CD, you can automatically deploy your app every time your team checks in code." 2. Commit (save) the script. 3. Select the Builds tab to see the build queued and run. 4. After the build is completed, select the Releases tab, open the new release, and then go to the Logs. Your new code automatically is deployed in the QA stage, and then in the Production stage. In many cases, you probably would want to edit the release pipeline so that the production deployment happens only after some testing and approvals are in place. See Approvals and gates overview. You've just learned how to create your first pipeline in Azure. Learn more about configuring pipelines in the language of your choice: .NET Core
- 63. Clean up LANGUAGE TEMPLATE TO USE .NET ASP.NET .NET Core ASP.NET Core C++ .NET Desktop Go Go Java Gradle Go Java Node.js Python Containers Or, you can proceed to customize the pipeline you just created. To run your pipeline in a container, see Container jobs. For details about building GitHub repositories, see Build GitHub repositories. To learn how to publish your Pipeline Artifacts, see Publish Pipeline Artifacts. To find out what else you can do in YAML pipelines, see YAML schema reference. If you created any test pipelines, they are easy to delete when you are done with them. Browser Azure DevOps CLI To delete a pipeline, navigate to the summary page for that pipeline, and choose Delete from the ... menu at the top-right of the page. Type the name of the pipeline to confirm, and choose Delete. You've learned the basics of creating and running a pipeline. Now you're ready to configure your build pipeline for the programming language you're using. Go ahead and create a new build pipeline, and this time, use one of the following templates.
- 64. JavaScript Node.js Xcode Xcode LANGUAGE TEMPLATE TO USE FAQ Where can I read articles about DevOps and CI/CD? What version control system can I use? How do I replicate a pipeline? What is Continuous Integration? What is Continuous Delivery? What is DevOps? When you're ready to get going with CI/CD for your app, you can use the version control system of your choice: Clients Visual Studio Code for Windows, macOS, and Linux Visual Studio with Git for Windows or Visual Studio for Mac Eclipse Xcode IntelliJ Command line Services Azure Pipelines Git service providers such as GitHub and Bitbucket Cloud Subversion Clients Visual Studio Code for Windows, macOS, and Linux Visual Studio with Git for Windows or Visual Studio for Mac Visual Studio with TFVC Eclipse Xcode IntelliJ Command line Services Azure Pipelines Git service providers such as GitHub and Bitbucket Cloud Subversion If your pipeline has a pattern that you want to replicate in other pipelines, clone it, export it, or save it as a template.
- 65. TIP After you clone a pipeline, you can make changes and then save it. After you export a pipeline, you can import it from the All pipelines tab. After you create a template, your team members can use it to follow the pattern in new pipelines. If you're using the New Build Editor, then your custom templates are shown at the bottom of the list.
- 66. How do I work with drafts? If you're editing a build pipeline and you want to test some changes that are not yet ready for production, you can save it as a draft. You can edit and test your draft as needed. When you're ready, you can publish the draft to merge the changes into your build pipeline.
- 67. How can I delete a pipeline? What else can I do when I queue a build? Where can I learn more about pipeline settings? Or, if you decide to discard the draft, you can delete it from the All Pipeline tab shown above. To delete a pipeline, navigate to the summary page for that pipeline, and choose Delete from the ... menu in the top-right of the page. Type the name of the pipeline to confirm, and choose Delete. You can queue builds automatically or manually. When you manually queue a build, you can, for a single run of the build: Specify the pool into which the build goes. Add and modify some variables. Add demands. In a Git repository Build a branch or a tag. Build a commit. In a TFVC repository Specify the source version as a label or changeset. Run a private build of a shelveset. (You can use this option on either a Microsoft-hosted agent or a self-hosted agent.) You can queue builds automatically or manually. When you manually queue a build, you can, for a single run of the build: Specify the pool into which the build goes. Add and modify some variables. Add demands. In a Git repository Build a branch or a tag. Build a commit. To learn more about build pipeline settings, see: Getting sources Tasks Variables Triggers Options Retention History To learn more about pipeline settings, see: Getting sources
- 68. How do I programmatically create a build pipeline? NOTE Tasks Variables Triggers Retention History REST API Reference: Create a build pipeline You can also manage builds and build pipelines from the command line or scripts using the Azure Pipelines CLI.
- 69. Plan and track work in Azure Boards 6/9/2022 • 21 minutes to read • Edit Online NOTE WORK ITEM TYPES BACKLOG HIERARCHY Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 You track your work by creating work items. This article walks you through creating issues and tasks using a Kanban board. You can learn the Basic process or the Agile process for creating these items. Choose one of the following four system processes—Agile, Basic, Scrum, or Capability Maturity Model Integration (CMMI)—for guidance depending on what process was selected for your project. For an overview of each of these processes, see Choose a process. The Basic process is available when you add a project to Azure DevOps Services or Azure DevOps Server 2019 Update 1. For earlier on-premises deployments, choose Agile, Scrum, or CMMI process. Agile process Basic process Scrum process CMMI process The Agile process provides several work item types—for example, user stories, tasks, bugs, features, and epics among others—to plan and track work. We recommend you start by adding user stories. If you need to group them into a hierarchy, you can define features. To track other details of work, you can add tasks to a user story.
- 70. WORK ITEM TYPES BACKLOG HIERARCHY Prerequisites Within each work item form, you can describe the work to be done, assign work to project contributors, track status, and collaborate with others through the Discussion section. Here we show how to add user stories and child tasks from the web portal and add details to those work items. After you connect to a project, you can add work items. If you don't have a project yet, create one in Azure DevOps. To add work items to a board, and use all other board features, you must be granted Basic access and have been added as a member of the Contributors or Project Administrators group. If you have been granted Stakeholder access for a private project and have been added as a member of the Contributors or Project Administrators group, you can view boards, open and modify work items, and add child tasks to a checklist. However, you can't reorder or reparent a backlog item using drag-and-drop, nor update a field on a card. If you have been granted Stakeholder access for a public project, and have been added as a member of the Contributors or Project Administrators group, you have full access to all Boards features. After you connect to a project, you can add work items. If you don't have a project yet, create one in Azure DevOps. To add work items to a board, and use all other board features, you must be granted Basic access and have been added as a member of the Contributors or Project Administrators group. If you have been granted Stakeholder access and have been added as a member of the Contributors or Project Administrators group, you can view boards, open and modify work items, and add child tasks to a checklist. However, you can't reorder or reparent a backlog item using drag-and-drop, nor update a field on a card.
- 71. NOTE NOTE Open your Kanban board The ability for Stakeholders to drag-and-drop cards to different columns requires installation of Azure DevOps Server 2020.1 update. To learn more, see Azure DevOps Server 2020 Update 1 RC1 Release Notes, Boards. After you connect to a project, you can add work items. If you don't have a project yet, create one in Azure DevOps. To add work items to a board, and use all other board features, you must be granted Basic access and have been added as a member of the Contributors or Project Administrators group. If you have been granted Stakeholder access for a private project and have been added as a member of the Contributors or Project Administrators group, you can view boards, open and modify work items, and add child tasks to a checklist. However, you can't update the status of a backlog item or reorder or reparent a backlog item using drag-and-drop, nor update a field on a card. If you have been granted Stakeholder access for a public project, and have been added as a member of the Contributors or Project Administrators group, you have full access to all Boards features. For details, see Default permissions and access for Azure Boards The images shown in this article correspond to the latest version of Azure Boards. While they may differ from those shown in earlier, on-premises versions of Azure DevOps, they are similar in the functions described unless otherwise noted. A Kanban board is provisioned with the addition of each project and each team. You can only create or add Kanban boards to a project by adding another team. To learn more, see About teams and Agile tools. Agile process Basic process Scrum process CMMI process The User Stories Kanban board is the best tool for quickly adding user stories and child tasks. To open, choose Boards>Boards.
- 72. Add work items to your board Add details to a board item The Features Kanban board is the best tool for quickly adding features and user stories that are children of those features. To open the Features board from the Stories board, choose Features from the board selector. Work items you add to your board are automatically assigned the default Area Path and Iteration Path assigned to the team. To learn more, see Configure team settings. Agile process Basic process Scrum process CMMI process 1. From the Stories board, choose New item and start adding those stories you want to track. 2. Enter return and the system assigns a work item ID to the user story. 3. To track the work you want to manage, add as many user stories that you need. Choose the issue or user story title to open it. Change one or more field values, add a description, or make a note in the Discussion section. You can also choose the Attachments tab and drag-and-drop a file to share the file with others. Agile process Basic process
- 73. Field descriptions NOTE Scrum process CMMI process For example, here we assign the story to Raisa Pokrovskaya and we add a discussion note, at-mentioning Raisa. Choose Save & Close when done. Field Usage Title Enter a description of 255 characters or less. You can always modify the title later. Assigned To Assign the work item to the team member responsible for performing the work. Depending on the context you are working in, the drop-down menu lists only team members or contributors to the project. You can only assign work to a single user. If you need to assign work to more than one user, add a work item for each user and distinguish the work to be done by title and description. The Assigned To field only accepts user accounts that have been added to a project or team. State
- 74. When the work item is created, the State defaults to the first state in the workflow. As work progresses, update it to reflect the current status. Reason Use the default first. Update it when you change state as need. Each State is associated with a default reason. Area (Path) Choose the area path associated with the product or team, or leave blank until assigned during a planning meeting. To change the dropdown list of areas, see Define area paths and assign to a team. Iteration (Path) Choose the sprint or iteration in which the work is to be completed, or leave it blank and assign it later during a planning meeting. To change the drop-down list of iterations, see Define iteration paths and configure team iterations. Description Provide enough detail to create shared understanding of scope and support estimation efforts. Focus on the user, what they want to accomplish, and why. Don't describe how to develop the product. Do provide sufficient details so that your team can write tasks and test cases to implement the item. Acceptance Criteria Provide the criteria to be met before the work item can be closed. Define what "Done" means by describing the criteria for the team to use to verify whether the backlog item or bug fix is fully implemented. Before work begins, describe the criteria for customer acceptance as clearly as possible. Have conversations between the team and customers to determine the acceptance criteria. These criteria help ensure a common understanding within the team to meet customers' expectations. Also, this information provides the basis for acceptance testing. Priority A subjective rating of the issue or task it relates to the business. You can specify the following values: 1: Product cannot ship without the successful resolution of the work item, and it should be addressed as soon as possible. 2: Product cannot ship without the successful resolution of the work item, but it does not need to be addressed immediately. 3: Resolution of the work item is optional based on resources, time, and risk. 4: Resolution of the work item is not required. Value Area A subjective rating of the issue or task it relates to the business. You can specify the following values: Architectural: Technical services to implement business features that deliver solution . Business: Services that fulfill customers or stakeholder needs that directly deliver customer value to support the business (Default). Effort, Story Points, Size Provide a relative estimate of the amount of work required to complete an issue. Most Agile methods recommend that you set estimates for backlog items based on relative size of work. Such methods include
- 75. Update work status TIP Add tasks TIP powers of 2 (1, 2, 4, 8) and the Fibonacci sequence (1, 2, 3, 5, 8, etc.). Use any numeric unit of measurement your team prefers. The estimates you set are used to calculate team velocity and forecast sprints. The State field tracks the status of a work item. With the Kanban board, you can quickly update the status of backlog items by dragging and dropping them to a different column. This feature requires that you have Basic access or higher. Agile process Basic process Scrum process CMMI process As work starts, drag the user story card from the Backlog column to the Active column. Once work is ready for review, move to the Resolved column. After it's reviewed and accepted, move to the Closed column. You can add or rename columns as needed, see Customize your board. You can add or rename columns as needed, see Customize your board. Task checklists provide a quick and easy way to track elements of work that are important to support completing a backlog item. Also, you can assign individual tasks to different team members. Tasks that you create from the Kanban board are automatically assigned the Area Path and Iteration Path of their parent work item. Tasks that you create from the Kanban board show up on your sprint taskboard. Also, tasks that you create from the sprint backlog or taskboard show up within tasks checklists on the Kanban board. Agile process Basic process Scrum process CMMI process
- 76. 1. To start adding tasks, choose the actions icon for the story and select the Add Task option. Enter a title for the task and type Enter when done. 2. If you have many tasks to add, keep typing your task titles and type Enter. 3. You can mark a task as done, expand or collapse the task checklist, or reorder and reparent tasks.
- 77. Add details to a task MARK A TASK AS DONE REORDER AND REPARENT TASKS EXPAND OR COLLAPSE THE CHECKLIST To mark a task as complete, check the task checkbox. The task State changes to Done. To reorder a task, drag it within the checklist. To reparent a the task, drag it to another issue on the board. To expand or collapse a task checklist, simply choose the task annotation. If you have details you want to add about a task, choose the title, to open it. Change one or more field values, add a description, or make a note in the Discussion section. Choose Save & Close when done. Agile process Basic process Scrum process CMMI process Here we assign the task to Christie Church.
- 78. Field descriptions NOTE In addition to the fields you can define for a backlog item—user story, issue, product backlog item, or requirement—you can specify the following fields for a task to support capacity and time tracking. There are no inherent time units associated with this field even though the taskboard always shows "h" for hours in relationship to Remaining Work. You can specify work in any unit of measurement your team chooses. Field Usage Activity The type of activity that's required to do a task.To learn more about how this field is used, see Capacity planning. Allowed values are: Deployment Design Development Documentation Requirements Testing Discipline (CMMI process)
- 79. Capture comments in the Discussion section The type of activity that's required to do a task.To learn more about how this field is used, see Capacity planning. Allowed values are: Analysis Development Test User Education User Experience Original Estimate The amount of estimated work required to complete a task. Typically, this field doesn't change after it is assigned. Remaining Work The amount of work that remains to finish a task. You can specify work in hours or in days. As work progresses, update this field. It's used to calculate capacity charts and the sprint burndown chart. If you divide a task into subtasks, specify Remaining Work for the subtasks only. Completed Work The amount of work spent implementing a task. Enter a value for this field when you complete the task. Task Type (CMMI only) Select the kind of task to implement from the allowed values: Corrective Action Mitigation Action Planned Use the Discussion section to add and review comments made about the work being performed. The rich text editor tool bar displays below the text entry area. It appears when you click your cursor within each text box that supports text formatting.
- 80. NOTE Mention someone, a group, work item, or pull request Edit or delete a comment NOTE There is no Discussion work item field. To query work items with comments entered in the Discussion area, you filter on the History field. The full content of the text entered into the Discussion text box is added to the History field. Choose one of these icons — , , or — to open a menu of recent entries you've made to mention someone, link to a work item, or link to a pull request. Or to open the same menu, you can type @, #, or !. @mention drop-down menu" /> Type a name, or enter a number and the menu list will filter to match your entry. Choose the entry you want to add. You can bring a group into the discussion by typing @ and the group name, such as a team or security group. If you need to edit or delete any of your discussion comments, choose Edit or choose the actions icon and then choose Delete. Editing and deleting comments requires Azure DevOps Server 2019 Update 1 or later version. After updating the comment, choose Update. To delete the comment, you'll need to confirm that you want to delete it. A full audit trail of all edited and deleted comments is maintained in the History tab on the work item form. Use the @mention control to notify another team member about the discussion. Simply type @ and their name. To reference a work item, use the #ID control. Type # and a list of work items that you've recently
- 81. IMPORTANT Add a reaction to a comment Next step Related articles referenced will appear from which you can select. To reference a work item, use the #ID control. Type # and a list of work items that you've recently referenced will appear from which you can select. You can't edit or delete comments once you've entered them. For on-premises Azure DevOps Server, you must configure an SMTP server in order for team members to receive notifications. Add one or more reactions to a comment by choosing a smiley icon at the upper-right corner of any comment. Or, choose from the icons at the bottom of a comment next to any existing reactions. To remove your reaction, choose the reaction on the bottom of your comment. The following image shows an example of the experience of adding a reaction, as well as the display of reactions on a comment. Customize your board Azure Boards FAQs Index to field descriptions Add tags to issues or tasks
- 82. Add, run, update inline tests 6/9/2022 • 3 minutes to read • Edit Online Open your Kanban board Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Learn how to add, run, update, and expand and collapse inline tests in Azure DevOps. To start manual testing, add the test to the user story or bug that you want to test. From the Kanban board, you can define inline tests or a set of manual tests for a backlog item. You also can run these tests and update their status. If you're new to working with the Kanban board, see the Kanban quickstart. Tests you create from the Kanban board are automatically linked to the user story or backlog item. 1. From your web browser, open the project for your organization and select Azure Boards. If you don't have a project, create one now. If you haven't been added as a team member, get invited now. The URL follows this pattern: https://dev.azure.com/fabrikamfiber/_boards/board If you don't see the team or project you want, select Azure DevOps to browse all projects and teams. 2. Select Boards to open the Kanban board. 1. From your web browser, open the project for your organization and select Azure Boards. If you don't have a project, create one now. If you haven't been added as a team member, get invited now. The URL follows this pattern: https://dev.azure.com/fabrikamfiber/_backlogs/board If you don't see the team or project you want, select Azure DevOps to browse all projects and teams. 2. Select Board to open the Kanban board.
- 83. Add tests 1. To add tests, open the menu for a work item. Inline tests are the same as test cases in a test suite. A default test plan and test suite automatically get created under which the manual test cases are grouped.
- 84. For example, a test suite is created for the following user story, and inline tests are added to that suite. User story 314 is highlighted. It has two manual tests defined with the IDs 337 and 341. 2. If you have a number of tests to add, enter each title and select Enter. To add details to the test case, open it. You can select the title, double-select the inline item, or open the context menu and choose Open.
- 85. To learn more about how to define tests, see Create manual tests. Before you run the test, you must add details. 1. To add tests, open the menu for the work item. Inline tests are the same as test cases in a test suite. A default test plan and test suite automatically get created under which the manual test cases are grouped. For example, a test suite gets created for each user story, and all inline tests are added to that suite. The following user story 152 is highlighted. It has three manual tests defined with the IDs 153, 155, and 161.
- 86. To learn more about test plans and test suites, see Plan your tests. 2. If you have a number of tests to add, enter each title and select Enter. To add details to the test case, open it. You can select the title, double-select the inline item, or open the context menu and choose Open.
- 87. Run a test To learn more about how to define tests, see Create manual tests. Before you run the test, you must add details. Run the test by selecting Run test from the actions menu for the inline test.
- 88. Microsoft Test Runner starts in a new browser instance. For information on how to run a test, see Run manual tests. Run the test by selecting Run test from the actions menu for the inline test. Microsoft Test Runner starts in a new browser instance. For information on how to run a test, see Run manual tests.
- 89. Update the status of a test You can update the status of the test from the actions menu. When you update the status of tests, you can track test results. You can update the status of the test from the actions menu.
- 90. Expand or collapse inline tests When you update the status of tests, you can track test results. When you first open the Kanban board, you'll see an unexpanded view of checklists and tests. Select the inline test summary to expand a collapsed set of tests. Select the same summary to collapse an expanded list. When you first open the Kanban board, you'll see an unexpanded view of checklists.
- 91. Next steps Related articles Select the inline test summary to expand a collapsed set of tests. Select the same summary to collapse an expanded list. Kanban quickstart Learn more about test case management Exploratory test your web app directly in your browser Essential services Client-server tools Software development roles
- 92. Tutorial: Track a user story, bug, issue, or other work item or pull request 6/9/2022 • 5 minutes to read • Edit Online NOTE Prerequisites Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 To get notified of changes made to a specific work item or a pull request, you can choose to follow them. The Follow feature provides an improvised way of getting notified on a case-by-case basis. If you want to subscribe to receive notifications automatically based on changes that occur based on your targeted set of criteria, see Manage personal notifications. For example, you can create a subscription to automatically get notified whenever a work item that you created or that was assigned to you is modified. Notification subscriptions allow you to personalize the notifications you receive automatically based on additional criteria you specify for yourself, a team, or a project. For example, you can create a subscription and add field criteria to receive changes based on one or more of the following templates. This article shows you how to: Follow a work item Follow a pull request Manage work items that you're following Configure an SMTP server in order for team members to receive notifications. Connect to a project. If you don't have a project yet, create one. You must be added to a project as a member of the Contributors or Project Administrators security group. To get added, Add users to a project or team. To view or follow work items, you must be granted Stakeholder access or higher. For details, see About access levels. Also, you must have your View work items in this node and Edit work items in this node permissions set to Allow. By default, the Contributors group has this permission set. To learn more, see Set permissions and access for work tracking. To view or follow pull requests, you must have Basic access or higher.
- 93. Follow a work item You must connect to a project. If you don't have a project yet, create one. You must be added to a project as a member of the Contributors or Project Administrators security group. To get added, Add users to a project or team. To view or follow work items, you must be granted Stakeholder access or higher. For details, see About access levels. Also, you must have your View work items in this node and Edit work items in this node permissions set to Allow. By default, the Contributors group has this permission set. To learn more, see Set permissions and access for work tracking. To view or follow pull requests, you must have Basic access or higher. When you want to track the progress of a single work item, choose the follow icon. This signals the system to notify you when changes are made to the work item. If you want to specify conditions on when you'll get notified of changes, choose the gear icon and choose from the options provided. By default, you're Subscribed to receive a notification when any change is made to the work item. Choose Not Subscribed to receive notification only when you're @mentioned. Or choose Custom to receive notifications when one of the checked fields changes, State, Assigned To, or Iteration Path.
- 94. Follow a pull request Manage work items that you're following You'll only receive notifications when other members of your team modify the work item, such as adding to the discussion, changing a field value, or adding an attachment. Notifications are sent to your preferred email address, which you can change from your user profile To stop following changes, choose the following icon. To track the progress of a single pull request, choose the actions icon for the pull request, and select the Follow option. This signals the system to notify you when changes are made to the PR. You'll only receive notifications when other members of your team modify the PR, such as adding to the discussion or adding an attachment. Notifications are sent to your preferred email address, which you can change from your user profile. To stop following changes, open the PR context menu and choose the Following icon. You can review and manage all the work items you've selected to follow. Open Boards>Queries, choose All, and under My Queries, choose Followed work items.
- 95. From this view, you can view all items you're following across all projects. Also, you can complete similar actions supported with a query results view, such as: Refresh the view Add or remove visible columns Sort the order of specific columns Filter results by text or tags Set work item pane Enter full screen mode. You can also view and manage work that you're following from Boards>Work Items and pivot to Following. Open Work>Queries and choose Followed work items.
- 96. Query work items that you're following Try this next From this view, you can view all items you're following across all projects. Also, you can complete similar actions supported with a query results view, such as: Refresh the view Add or remove visible columns Sort the order of specific columns Filter results by text or tags Set work item pane Enter full screen mode. You can also view and manage work that you're following from your Project pages. To learn more, see Work across projects. You can use the @Follows macro in a query to filter a list based on work items you're following along with other query filters. For example, the following query shows how to query across all projects for active work items that you're following. You use the ID field and the In operator with the @Follows macro. Add, update, and follow a work item
- 97. Related articles Q: Can I add someone else to follow a work item or PR? Manage personal notifications View and update work items via the mobile work item form A: No, you can't add another team member to follow a work item or pull request at this time. You can subscribe them to get notified based on select criteria, such as when a work item is create or modified, or a pull request is created. For details, see Manage team notifications.
- 98. Get started as a Stakeholder 6/9/2022 • 16 minutes to read • Edit Online NOTE NOTE Connect to the web portal of a project Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Stakeholders are users with free but limited access to Azure DevOps features and functions. With Stakeholder access, you can add and modify work items, manage build and release pipelines, and view dashboards. You can check project status and provide direction, feedback, feature ideas, and business alignment to a team. For a quick overview of the features available to Stakeholders, see Stakeholder access quick reference. For public projects, Stakeholder access gives users greater access to features. To learn more, see Default roles and access for public projects. For information about working with pipelines, see these articles: Build your GitHub repository and Build OSS repositories. Stakeholders are users with free but limited access to Azure DevOps features and functions. With Stakeholder access, you can add and modify work items, view and approve pipelines, and view dashboards. You can check project status and provide direction, feedback, feature ideas, and business alignment to a team. Stakeholder access is one of several supported access levels as described in Stakeholder access quick reference. To get access as a Stakeholder, ask your organization owner or Project Collection Administrator to add you to a project with Stakeholder access. Stakeholder access is one of several supported access levels as described in Stakeholder access quick reference. To get access as a Stakeholder, ask your server administrator to add you to a security group that has Stakeholder access. Azure Boards supports several Agile methods such as Kanban and Scrum. Depending on what methods your team uses, you'll want to become familiar with other tools that Azure Boards supports. This article focuses on getting familiar with work items and the Kanban board. For additional information, see Related articles at the end of this article. Use this tutorial to learn how to do the following tasks: Sign in to a project Understand which work item types are available to your project Open the Kanban board and open a work item Add details, tags, or comments to a work item View the product backlog Find work assigned to you, or query for other work items Understand what features are and aren't available to users with Stakeholder access You must have been added to the Azure DevOps project and been granted Stakeholder or higher access level. 1. Choose the link provided in the email invitation you should have received. Or, open a browser window and enter the URL for the web portal.
- 99. Understand work items and work item types Open your Kanban board from the web portal https://dev.azure.com/OrganizationName/ProjectName http://ServerName:8080/tfs/DefaultCollection/ProjectName For example, to connect to the server named FabrikamPrime and project named Contoso, enter http://FabrikamPrime:8080/tfs/DefaultCollection/Contoso . 2. Enter your credentials. If you can't sign in, ask the organization owner or Project Administrator to add you as a member of the project with Stakeholder access. Work items support planning and tracking work. Each work item represents an object stored in the work item data store. Each work item is based on a work item type and is assigned an identifier which is unique within an organization or project collection. Different work items are used to track different types of work as described in About work items. The work item types available to you are based on the process used when your project was created—Agile, Basic, Scrum, or CMMI—as illustrated in the following images. Agile process Basic process Scrum process CMMI process The following image shows the Agile process backlog work item hierarchy. User Stories and Tasks are used to track work, Bugs track code defects, and Epics and Features are used to group work under larger scenarios. Each team can configure how they manage Bugs—at the same level as User Stories or Tasks—by configuring the Working with bugs setting. To learn more about using these work item types, see Agile process. You can start viewing work items once you connect to a project. 1. Check that you selected the right project, and select Boards > Boards. Then select the correct team from the team selector menu. To select another team's board, open the selector. Then select a different team, or select the Browse all team boards option. Or, you can enter a keyword in the search box to filter the list of team backlogs for the project.
- 100. Add work items TIP Select the star icon to make a team board a favorite. Favorite artifacts ( favorite icon) appear at the top of the team selector list. 2. Check that you selected Stories for Agile, Issues for Basic, Backlog items for Scrum, or Requirements for CMMI as the backlog level. TIP 1. Check that you selected the right project, and select Boards > Boards. Then select the correct team from the team selector menu. To select another team's board, open the selector. Then select a different team, or select the Browse all team boards option. Or, you can enter a keyword in the search box to filter the list of team backlogs for the project. Select the star icon to make a team board a favorite. Favorite artifacts ( favorite icon) appear at the top of the team selector list. 2. Check that you selected Stories for Agile, Issues for Basic, Backlog items for Scrum, or Requirements for CMMI as the backlog level. Here we have selected Backlog Items for the Scrum process. 1. To view your Kanban board, open your project from a web browser. Select Work > Backlogs > Stories, and then select Board. If you don't see Work, your screen size might be reduced. Select the three dots ( ) icon. Then select Work > Backlogs > Board. 2. To select another team, open the project and team selector. Select a different team, or select the Browse option. Your Kanban board appears. From the Kanban board, you can add work items, open them, and modify them. To add work items, open the backlog by choosing the Backlog link. To add a work item, select the plus sign, enter a title, and then press Enter.
- 101. Update status of work items NOTE Add details to a work item NOTE Or, you can add work items to the bottom of the product backlog. Open the backlog by choosing the Backlog link. From the Kanban board, you can't add work items, but you can open them and annotate them. To add work items, open the backlog by choosing the Backlog link. Also, you can't update the status of a work item by drag- and-drop to a different column or reorder cards within a column. As work completes in one stage, update the status of an item by dragging it to a downstream stage. The ability for Stakeholders to drag-and-drop cards to different columns requires installation of Azure DevOps Server 2020.1 update. To learn more, see Azure DevOps Server 2020 Update 1 RC1 Release Notes, Boards. To add information to a work item, open it by double-clicking the title or by selecting it and then typing Enter. Change one or more field values, add a description, add a tag, or add a comment in the Discussion section. You can also choose the Attachments tab and drag-and-drop or upload a file to share with others. You can only assign work to a user who has been added to the project. The work item form you see may differ from those shown in the following images. The basic functionality is the same, however, changes have been made with different versions of Azure DevOps. Agile process
- 102. Field descriptions NOTE Basic process Scrum process CMMI process For example, here we assign the story to Raisa Pokrovskaya and we add a discussion note, at-mentioning Raisa. Choose Save & Close when done. Field Usage Title Enter a description of 255 characters or less. You can always modify the title later. Assigned To Assign the work item to the team member responsible for performing the work. Depending on the context you are working in, the drop-down menu lists only team members or contributors to the project. You can only assign work to a single user. If you need to assign work to more than one user, add a work item for each user and distinguish the work to be done by title and description. The Assigned To field only accepts user accounts that have been added to a project or team. State
- 103. When the work item is created, the State defaults to the first state in the workflow. As work progresses, update it to reflect the current status. Reason Use the default first. Update it when you change state as need. Each State is associated with a default reason. Area (Path) Choose the area path associated with the product or team, or leave blank until assigned during a planning meeting. To change the dropdown list of areas, see Define area paths and assign to a team. Iteration (Path) Choose the sprint or iteration in which the work is to be completed, or leave it blank and assign it later during a planning meeting. To change the drop-down list of iterations, see Define iteration paths and configure team iterations. Description Provide enough detail to create shared understanding of scope and support estimation efforts. Focus on the user, what they want to accomplish, and why. Don't describe how to develop the product. Do provide sufficient details so that your team can write tasks and test cases to implement the item. Acceptance Criteria Provide the criteria to be met before the work item can be closed. Define what "Done" means by describing the criteria for the team to use to verify whether the backlog item or bug fix is fully implemented. Before work begins, describe the criteria for customer acceptance as clearly as possible. Have conversations between the team and customers to determine the acceptance criteria. These criteria help ensure a common understanding within the team to meet customers' expectations. Also, this information provides the basis for acceptance testing. Priority A subjective rating of the issue or task it relates to the business. You can specify the following values: 1: Product cannot ship without the successful resolution of the work item, and it should be addressed as soon as possible. 2: Product cannot ship without the successful resolution of the work item, but it does not need to be addressed immediately. 3: Resolution of the work item is optional based on resources, time, and risk. 4: Resolution of the work item is not required. Value Area A subjective rating of the issue or task it relates to the business. You can specify the following values: Architectural: Technical services to implement business features that deliver solution . Business: Services that fulfill customers or stakeholder needs that directly deliver customer value to support the business (Default). Effort, Story Points, Size Provide a relative estimate of the amount of work required to complete an issue. Most Agile methods recommend that you set estimates for backlog items based on relative size of work. Such methods include
- 104. Add tags to a work item NOTE Capture comments in the Discussion section powers of 2 (1, 2, 4, 8) and the Fibonacci sequence (1, 2, 3, 5, 8, etc.). Use any numeric unit of measurement your team prefers. The estimates you set are used to calculate team velocity and forecast sprints. Tags are useful for filtering backlogs, boards, and queries. As a Stakeholder, you can add existing tags to a work item, however, you can't add new tags. From the web portal, open a work item and choose Add tag and type a keyword of an existing tag. Or, select from the list of previously assigned tags. Tags that appear in the tag bar are already assigned to the work item. To unassign a tag, choose the x on the tag, . By default, all Contributors and Stakeholders of public projects are granted permissions to add new and existing tags. Stakeholders in private projects can add tags that are already defined, but not add new tags. To grant or restrict permissions to create new tags, you set the project-level Create tag definition permission. To learn more, see Change project-level permissions. Use the Discussion section to add and review comments made about the work being performed. The rich text editor tool bar displays below the text entry area. It appears when you click your cursor within each text box that supports text formatting.
- 105. NOTE Mention someone, a group, work item, or pull request Edit or delete a comment NOTE There is no Discussion work item field. To query work items with comments entered in the Discussion area, you filter on the History field. The full content of the text entered into the Discussion text box is added to the History field. Choose one of these icons — , , or — to open a menu of recent entries you've made to mention someone, link to a work item, or link to a pull request. Or to open the same menu, you can type @, #, or !. @mention drop-down menu" /> Type a name, or enter a number and the menu list will filter to match your entry. Choose the entry you want to add. You can bring a group into the discussion by typing @ and the group name, such as a team or security group. If you need to edit or delete any of your discussion comments, choose Edit or choose the actions icon and then choose Delete. Editing and deleting comments requires Azure DevOps Server 2019 Update 1 or later version. After updating the comment, choose Update. To delete the comment, you'll need to confirm that you want to delete it. A full audit trail of all edited and deleted comments is maintained in the History tab on the work item form. Use the @mention control to notify another team member about the discussion. Simply type @ and their name. To reference a work item, use the #ID control. Type # and a list of work items that you've recently
- 106. IMPORTANT Add a reaction to a comment Check the backlog and prioritized work referenced will appear from which you can select. To reference a work item, use the #ID control. Type # and a list of work items that you've recently referenced will appear from which you can select. You can't edit or delete comments once you've entered them. For on-premises Azure DevOps Server, you must configure an SMTP server in order for team members to receive notifications. Add one or more reactions to a comment by choosing a smiley icon at the upper-right corner of any comment. Or, choose from the icons at the bottom of a comment next to any existing reactions. To remove your reaction, choose the reaction on the bottom of your comment. The following image shows an example of the experience of adding a reaction, as well as the display of reactions on a comment. You can check the product backlog to see how the team has prioritized work. Backlog items appear in priority order. Work item types may include bugs depending on the settings made for the team. From the Kanban board, choose View as backlog. From the Kanban board, choose View as backlog. From the Kanban board, choose Backlog.
- 107. Find work assigned to you, or query for other work items You should see the list of backlog items listed in priority order. You can add a backlog item which will be placed at the bottom of the list. With Stakeholder access, you can't re-prioritize work. To view or edit a work item, select it and choose Enter. 1. Choose Boards>Work Items, and then select Assigned to me. You can focus on relevant items inside a project using one of the seven pivots as described next. Additionally, you can filter and sort each pivot view. For details, see View and add work items using the Work Items page. 2. To query for work items, see View, run, or email a work item query. 1. Open Work>Queries and select Assigned to me to see the list of work items assigned to you.
- 108. 2. Or, open any of the queries defined in the Shared Queries folder. 3. And, you can create new queries or edit existing queries and save them under My Queries folder.
- 109. Related articles For a comparison chart of Stakeholder versus Basic access, see this feature matrix. See also these quickstart guides: Add work items Create your backlog Kanban quickstart Access levels Change access levels
- 110. View permissions for yourself or others 6/9/2022 • 3 minutes to read • Edit Online NOTE Prerequisites View project-level permissions NOTE Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Learn how to view your permissions or the permissions that are set for others in Azure DevOps. If you don't have a permission to access a feature or function, you can request it from the right resource. Permissions are set at the collection, project, and object level as described in Get started with permissions, access, and security groups. So to view the permissions you have, you need to open the permissions at the object, project, or collection level. This article shows how to view permissions assigned to a user at the project-level or collection-level. However, the steps are similar when you work from the Security dialog of an object. You must have a project to connect to. If you don't have a project yet, create one. You must be a member of the Project Valid Users Group or Project Collection Valid Users Group to view permissions. To enable the preview feature, for the new user interface for the Project Permissions Settings Page, see Enable preview features. Preview page Current page 1. Choose Project Settings and then Permissions.
- 111. 2. Choose Users. To filter the list, enter a name into the Search groups or users box.
- 112. 3. Choose the name you want. The project-level permissions for that user displays. These permissions are based on the groups the user belongs to or the permissions set specifically for the user's account. 4. Choose Member of to see which security groups and teams that the user belongs to. Here we see that Jamal Hartnett belongs to several teams and the Project Collection Administrators group for several projects.
- 113. 1. Open Project Settings. Choose the gear settings icon, and choose Security. 2. Begin entering the name into the Filter users and groups box. The system automatically shows the names that begin with the characters you enter. 3. Choose the name you want. The project-level permissions you have set are based on the groups you belong to or the permissions set for your account.
- 114. View organization or collection-level permissions For a description of each permission, see Permissions and groups reference. 4. Choose Member of to see which security groups the user belongs to. Here we see that Jamal Hartnett belongs to several teams and the Project Collection Administrators group. For a description of each group, see Permissions and groups reference. Open admin settings for the organization or a project collection. 1. Choose the Azure DevOps logo to open Projects. Then choose Organization settings.
- 115. 2. Choose Permissions, the Project Collection Administrators group, and then Members. 3. Follow steps 2 through 4 in the procedure outlined previously for view project-level permissions. 1. Choose the Azure DevOps logo to open Projects. Then choose Admin settings.
- 116. 2. Choose Security, the Project Collection Administrators group, and then Members. 3. Follow steps 2 through 4 in the procedure outlined previously for view project-level permissions. 1. Choose the settings icon and select Organization settings or Collection settings.
- 117. View object-level permissions 2. Choose Security, Project Collection Administrators group, and then Members. 3. Follow steps 2 through 4 in the procedure outlined previously for view project-level permissions. You can define the security or permissions for a number of objects. You access them from the context menu of the object. From the web portal, open the Security dialog for the object whose permissions you want to set. For specific instructions, see the following articles:
- 118. Next steps Related articles Area Task Wiki & Dashboard permissions README & Wiki Dashboards Azure Repos, Azure Pipelines/DevOps (code, build, test, release) permissions Git branch Git repository TFVC Builds Release pipeline security Approvals and approvers Azure Boards/Work tracking permissions Area and iteration paths Work item query and folder Plan permissions Look up a member of the Project Administrators group Troubleshoot permissions Permissions and role lookup guide
- 119. Sign up for Azure DevOps 6/9/2022 • 2 minutes to read • Edit Online Prerequisites Sign up NOTE Enable GitHub invitations Azure DevOps Services Azure DevOps gives you an integrated set of services and tools to manage your software projects, from planning and development through testing and deployment. You can sign up for Azure DevOps for free with either a Microsoft or GitHub account. Use either of the following accounts to sign up for Azure DevOps: a Microsoft account. If you don't have one, create a Microsoft account now. a GitHub account. If you don't have one, create a GitHub account now. 1. Select the sign-up link for Azure DevOps. 2. Enter your account credentials and go through the sign-up process. With a GitHub account, you're asked to Authorize Microsoft-corp. If your GitHub email address is associated with an Azure AD-backed organization in Azure DevOps, you can't sign in with your GitHub account, rather you must sign in with your Azure AD account. An organization gets created based on the account you used to sign in. If you signed in with a newly created Microsoft account, then your project is automatically created and named after your account name. If you signed in with an existing Microsoft account, you can create a project next. Sign in to your organization at any time https://dev.azure.com/{yourorganization} . When you create a new Azure DevOps organization with your GitHub account, we turn on the Invite GitHub users policy by default. For existing organizations, your administrator can turn on this capability via Organization settings > Policies. Once the setting gets changed, sign out of Azure DevOps, and then from a fresh browser session, sign back in to the organization dev.azure.com/{organizationName} or organizationName.visualstudio.com with your GitHub credentials. You're recognized as a GitHub user and the GitHub invitation experience is available to you.
- 120. Next steps Related articles For more information about GitHub authentication, see FAQs. Add users to your organization Plan your organizational structure in Azure DevOps Rename your organization Change the location of your organization Add users to your organization Create a project Add users or groups to a team or project
- 121. Create an organization 6/9/2022 • 2 minutes to read • Edit Online NOTE Prerequisites IMPORTANT Create an organization Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Use an organization to connect groups of related projects, and help to scale up your enterprise. You can use a personal Microsoft account, GitHub account, or a work or school account. Use your work or school account to automatically connect your organization to your Azure Active Directory (Azure AD). All organizations must be manually created via the web portal. We don't support automated creation of organizations. We do support automated organization configuration, project creation, and resource provisioning via REST API. Understand how to plan your organizational structure. Determine whether you want to use only Microsoft accounts or authenticate users with Azure AD. For more information, see Choosing your organization administrator account type. Currently, you can only use letters from the English alphabet in your organization name. Start organization names with a letter or number, followed by letters, numbers or hyphens, and they must end with a letter or number. 1. Sign in to Azure DevOps. 2. Select New organization.
- 122. 3. Confirm information, and then select Continue.
- 123. Create a project collection Next steps Related articles Congratulations, you're an organization owner! Sign in to your organization at any time, https://dev.azure.com/{yourorganization} . A project collection is a container of projects. By grouping projects together, you can manage projects more efficiently and assign the same resources to those projects. For more information about how to create a project collection, see Create a project collection. With your organization, the following aspects are included in the free tier: Five Azure DevOps users (Basic) Free tier of Microsoft-hosted CI/CD (one concurrent job, up to 30 hours per month) 2 GiB of Azure Artifacts storage One self-hosted CI/CD concurrent job Create a project Get started with Azure Repos and Visual Studio Rename your organization Change organization time-zone Change organization owner Delete your organization Resolve orphaned organization
- 124. Get started managing your project 6/9/2022 • 8 minutes to read • Edit Online NOTE Add users to your project Share your project vision, set up a project wiki Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 With most Azure DevOps Services, you can start using the service and configure resources as you go. No up- front work is required. Most settings define defaults. If you've created a project or been added to the Project Administrators group, you'll want to be familiar with the administrative tasks your charged with. there are a few tasks you might want to do to ensure a smooth operational experience. This article provides an overview of tasks a member of the Project Administrators group should review and attend to. For information on tasks to be performed by members of the Project Collection Administrators group, see Manage your organization or project collection. You add users to a team or project so they can contribute to the team and project. Users can be added to multiple teams and projects. Users that have been added to an organization, can easily be added to a project by adding them to a team or inviting them to contribute to a project. Team administrators can add users to their team which automatically adds them to the project. By adding users to a team, you make team-specific tools aware of them, such as the team security group, Team Members widget, and sprint capacity planning tools. To learn more about teams, see About teams and Agile tools. Members of the Project Administrators group can add users to a project. Adding users to a team or project automatically adds them to the project's Contributors group. Members of this group have permissions to most features needed to contribute to work items, code, builds, and releases. For an overview of default permissions, see Default permissions quick reference. Once users have been added to a project or organization, you can browse for their display name or user name (email alias) from any people-picker tool. Users can connect to a project and access features available through a supported client or the web portal. To learn more, see the following articles: Add users or groups to a team or project Manage your organization or project collection, Add users to your organization Connect to a project Each project has a summary page that's useful for sharing information through README files. Or, redirect users to a project Wiki. For users who are new to your project, we recommend that you set up your project summary page. Or, you can provision a Wiki. Use these features to share established processes and procedures for your
- 125. Remove unused services Manage security and permissions NOTE project. Each project has a summary page that's useful for sharing information through README files. For users who are new to your project, we recommend that you set up your project summary page. Or, you can provision a Wiki. Use these features to share established processes and procedures for your project. To simplify the web portal user interface, you can disable select services. For example, if you use a project only to log bugs, then disable all services except for Boards. To learn more, see Turn a service on or off. This example shows that Test Plans is disabled: Access to select tasks is controlled by permissions and security groups. To quickly understand the defaults configured for your project, see Default permissions and access. The following table lists the permissions assigned at the project-level. All of these permissions are granted to members of the Project Administrators group, except for the Delete shared Analytics views and Edit shared Analytics views permissions which are not set. For a description of each permission, see Permissions and groups reference, Groups. The following table lists the permissions assigned at the project-level. All of these permissions are granted to members of the Project Collection Administrators group. For a description of each permission, see Permissions and groups reference, Groups. Permissions associated with Analytics requires that the Inherited process model is selected for an on-premises project collection. General Delete team project
- 126. Edit project-level information Manage project properties Rename team project Suppress notifications for work item updates Update project visibility View project-level information Delete team project Edit project-level information Manage project properties Rename team project Suppress notifications for work item updates View project-level information Delete team project Edit project-level information Manage project properties Rename team project View project-level information Boards Bypass rules on work item updates Change process of team project Create tag definition Delete and restore work items Move work items out of this project Permanently delete work items Bypass rules on work item updates Change process of team project Create tag definition Delete and restore work items Move work items out of this project Permanently delete work items Create tag definition Delete and restore work items Permanently delete work items Analytics Delete shared Analytics views Edit shared Analytics views View analytics Test Plans Create test runs Delete test runs Manage test configurations Manage test environments
- 127. Add members to the Project Administrators group Grant or restrict permissions Review and update notifications View test runs To learn more about security and setting permissions at the project-level, review the following articles: Get started with permissions, access, and security groups Change permissions at the project-level The person who creates a project is automatically added as a member to the Project Administrators group. Members of this group have permissions to manage project configuration, repositories, pipeline resources, teams, and all project-level permissions. It's always a good idea to have more than one person who has administrative privileges. To add a user to this group, see Change permissions at the project level, Add members to the Project Administrators group. Permissions are managed at the following three levels and through role-based assignments. object project organization or collection As a member of the Project Administrators group, you can grant or restrict permissions for all objects and at the project-level. To delegate specific tasks to others, we recommend that you add them to a built-in or custom security group or add them to a specific role. To learn more, see the following articles. Role-based permissions Add or remove users or groups, manage security groups Grant or restrict access to select features and functions Set object-level permissions A number of notifications are predefined for each project you add. Notifications are based on subscription rules. Subscriptions arise from the following areas: Out-of-the-box or default subscriptions. Team, project, and organization or collection subscriptions defined by a team administrator or member of the Project Administrators or Project Collection Administrators groups. If users believe they're getting too many notifications, you can direct them to opt out of a subscription.
- 128. Determine traceability requirements Set DevOps policies Configure and customize Azure Boards Define area and iteration paths to track work If you're using most of Azure DevOps Services—Boards, Repos, Pipelines, and Test Plans— you'll want to alert your teams to those features that support end-to-end traceability. To get started, we recommend that you review the following articles: Cross-service integration and collaboration overview End-to-end traceability Set policies to support collaboration across your teams and automatically remove obsolete files. To set policies that govern Azure Repos, Azure Pipelines, and Azure Test Plans, review the following articles: Manage branch policies Add Team Foundation Version Control (TFVC) check-in policies Set build and release pipeline retention policies Set test retention policies You can configure and customize Azure Boards to support a number of business requirements for planning and tracking work. At a minimum, you'll want to configure the following elements: Area paths to group work items by team, product, or feature area Iteration paths to group work into sprints, milestones, or other event-specific or time-related periods. If you're new to Azure Boards and want an indepth overview of what you can configure and customize, see Configure and customize Azure Boards. If you support several products, you can assign work items by feature area by defining area paths. To assign work items to specific time intervals, also known as sprints, you configure iteration paths. To use the Scrum tools —sprint backlogs, taskboards, and team capacity—you need to configure several sprints. For an overview, see About areas and iteration paths.
- 129. ITERATIONS AREAS Customize work-tracking processes NOTE Integrate with other services You and your team can start using all work-tracking tools immediately after you create a project. But often, one or more users want to customize the experience to meet one or more business needs. You can customize the process easily through the user interface. As such, you'll want to establish a methodology for who will manage the updates and evaluate requests. By default, organization owners and users added to the Project Collection Administrators security group are granted permission to create, edit, and manage processes used to customize the work-tracking experience. If you want to lock down who is able to perform these tasks, you can set permissions at the organization-level to Deny. To learn more, see these articles: About process customization and inherited processes Customize a project Add and manage processes On-premises XML process customization Add or modify a field to track work Add or modify a work item type Azure DevOps supports integration with Azure, GitHub, and many other services. As a member of the Project Administrators group, you can configure integration with many of these services. To learn more, see the following articles. Azure DevOps and GitHub integration overview Azure Boards and GitHub integration Microsoft teams integration: Azure Boards with Microsoft Teams Azure Repos with Microsoft Teams Azure Pipelines with Microsoft Teams Slack integration: Azure Boards with Slack Azure Repos with Slack
- 130. Add teams to scale your project Next steps Related articles Azure Pipelines with Slack Integrate with service hooks As your organization grows, we recommend that you add teams to scale your project. Each team gets access to their own set of customizable Agile tools. To learn more, see the following articles: About projects and scaling your organization Add a team, move from one default team to several teams Add a team administrator Share your project vision Project and team quick reference Get started managing your organization or project collection About user, team, project, and organization-level settings Project and team quick reference Get started managing your organization or project collection About user, team, project, and organization-level settings TFS administration
- 131. Get started managing your organization or project collection 6/9/2022 • 12 minutes to read • Edit Online NOTE Add users to your organization Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 After you create an organization or project collection, you'll want to add contributors and configure policies, settings, and other options available to you. This article provides an overview of tasks you'll want to review to ensure you're setting up your organization or collection to get maximal use of your services. Each organization is associated with one and only one collection. If you need to create another organization, see Plan your organizational structure and Create an organization. When you install Azure DevOps Server, you automatically create a default collection. If you need to create another project collection, see Manage project collections. This article provides an overview of tasks that require membership in the Project Collection Administrators group. For information on tasks to be performed by members of a Project Administrators group, see Manage your project. For large enterprises, the recommended method to manage Azure DevOps users, is to connect Azure DevOps to Azure Active Directory (Azure AD) and manage user access through security groups defined in Azure AD. That way, when you add and remove users or groups from Azure AD, you automatically add and remove these same users and groups from Azure DevOps. You limit the maintenance of managing permissions and user access. For small and large enterprises, you can add users and security groups directly through the web portal Organization settings>Users interface. All users added to an organization can be added to one or more projects defined for the organization. For large enterprises, the recommended method to manage Azure DevOps users, is to connect Azure DevOps to Active Directory (AD) and manage user access through security groups defined in AD. That way, when you add and remove users or groups from AD, you automatically add and remove these same users and groups from Azure DevOps. Typically, you should install Active Directory before installing Azure DevOps. You limit the maintenance of managing permissions and user access. For small and large enterprises, you add users to a server instance through the web portal Access levels interface. All users added to the server instance can be added to one or more projects defined within the project collection(s) defined in the server instance. When you add users, you specify their access level which determines the features they can use through the web portal. To learn more, review these resources: Get started with permissions, access, and security groups About access levels Add organization users and manage access Connect your organization to Azure Active Directory
- 132. NOTE NOTE Set up billing Manage security and permissions If the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization, users added to the Project-Scoped Users group won't be able to access projects that they haven't been added to. To learn more, see Limit user visibility for projects and more later in this article. Get started with permissions, access, and security groups About access levels Add users or groups to an access level Install Active Directory Domain Services (Level 100) Even if you add a user or group to an access level, you must also add them to a project for them to connect to a project and access features available through a supported client or the web portal. Azure DevOps Services charges for the following services as described in Pricing for Azure DevOps. Individual services: User licenses for Basic or Basic + Test Plans. Microsoft-hosted CI/CD parallel jobs Self-hosted CI/CD parallel jobs Storage of Azure Artifacts feeds All organizations are granted five free Basic licenses and unlimited users with Stakeholder access. For information on each access level, see About access levels. If your organization requires more than five contributors, then you'll need to set up billing. Users that have a Visual Studio subscription can be added without incurring any further billing charges. Billing is based on the access level, Basic or Basic + Test Plans, that you assign to the user. To learn more, see Set up billing. Access to select tasks is controlled by permissions and security groups. The following table lists the permissions assigned at the organization or collection-level. All of these permissions, except for the Make requests on behalf of others permission, are granted to members of the Project Collection Administrators group. For a description of each permission, see Permissions and groups reference, Groups. General Alter trace settings Create new projects Delete team project Edit instance-level information View instance-level information Service Account Make requests on behalf of others
- 133. Add members to the Project Collection Administrators group Trigger events View system synchronization information Boards Administer process permissions Create process Delete field from organization or account Delete process Edit process Delete field from organization or account Repos (TFVC) Administer shelved changes Administer workspaces Create a workspace Pipelines Administer build resource permissions Manage build resources Manage pipeline policies Use build resources View build resources Administer build resource permissions Manage build resources Use build resources View build resources Test Plans Manage test controllers Auditing Delete audit streams Manage audit streams View audit log Policies Manage enterprise policies To learn more about security and setting permissions at the collection-level, review the following articles: Get started with permissions, access, and security groups Change permissions at the organization or collection-level. The person who creates an organization is automatically added as a member to the Project Collection Administrators group. Members of this group have permissions to manage the settings, policies, and processes for the organization, create and manage all projects defined in the organization, and install and manage extensions.
- 134. Limit user visibility for projects and more NOTE Limit identity search and selection The person who creates a project collection is automatically added as a member to the Project Collection Administrators group. Members of this group have permissions to manage the settings, policies, and processes for the organization, create and manage all projects defined in the organization, and install and manage extensions. It's always a good idea to have more than one person who has administrative privileges. To add a user to this group, see Change permissions at the organization level,Add members to the Project Collection Administrators group. By default, users added to an organization can view all organization and project information and settings. To restrict select users, such as Stakeholders, Azure Active Directory guest users, or members of a particular security group, you can enable the Limit user visibility and collaboration to specific projects preview feature for the organization. Once that is enabled, any user or group added to the Project-Scoped Users group, are restricted in the following ways: Restricted users to only access those projects to which they've been explicitly added to. Restricts views that display list of users, list of projects, billing details, usage data, and more that is accessed through Organization Settings. Limits the set of people or groups that appear through people-picker search selections and the ability to @mention people. To enable this feature, see Manage or enable features. All security groups are organization-level entities, even those groups that only have permissions to a specific project. From the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover the names of all groups in an organization using the azure devops CLI tool or our REST APIs. To learn more, see Add and manage security groups. For organizations that manage users and groups using Azure Active Directory (Azure AD), people pickers provide support for searching all users and groups added to Azure AD, not just those users and groups added to your project. people pickers support the following Azure DevOps functions: Selection of a user identity from a work tracking identity field such as Assigned To Selection of a user or group using @mention in a work item discussion or rich-text field, a pull request discussion, commit comments, or changeset or shelveset comments Selection of a user or group using @mention from a wiki page As shown in the following image, you simply start typing into a people picker box until you find a match to a user name or security group.
- 135. WARNING Set security policies When the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization, project-scoped users are unable to search for users who were added to the organization through Azure Active Directory group membership, rather than through an explicit user invitation. This is an unexpected behavior and a resolution is being worked on. To self-resolve this issue, disable the Limit user visibility and collaboration to specific projects preview feature for the organization. Users and groups who are added to the Project-Scoped Users group can only see and select users and groups in the project they are connected to from a people picker. To scope people pickers for all project members, see Limit user visibility for projects and more earlier in this article. To limit the identity selection to just those users and groups added to a project, perform the following procedure for your organization and projects. 1. Enable the Limit user visibility and collaboration to specific projects preview feature for the organization. To learn how, see Manage or enable features. 2. Add the users to your project(s) as described in Add users to a project or team. Users added to a team are automatically added to the project and team group. 3. Open Organizations Settings>Security>Permissions and choose Project-Scoped Users. Choose the Members tab. Add all users and groups that you want to scope to the project(s) you've added them to. To learn more, see Set permissions at the project- or collection-level. The Project-Scoped Users group only appears under the Permissions>Groups once Limit user visibility and collaboration to specific projects preview feature is enabled. Configure the security policies for your organization through the Organization settings>Policies page. These policies enable you to grant or restrict the following features: Third-party application access via OAuth SSH authentication Creation of public projects Invitation of GitHub user accounts
- 136. Enable preview features for your organization Install and manage extensions Install Code Search To learn more, see Change application connection & security policies for your organization. As new features are introduced to Azure DevOps Services, you can choose to enable them or not for an organization. Some features are introduced and automatically enabled. You can try them out, provide feedback, and work with those features that meet your requirements. When you enable a feature at the organization level, you essentially turn it on for all users of your account. Each user can then disable the feature if they so choose. If you disable a feature at the organization level, user settings are not changed. Users can enable or disable the feature on their own. To enable or disable a preview feature, see Manage or enable features. The following features are only enabled or disabled at the organization-level: Limit identity search and selection Full Access to Azure Pipelines for Stakeholders An extension is an installable unit that adds new capabilities to your projects. Azure DevOps extensions support the following functions: Planning and tracking of work items, sprints, scrums, and so on Build and release flows Code testing and tracking Collaboration among team members For example, to support code search, install the Code Search extension. You want to tell your users about extensions and that they can request an extension. To install and manage extensions, you must be an organization Owner, a member of the Project Collection Administrators group. Or, you can get added to the Manager role for extensions. Code Search is a free Marketplace extension that you must install to enable searching across all your source
- 137. Enable or disable Analytics Adjust time zone and other organization settings Configure DevOps settings Customize work-tracking processes Alert users with information banners repositories. To learn how, see Install and configure Search. The Analytics service is the reporting platform for Azure DevOps, replacing the previous platform based on SQL Server Reporting Services. Built for reporting, Analytics is optimized for fast read-access and server-based aggregations. Use it to answer quantitative questions about the past or present state of your projects. To learn more, see What is the Analytics service? and Install or enable the Analytics service. When you create an organization, you specify the name of your organization and select the region where your organization is hosted. The default Time zone is set to UTC. You can update the Time zone and specify a Privacy URL from the Organization settings>Overview page. To learn more about these settings, see the following articles: Time zone settings and usage Add a privacy policy URL for your organization There are a few settings that you define at the organization-level to support devops work. These include the following items: Add agent pools Define pipeline retention settings Define repository settings: Default branch name for new repositories Gravatar images. All work-tracking tools are available immediately after you create a project. Often, one or more users may want to customize the experience to meet one or more business needs. Processes are easily customized through the user interface. However, you may want to establish a methodology for who manages the updates and evaluates requests. To learn more, see the following articles: About process customization and inherited processes Customize a project Add and manage processes All work-tracking tools are available immediately after you create a project. Often, one or more users may want to customize the experience to meet one or more business needs. But, you may want to establish a methodology for who manages the updates and evaluates requests. To learn more, see On-premises XML process model. You can quickly communicate with your Azure DevOps users through information banners. Use banners to alert your Azure DevOps users to upcoming changes or events without sending mass emails. To learn how, see Add and manage information banners.
- 138. Review and update notifications Configure an SMTP server Scale your organization or collection Related articles A number of notifications are predefined at the organization or collection level. You can disable or modify these subscriptions, or add new subscriptions as described in Manage notifications for a team, project, or organization. In order for team members to receive notifications, you must configure an SMTP server. To learn about scaling your organization, review the following articles. About projects and scaling your organization Plan your organizational structure Project and team quick reference FAQs about signing up and getting started Organization management About user, team, project, and organization-level settings Project and team quick reference Security & identity
- 139. About user, team, project, and organization-level settings Azure DevOps Server administration
- 140. Add users or groups to a team or project 6/9/2022 • 21 minutes to read • Edit Online Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 You add users to a team or project so they can contribute to the team and project. For enterprise organizations with large user bases, we recommend you use Azure Active Directory to add and manage new users through security groups. However, to enable flexibility for all size organizations, the following operations are supported: Team and project administrators can add new users to their team or project, unless the policy Allow team and project administrators to invite new users is disabled. New users are ones that haven't been added to the organization. When adding new users through the team and project user interfaces, the system automatically assigns an access level to the user. Adding users to a team or project automatically adds them to the Contributors group for the project. Members of the Contributors group have permissions to most features needed to contribute. By adding users to a team, you make team-specific tools aware of them, such as the team security group, Team Members widget, and sprint capacity planning tools. Once users have been added to a project or organization, you can browse for their display name or user name (email alias) from any people-picker tool. You add users to a team or project so they can contribute to the team and project. For enterprise organizations with large user bases, we recommend you use Active Directory or Windows Group to manage users through security groups. However, to enable flexibility for all size organizations, the following operations are supported: Team and project administrators can add existing users to their team or project. Existing users are ones known to the project collection through Active Directory or Windows group. Adding users to a team or project automatically adds them to the Contributors group for the project. Members of the Contributors group have permissions to most features needed to contribute. By adding users to a team, you make team-specific tools aware of them, such as the team security group, Team Members widget, and sprint capacity planning tools. Once users have been added to a project or organization, you can browse for their display name or user name (email alias) from any people-picker tool. You add projects to an organization or project collection and you add teams to projects. To learn more, see: Create a project Add team, go from one default team to others
- 141. IMPORTANT Supported options for adding users To view the content available for your platform, make sure that you select the correct version of this article from the version selector which is located above the table of contents. Feature support differs depending on whether you are working from Azure DevOps Services or an on-premises version of Azure DevOps Server. To learn which on-premises version you are using, see What platform/version am I using? Depending on the interface you use, you can exercise different options for adding new or existing users to teams or projects. Team and project administrators can add existing users to their team or project. Existing users are ones that are known to a project collection through the Active Directory or Windows Group created for the server that hosts the on-premises Azure DevOps Server. Administrator level Interface Supported tasks Team administrators Team Members dashboard widget Add new or existing users to a team. Send new users an invite. Team administrators Project Settings>Teams>Team>Members Add existing users or groups to a team, or remove a member. Project Administrators Project Summary page, Invite Add new or existing users. Send new users an invite. Optionally add users to one or more teams. Project Administrators Project Settings>Permissions>Groups>Group Members Add existing users or groups to a security group. By adding to a team group, you effectively add them to the team. Optionally remove a user from a group. Project Collection Administrators Organization Settings>Users Add new users to an organization and send an invite. Must specify the access level. Optionally add them to
- 142. Prerequisites Add a user from the Team Members widget select projects. Can use Group rules to further manage groups being added. Project Collection Administrators az devops user CLI Add new users to an organization and send an invite. Must specify the access level. Azure Active Directory Administrators Azure Active Directory Users you add to Azure Active Directory connected to Azure DevOps Services are added to the Project Collection Valid Users group. To learn more, see Connect your organization to Azure Active Directory. Active Directory Administrators Active Directory or Windows Group Users you add to Active Directory or Windows Group connected to Azure DevOps are added as members of the Project Collection Valid Users group. They have access to all projects within a project collection. To learn more, see Set up groups for use in Azure DevOps on-premises. You must have an organization and project. If you don't have a project yet, create one. To add users to or remove users from a team, you must be added as a team administrator, or be a member of one of the administrative groups. To add users to or remove users from a project, you must be a member of the Project Administrators group. When the organization is connected to Azure Active Directory, the Allow team and project administrators to invite new users policy must be enabled for team administrators or members of the Project Administrators group to add new users. To add users or manage users for an organization, you must be a member of the Project Collection Administrators group. Organization owners are automatically members of this group. If you don't have a project yet, create one To add users to or remove users from a team, you must be added as a team administrator, or be a member of one of the administrative groups. To add users to or remove users from a project,you must be a member of the Project Administrators group. To add users or manage users for a server, you must be a member of the Azure DevOps Administrators group. If you're new to Azure DevOps, you may want to familiarize yourself with the information provided in these articles: Get started with permissions, access levels, and security groups About projects and scaling your organization Default permissions and access quick reference About teams and Azure Boards tools As a team administrator, you can add new or existing members from the Team Members dashboard widget. To add this widget to a dashboard, see Add widgets to a dashboard.
- 143. NOTE 1. To invite someone to your team, choose the plus button on the Team Members widget. 2. For new users, enter their email address. For existing users, type their name until it resolves as a known name to the system. You can add several email addresses or account names by separating them with a semicolon (;). Choose the entry listed under Add users to complete the entry. Any valid email address is acceptable. When the user accepts the invitation and signs into Azure DevOps, they register their email address as a Microsoft account and choose a password. Choose the name that appears to complete the entry. 3. Complete the addition.
- 144. NOTE When the user is unknown, you'll get a notification that an access level must be assigned. To complete the invitation, choose Add. Choose Add to complete adding the user. Known users don't receive an invitation. When adding a new user, the system assigns Stakeholder as the access level when all free five Basic access levels have been assigned. Active contributors to a project need to have Basic access as a minimum. A Project Collection Administrator can change the access level and resend invitations from the Organization Settings>Users page. Users that have limited access, such as Stakeholders, won't be able to access select features even if granted permissions to those features. To learn more, see Permissions and access. 4. (Optional) A message will briefly display on the screen to indicate success or failure. Choose Details to open the notification and review details.
- 145. Add users or groups to a team A success message indicates the status of adding the user to the system. A failure message indicates why the addition of the user failed. "::: 5. New users receive an email inviting them to sign in to the project. Existing users don't receive any formal notification. Add existing users or security groups to a team from the Project settings> Teams page. From this interface
- 146. NOTE you can view, add, or remove users and security groups to/from a team. To add a custom security group, see Add or remove users or groups, manage security groups. To enable the new user interface for managing teams, enable the New Teams Page from the Preview features tool. To learn how, see Manage or enable features. Preview UI Current UI You can toggle between direct or expanded membership views. The Direct Members view displays users and groups that have been added to the team. The Expanded Members view replaces any Azure DevOps groups with the members that belong to those groups. Azure Active Directory or Active Directory groups aren't expanded. 1. Open a backlog or board for a team and choose the team profile icon. Then choose Team Settings. Here we open the Board for the Web team and from there the team profile. 2. If you need to switch the team context, use the team selector within the breadcrumbs. 3. Choose Add.
- 147. Remove users or groups from a team TIP 4. Enter the sign-in addresses or display name for each account you want to add. You can also add a project security group—such as another team group, custom group, or Azure Active Directory group when used by the organization. Add them one at a time or all at the same time. You can enter several identities into the text box, separated by commas. You must enter user and group names one at a time. However, after entering a name, the account is added to the list, and you can enter another name in the Identities text box before choosing to save your changes. You may need to choose the refresh icon to see your updates. 5. To add an account as a team administrator, choose the Settings page and then choose Add under the Administrators section. For details, see Add a team administrator Choose the Current page tab for information on adding a user to a team. The New Teams Page preview feature is only available for Azure DevOps Services at this time. From the team's Members page, you can remove members.
- 148. Invite users from the Summary page NOTE Preview UI Current UI TIP 1. To remove members, open the team's Members page, choose Direct Members, check the checkbox of the user you want to remove, choose More options, and then choose Remove. To remove a team administrator as a team member, you must first remove them as an administrator. 2. Confirm the removal by choosing Delete in the confirmation message. Choose the Current page tab for information on adding a user to a team. The New Teams Page preview feature is only available for Azure DevOps Services at this time. As a member of the Project Administrators group, you can add members to a project from the Summary page and optionally add them to one or more teams. To learn more about the Summary page, see Share your project vision, view project activity. For on-premises Azure DevOps, all email actions require an SMTP server to be configured. 1. Open the Project>Summary page, and choose Invite.
- 149. 1. Open the Project>Summary page, and choose the Add button. 1. For new users, enter their email address. For existing users, type their name until it resolves as a known name to the system. You can add several email addresses or account names by separating them with a semicolon (;). Choose the entry listed under Add users to complete the entry. If you're adding a user known by the organization or collection, type the name or email address and then choose the name that appears to complete the entry.
- 150. NOTE Any valid email address is acceptable. When the user accepts the invitation and signs into Azure DevOps, they register their email address as a Microsoft account and choose a password. 2. Optionally, select the teams you want to add the user to and then choose Add to complete the invitation. When the user is unknown, you'll get a notification that an access level must be assigned. To complete the invitation, choose Add. Choose Add to complete the invitation.
- 151. NOTE When adding a new user, the system assigns Stakeholder as the access level when all free five Basic access levels have been assigned. Active contributors to a project need to have Basic access as a minimum. A Project Collection Administrator can change the access level from the Organization Settings>Users page. Users that have limited access, such as Stakeholders, won't be able to access select features even if granted permissions to those features. To learn more, see Permissions and access. 3. (Optional) A message will briefly display on the screen to indicate success or failure. Choose Details to open the notification and review details. A success message indicates the status of adding the user to the system. A failure message indicates why the addition of the user failed.
- 152. Add users or groups to a project NOTE "::: 4. New users receive an email inviting them to sign in to the project. Existing users don't receive any formal notification. As a member of the Project Administrators group, you can add users or groups to a project from the Project settings> Permissions page by adding them to a security group. To add a custom security group, see Add or remove users or groups, manage security groups. To enable the new user interface for the Project Permissions Settings Page, see Enable preview features.
- 153. Preview UI Current UI 1. Open the web portal and choose the project where you want to add users or groups. To choose another project, see Switch project, repository, team. 2. Choose Project settings, and then Permissions. 3. Under Groups, choose one of the following options: Readers: To add users who require read-only access to the project, choose. Contributors: To add users who contribute fully to this project or who have been granted Stakeholder access. Project Administrators: To add users who need to administrate the project. To learn more, see Change project-level permissions. Or, you can choose any team group to add users to a specific team. Here we choose the Contributors group. 4. Next, choose the Members tab. The default team group, and any other teams you add to the project, get included as members of the
- 154. TIP NOTE Contributors group. Add a new user as a member of a team instead, and the user automatically inherits Contributor permissions. Managing users is much easier using groups, not individual users. 5. Choose Add to add a user or a user group. 6. Enter the name of the user account into the text box. You can enter several identities into the text box, separated by commas. The system automatically searches for matches. Choose the match(es) that meets your requirements. The first time you add a user or group to Azure DevOps, you can't browse to it or check the friendly name. After the identity has been added, you can just enter the friendly name. Choose Save when done.
- 155. Manage users or resend invitations List team members or team details NOTE List team members 7. You may customize user permissions for other functionality in the project. For example, in areas and iterations or shared queries. Choose the Current page tab for information on adding a user to a project. The Project Permissions Settings Page preview feature is only available for Azure DevOps Services at this time. Project Collection Administrators can update user assignments and resend invitations. The various options they have are: Change the access level Manage user - add them to select projects Resend invite Remove direct assignments Remove from organization To learn more, see Add account users for Azure DevOps. From the Azure DevOps CLI command, you can see details about a team or list the individual members of that team. To first see a list of all teams in your organization, use the az devops team list command. List team members | Show team details You can use the az devops user command to add users to an organization. There is no comparable command for adding users to a team or project. You can list the individual members of a team in your organization with the az devops team list-member
- 156. az devops team list-member --team [--org] [--project] [--skip] [--top] Parameters Example az devops team list-member --team "Fabrikam Team" --top 5 --output table ID Name Email ------------------------------------ ----------------- -------------------------- 3b5f0c34-4aec-4bf4-8708-1d36f0dbc468 Christie Church fabrikamfiber1@hotmail.com 19d9411e-9a34-45bb-b985-d24d9d87c0c9 Johnnie McLeod fabrikamfiber2@hotmail.com 8c8c7d32-6b1b-47f4-b2e9-30b477b5ab3d Chuck Reinhart fabrikamfiber3@hotmail.com d291b0c4-a05c-4ea6-8df1-4b41d5f39eff Jamal Hartnett fabrikamfiber4@hotmail.com bd30c189-db0f-4dd6-9418-5d8b41dc1754 Raisa Pokrovskaya fabrikamfiber5@hotmail.com Show team details az devops team show --team [--org] [--project] Parameters Example command. To get started, see Get started with Azure DevOps CLI. team: Required. Name or ID of the team to show. org: Azure DevOps organization URL. You can configure the default organization using az devops configure -d organization=ORG_URL . Required if not configured as default or picked up using git config . Example: --org https://dev.azure.com/MyOrganizationName/ . project: Name or ID of the project. You can configure the default project using az devops configure -d project=NAME_OR_ID . Required if not configured as default or picked up using git config . skip: Optional. Number of members to skip. top: Optional. Maximum number of members to return. The following command lists the first five members of the team named Fabrikam Team and returns the details in table format. You can view details about a team in your organization with the az devops team show command. To get started, see Get started with Azure DevOps CLI. team: Required. Name or ID of the team to show. org: Azure DevOps organization URL. You can configure the default organization using az devops configure -d organization=ORG_URL . Required if not configured as default or picked up using git config . Example: --org https://dev.azure.com/MyOrganizationName/ . project: Name or ID of the project. You can configure the default project using az devops configure -d project=NAME_OR_ID . Required if not configured as default or picked up using git config . The following command shows information about the team in your organization named Fabrikam Team and returns the details in table format.
- 157. az devops team show --team "Fabrikam Team" --output table ID Name Description ------------------------------------ ------------ ------------------------------------------------- a48cb46f-7366-4f4b-baf5-b3632398ed1e Fabrikam Team The default project team. Was Fabrikam Fiber Team Add users or groups to an access level Add users or groups to SQL Server Reports Next steps Related articles For on-premises deployments, you may need to set the access level for a user or group, particularly if those groups don't belong to the default access level. To learn more, see Change access levels. If your on-premises deployment is integrated with SQL Server Reports, you need to manage membership for those products separately from their websites. See Grant permissions to view or create SQL Server reports in Azure DevOps. Manage your project Add users and manage access Resources granted to project members Manage your organization, Limit identity search and selection Manage your organization, Limit user visibility for projects and more Manage permissions with command line tool Grant or restrict access using permissions. Resources granted to project members Grant or restrict access using permissions.
- 158. Manage and configure team tools 6/9/2022 • 6 minutes to read • Edit Online Prerequisites NOTE Open your team profile Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 As a team administrator, you can customize your backlogs and board to best meet how your team works. If you need to have a team created, request a member of your Project Administrators group do so. It only takes a minute to add a new team. Team settings are managed by the team administrator role. Users assigned as team administrator can configure and manage all team tools. Team administrators should do the following tasks: Add team members Add another team administrator Configure areas and iteration paths Configure backlogs, boards, and general settings Also, consider the following optional tasks: Configure and manage team dashboards Configure team notifications To perform any team configuration task, you need to be added as a team administrator for the team to be modified, or be a member of the Project Administrators group. See Change project-level permissions. To add a team, you must be a member of the Project Administrators group. For more information, see Add teams. For guidance on configuring and customizing your project and teams to support your business needs, review Configuration and customization of Azure Boards. Open your team profile to quickly access items defined for your team. 1. Sign in to your organization ( https://dev.azure.com/{yourorganization} ), and then open your project. 2. Select Project settings > Teams > your team name.
- 159. Add users to a team Several tools, such as capacity planning, team alerts, and dashboard widgets, are team-scoped. These tools automatically reference the users that are as members of a team to support planning activities or sending alerts. To add users to a team, see Add users to a project or specific team. All members of a team can favorite team artifacts and define work item templates. For more information, see: Set personal or team favorites
- 160. Add an administrator Configure team areas and iterations Use templates to add and update work items. If team members don't have access to all the features they want, make sure they have the permissions needed for those features. When you add a team to a project, a Project Administrator should add one or more team administrators. Many Agile tools depend on the area and iteration paths that are configured for the team. To learn more about configuring team areas and iterations, see About teams and Agile tools. Once project administrators add area paths and iteration paths for a project, team administrators can select the area and iteration paths associated with their team. These settings affect many Agile tools available to the team.
- 161. Configure team backlogs, boards, and general settings NOTE NOTE Settings include making the following associations for each team: Select team Area Paths Can select the default area path(s) associated with the team. These settings affect many Agile tools available to the team. Select team Iteration Paths or sprints Can select the default area path(s) associated with the team. These settings affect many Agile tools available to the team. For more information, see Define area paths and assign to a team and Define iteration paths and configure team iterations. Team administrators can choose which backlog levels are active for a team. For example, a feature team may choose to show only the product backlog and a management team may choose to show only the feature and epic backlogs. Also, administrators can choose whether bugs are treated similar to user stories and requirements or as tasks. Team administrators can also choose which days are non-working days for the team. Sprint planning and tracking tools automatically consider days off when calculating capacity and sprint burndown. You can configure most of your team settings from the common configuration dialog. The common configuration Settings dialog is available for TFS 2015.1 and later versions. To understand the differences between backlogs, boards, taskboards, and Delivery plans, see Backlogs, boards, and plans. If your backlog or board doesn't show the work items that you expect or want, see Set up your backlogs and boards.
- 162. 1. Check that you selected the correct project, and then choose Boards > Boards, and select the correct team from the team selector dropdown menu. For more information, see Use breadcrumbs and selectors to navigate and open artifacts. 2. Choose Team settings to configure the board and set general team settings. 3. Choose a tab under any of the sections—Cards, Board, Charts, and General—to configure the cards or boards, the cumulative flow chart, or other team settings. When you're done configuring the settings, select Save and close.
- 163. 1. Check that you selected the right project, (2) choose Boards > Boards, and then (3) select the correct team from the team selector menu. 2. Make sure that you select the team backlog or board that you want to configure using the team selector. To learn more, see Use breadcrumbs and selectors to navigate and open artifacts. 3. Choose the product or portfolio backlog from the board-selection menu.
- 164. 4. Choose Team settings to configure the board and set general team settings. 5. Choose a tab under any of the sections—Cards, Board, Charts, and General—to configure the cards or boards, the cumulative flow chart, or other team settings. 1. Make sure that you select the team from the project/team selector. You can switch your team focus to one that you've recently viewed from the project/team selector. If you don't see the team or project you want, choose Browse… or choose Azure DevOps to access the Projects page.
- 165. 2. Open Work > Backlogs > Board. 3. Choose the board you want to configure and then choose Team settings to configure the board and set general team settings. For example, from the Kanban board ... 4. Choose a tab under Cards or Board to configure the cards and Kanban board columns and swimlanes. ![Common configuration dialog team settings]../.../boards/boards/media/customize-cards/common- config-141.png) Team administrators can fully customize the team's Kanban boards associated with the product and portfolio backlogs. You configure a Kanban board by first defining the columns and WIP limits from the common configuration dialog. For guidance, see Kanban basics.
- 166. For more information on each configuration option, see the following articles: General Backlogs Working days Working with bugs Cards Add fields Define styles Add tag colors Enable annotations Configure inline tests Boards Add columns Split columns WIP limits Definition of Done Add swimlanes Card reordering Configure status badges Add columns Split columns WIP limits Definition of Done Add swimlanes Card reordering Chart Configure cumulative flow chart Kanban board
- 167. Configure sprint Taskboards Add and manage team dashboards Update team name, description, and image Similar to Kanban boards, each sprint Taskboard can be customized to support information-rich, color-coded cards as well as addition of customized columns. For details, see Customize sprint Taskboards. Similar to Kanban boards, each sprint Taskboard can be customized to support information-rich, color-coded cards. For details, see Customize sprint Taskboards. By default, all team members can add and edit team dashboards. In addition, team administrators can manage permissions for team dashboards. For details, see Add and manage dashboards. Team administrators can add, configure, and manage permissions for team dashboards. For details, see Add and manage dashboards.
- 168. Manage notifications Team settings also include the team name, description, and team profile image. To add a team picture, select the image icon. The maximum file size is 2.5 MB. Team settings also include the team name, description, and team profile image. To add a team picture, select the image icon. The maximum file size is 2.5 MB. Team settings also include the team name, description, and team profile image. To add a team picture. Open the Team Profile and choose the picture icon. The maximum file size is 4 MB. Team administrators can add and modify alerts so that the team can receive email notifications as changes occur to work items, code reviews, source control files, and builds. Many alerts are defined for each team. For details, see Manage team alerts.
- 169. Related articles About projects and scaling your organization About teams and Agile tools Add teams Add a team administrator
- 170. Request an increase in permission levels 6/9/2022 • 4 minutes to read • Edit Online Common permissions to request Prerequisites Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 To get access to certain tasks, you might need to request an increase to your permissions or be added to a security role. Typically, you'll do this upon receiving an information or error message indicating you have insufficient permissions. Such a message will indicate the permission levels you need. Prior to requesting a change in permission levels, make sure you understand the basics by reviewing Get started with permissions, access, and security groups. Most users added to the Contributors group are granted the permissions they need to perform most tasks. However, the following tasks require membership in the Project Administrators group or a change in permissions. Work tracking Add or change Area Paths or Iteration Paths: Requires elevated permissions to an Area Path or Iteration Path node. To learn more, see Set work tracking permissions, Create child nodes. Create shared queries or query folders: Requires elevated permissions set for a shared query folder. To learn more, see Set work tracking permissions, Set permissions on queries or query folders. Change team settings—such as Kanban board settings: Requires addition as a team administrator. To learn more, see Add or remove a team administrator Source code, Git repositories, the following tasks require elevated permissions for Git repositories or a specific repository. To learn more, see Set Git repository permissions. Create, delete, or rename a Git repository Manage repository permissions Bypass policies The following tasks require membership in the Project Collection Administrators group or a change in permissions at the collection-level or addition to a specific role. Collection-level configurations Create projects: Requires elevated permissions at the collection level. Add, edit, or manage a process: Requires elevated permissions at the collection level or process-level permissions. Install, uninstall, or disable extensions: Requires addition to the Manager role for extensions. For an overview of built-in security groups and default permission assignments, see Default permissions and access. To view permissions, you must be a member of the Project Valid Users group. Users added to a project are automatically added to this security group. To learn more, see View permissions for yourself or others. To look up an administrator for your project or project collection, you must be a member of the Project Valid Users group.
- 171. NOTE Review your permission assignments Request a change to a permission level or role change Refresh or re-evaluate your permissions Users added to the Project-Scoped Users group won't be able to access Organization Settings other than the Overview section if the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization. To learn more, see Manage your organization, Limit user visibility for projects and more. Before you request a change to permission levels, review your permission assignments as described in View permissions for yourself or others. Verify that your permission assignments are preventing you from accomplishing a task you need to perform. To request a change or increase in your permission levels, take the following actions: 1. Identify the permissions you need and at what level. Permissions are set at the object, project, and project-collection level. Also, permissions are granted through various roles. To identify the level and permission you need, review the Permissions lookup guide. 2. Identify a person in your organization who can grant you the permissions you need. For example: To get permissions to manage team settings, identify the team administrator for your team or a member of the Project Administrators group. To change an object-level permissions, identify the owner of the object or a member of the Project Administrators group. To learn how, see Set object-level permissions. To change a project-level permission, identify a member of the Project Administrators group. See Look up a project administrator. To change a project collection-level permission, identify a member of the Project Collection Administrators group. See Look up a project collection administrator. 3. Contact the person you identified in step 2 and make your request. Make sure you specify the permission you want changed. After your permission levels are changed, you may need to refresh your permissions for Azure DevOps to recognize the changes. This step is recommended when a change is made to your permission level, role level, or if you are added to a new or different Azure DevOps, Azure Active Directory, or Active Directory security group. When you are added to a new or different security group, your inherited permissions may change. By refreshing your permissions, you cause Azure DevOps to re-evaluate your permission assignments. Otherwise, your permission assignments won't be refreshed until you sign-off, close your browser, and sign-in again. To refresh your permissions, choose User settings, on the Permissions page, you can select Re-evaluate permissions. This function reevaluates your group memberships and permissions, and then any recent changes take effect immediately.
- 172. Related articles Permissions lookup guide Default permissions and access Troubleshoot permissions Look up a project administrator Look up a project collection administrator
- 173. Grant or restrict access using permissions 6/9/2022 • 6 minutes to read • Edit Online TIP Recommended method for granting and restricting permissions Delegate tasks to specific roles Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 You can grant or restrict access to resources that you manage in Azure DevOps. You may want to open up or close down access to a select set of features and for a select set of users. While the built-in security groups provide a standard set of permission assignments, you may need additional security requirements not met by these assignments. If you're new to administrating permissions and groups, review Get started with permissions, access, and security groupsto learn about permission states and inheritance. In this article you learn how to do the following tasks: Recommended method for granting and restricting permissions Delegate tasks by assigning select permissions to specific roles Limit visibility to organization information Limit people picker to project users and groups Restrict access to view or modify objects Restrict modification of work items based on a user or group Recommended method for granting and restricting permissions Delegate tasks by assigning select permissions to specific roles Restrict access to view or modify objects Restrict modification of work items based on a user or group Because you set many permissions at an object-level, such as repositories and area paths, how you structure your project determines the areas you can open up or close down. For maintenance purposes, we recommend you use either the built-in security groups or custom security groups to manage permissions. You can't change the permission settings for the Project Administrators group or the Project Collection Administrators group, which is by design. However, for all other groups, you can change the permissions. If you manage a small number of users, then you may find changing individual permissions a valid option. However, custom security groups allow you to better track roles and permissions assigned to those roles. As an administrator or account owner, it's a good idea to delegate administrative tasks to those team members who lead or manage an area. Several of the main built-in roles that come with default permissions and role assignments are: Readers Contributors
- 174. Team Administrator (role) Project Administrators Project Collection Administrators For a summary of permissions for the above roles, see Default permissions and access, or for the Project Collection Administrators, see Change project collection-level permissions. To delegate tasks to other members within your organization, consider creating a custom security group and then granting permissions as indicated in the following table. Role Tasks to perform Permissions to set to Allow Development lead (Git) Manage branch policies Edit policies, Force push, and Manage permissions See Set branch permissions. Development lead (TFVC) Manage repository and branches Administer labels, Manage branch, and Manage permissions See Set TFVC repository permissions. Software architect (Git) Manage repositories Create repositories, Force push, and Manage permissions See Set Git repository permissions Team administrators Add area paths for their team Add shared queries for their team Create child nodes, Delete this node, Edit this node See Create child nodes, modify work items under an area path Contribute, Delete, Manage permissions (for a query folder), See Set query permissions. Contributors Add shared queries under a query folder, Contribute to dashboards Contribute, Delete (for a query folder), See Set query permissions View, Edit, and Manage dashboards, See Set dashboard permissions. Project or product manager Add area paths, iteration paths, and shared queries Delete and restore work items, Move work items out of this project, Permanently delete work items Edit project-level information, See Change project-level permissions. Process template manager (Inheritance process model) Work tracking customization
- 175. Limit visibility to organization and project information Limit people picker to project users and groups Administer process permissions, Create new projects, Create process, Delete field from account, Delete process, Delete project, Edit process See Change project collection-level permissions. Process template manager (Hosted XML process model) Work tracking customization Edit collection-level information, See Change project collection-level permissions. Project management (On-premises XML process model) Work tracking customization Edit project-level information, See Change project-level permissions. Permissions manager Manage permissions for a project, account, or collection For a project, Edit project-level information For an account or collection, Edit instance-level (or collection-level) information To understand the scope of these permissions, see Permission lookup guide. To request a change in permissions, See Request an increase in permission levels. You can also grant permissions to manage permissions for the following objects: Set Git repository permissions Manage Git branch permissions Set TFVC repository permissions Administer build and release permissions Manage Wiki permissions. By default, users added to an organization can view all organization and project information and settings. To restrict access to only those projects that you add users to, you can enable the Limit user visibility and collaboration to specific projects preview feature for the organization. To enable this feature, see Manage or enable features. With this feature enabled, users added to the Project-Scoped Users group can't view most Organization settings and can only connect to those projects to which they've been added. For organizations that manage their users and groups using Azure Active Directory (Azure AD), people pickers provide support for searching all users and groups added to Azure AD, not just those added to a project. people pickers support the following Azure DevOps functions: Selection of a user identity from a work tracking identity field such as Assigned To Selection of a user or group using @mention in a work item discussion or rich-text field, a pull request discussion, commit comments, or changeset or shelveset comments Selection of a user or group using @mention from a wiki page As shown in the following image, you simply start typing into a people picker box until you find a match to a user name or security group.
- 176. Restrict access to view or modify objects Restrict modification of work items or select fields Next steps Related articles Users and groups who are added to the Project-Scoped Users group can only see and select users and groups in the project they are connected to from a people picker. To scope people pickers for all project members, see Manage your organization, Limit identity search and selection. Azure DevOps is designed to enable all valid users to view all objects defined in the system. You can restrict access to resources by setting the permission state to Deny. You can set permissions for members that belong to a custom security group or for an individual user. To learn more about how to set these types of permissions, see Request an increase in permission levels. Area to restrict Permissions to set to Deny View or contribute to a repository View, Contribute See Set Git repository permissions or Set TFVC repository permissions. View, create, or modify work items within an area path Edit work items in this node, View work items in this node See Set permissions and access for work tracking, Modify work items under an area path. View or update select build and release pipelines Edit build pipeline, View build pipeline Edit release pipeline, View release pipeline You set these permissions at the object level. See Set build and release permissions. Edit a dashboard View dashboards See Set dashboard permissions. For examples that illustrate how to restrict modification of work items or select fields, see Sample rule scenarios. Remove user accounts
- 177. Troubleshoot permissions Rules and rule evaluation Default permissions and access Permission lookup guide Get started with permissions, access, and security groups Permissions and groups reference Change project-level permissions Change project collection-level permissions
- 178. Security best practices 6/9/2022 • 14 minutes to read • Edit Online Scope service accounts Scope service connections GitHub Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Security should always be your topmost concern when you’re working with information and data, especially when you're working in a cloud-based solution, like Azure DevOps Services. Microsoft keeps the underlying cloud infrastructure secure, but it's up to you to configure security in Azure DevOps. You don't have to implement best practices when using Azure Devops, but doing so will likely help you have a better, more secure experience. We've gathered some best practices for keeping your Azure DevOps environment secure, with the following goals in mind: Properly scope service accounts, service connections, and permissions Maintain tight control of administrators and service account groups Manage security with security groups, policies, and settings at the organization/collection, project, or object level Secure services, like Azure Artifacts, Azure Boards, Azure Pipelines, Azure Repos, Azure Test Plans, and Azure DevOps in general. Ensure service accounts have zero interactive sign-in rights. Restrict service account privileges to the bare minimum necessary. Use a different identity for the report reader account, if you use domain accounts for your service accounts. For more information, see Service accounts and dependencies. Use local accounts for user accounts, if you're installing a component in a workgroup. For more information, see Service account requirements. Use service connections when possible. Service connections provide a secure mechanism to connect to assorted services without the need to pass in secret variables to the build directly. - Restrict these connections to the specific place they should be used and nothing more. Monitor service account activity and create audit streaming. Auditing allows you to detect and react to suspicious sign-ins and activity. For more information, see Common service connection types. Scope Azure Resource Manager, and other service connections, only to the resources and groups to which they need access. Service connections shouldn't have broad contributor rights on the entire Azure subscription. Don’t give users generic or broad contributor rights on the Azure subscription. Don’t use Azure Classic service connections, as there’s no way to scope the permissions. Make sure the resource group only contains Virtual Machines (VMs) or resources that the build needs access to. Use a purpose-specific team service account to authenticate a service connection. For more information, see Common service connection types.
- 179. Scope permissions Individual permissions External guest access Manage security groups, policies, and settings Security and user groups DO DON'T Use Azure Active Directory, Active Directory, or Windows security groups when you're managing lots of users. Don’t change the default permissions for the Project Valid Users group. This group can access and view project information. When you're adding teams, consider what permissions you want to assign to team leads, scrum masters, and other team members who may need to create and modify area paths, iteration paths, and queries. Don't add users to multiple security groups that contain different permission levels. In certain cases, a Deny permission level may override an Allow permission level. When you're adding many teams, consider creating a Team Administrators custom group where you allocate a subset of the permissions available to Project Administrators. Don't change the default assignments made to the valid users groups. If you remove or set the View instance-level information permission to Deny for one of the Valid Users groups, no users in the group can access the project, collection, or deployment, depending on the group you set. Disable Personal Access Token (PAT)-based authentication, so the OAuth flow gets used with the GitHub service connection. Never authenticate GitHub service connections as an identity that's an administrator or owner of any repositories. Check your policies. Never use a full-scope GitHub PAT (Personal Access Token) to authenticate GitHub service connections. Don't use a personal GitHub account as a service connection with Azure DevOps. The system manages permissions at different levels - individual, external, server, collection, project, object, and - and assigns them to one or more built-in groups by default. For more information, see Set individual permissions. Block external guest access entirely by disabling the "Allow invitations to be sent to any domain" policy. It's a good idea to do so if there's no business need for it. Use a different email or user principal name (UPN) for your personal and business accounts, even though it's allowed. This action eliminates the challenge of disambiguating between your business and personal accounts when the email/UPN is the same. Put all the external guest users in a single Azure AD group and manage the permissions of that group appropriately. You can easily manage and audit this way. Remove direct assignments so the group rules apply to those users. For more information, see Add a group rule to assign access levels. Reevaluate rules regularly on the Group rules tab of the Users page. Clarify whether any group membership changes in Azure AD might affect your organization. Azure AD can take up to 24 hours to update dynamic group membership. Every 24 hours and anytime a group rule changes, rules get automatically reevaluated in the system. For more information, see B2B guests in the Azure AD. See the following recommendations for assigning permissions to security groups and users groups.
- 180. Consider granting the work item query folders Contribute permission to users or groups who require the ability to create and share work item queries for the project. Don't assign permissions that are noted as Assign only to service accounts to user accounts. Keep groups as small as possible. Access should be restricted, and the groups should be frequently audited. Take advantage of built-in roles and default to Contributor for developers. Admins get assigned to the Project Administrator security group for elevated permissions, allowing them to configure security permissions. DO DON'T Server-level groups Project-level permissions See the following table of built-in security groups, which users to add, and best practice tips. Built-in security group Add these users Best practice tips Team Foundation Administrators People who need to perform all server-level operations. This group should be restricted to the smallest possible number of users who need total administrative control over server-level operations. If your deployment uses SharePoint or Reporting, consider adding the members of this group to the Farm Administrators and Site Collection Administrators groups in SharePoint and the Team Foundation. Team Foundation Valid users People who need to view server instance-level information. This group contains all users known to exist in the server instance. You can't modify the membership of this group. Limit access to projects and repos to reduce the risk of leaking sensitive information and deploying insecure code to production. Use either the built-in security groups or custom security groups to manage permissions. For more information, see Grant or restrict permissions to select tasks. Built-in security group Add these users Best practices Project Collection Administrators People who need total administrative control over the collection. This group should be restricted to the smallest possible number of users who need total administrative control over the collection. For Azure DevOps, assign to administrators who customize work tracking.
- 181. Removing users Choose the right authentication method Require multi-factor authentication Use Azure AD Use PATs seldomly If your deployment uses Reporting Services, consider adding the members of this group to the Team Foundation Content Managers groups in Reporting Services Project Collection Build Administrators People who need to administer build resources and permissions for the collection. Limit this group to the smallest possible number of users who need total administrative control over build servers and services for this collection. Project-scoped users People who need limited access to view organization settings and projects other than those projects they’re specifically added to. Add users to this group when you want to limit their visibility and access to those projects that you explicitly add them to. Do not add users to this group if they are also added to the Project Collection Administrators group. If your organization uses MSA accounts, then remove inactive users directly from the organization, as you have no other way to prevent access. When you do so, you can't create a query for work items assigned to the removed user account. For more information, see Delete users from Azure DevOps. If your organization is backed by Azure AD, then you can disable or delete the Azure AD user account while leaving their Azure DevOps account active. In this way, you can continue to query their work item history using their account name. Revoke user PATs. Revoke any special permissions that may have been granted to individual user accounts. Reassign work from users you’re removing to current team members. Select your authentication methods from the following sources: Multi-factor authentication Azure Active Directory (Azure AD) Personal access tokens (PATs) Require all users to use multi-factor authentication (MFA), as a basic security feature. Multi-factor authentication requires use of more than on verification method, which adds a second layer of security to all Azure DevOps transactions. Integrate Azure DevOps with Azure AD to have a single plane for identity. Consistency and a single authoritative source increases clarity and reduces security risks from human errors and configuration complexity. The key to end to end governance is to have multiple role assignments (with different role definitions and different resource scopes to the same Azure AD groups). Without Azure AD, you're solely responsible for controlling organization access. For more information, see the following articles: About accessing your organization with Azure AD Add AD/Azure AD users or groups to a built-in security groups
- 182. Limit access by location Secure your network Use Web application firewalls Secure projects Always authenticate with identity services rather than cryptographic keys when available. Managing keys securely with application code is difficult and regularly leads to mistakes like accidentally publishing sensitive access keys to code repositories like GitHub. But, if you're using PATs, see the following recommendations: Administrators should audit all PATs using the REST APIs and revoke any PATs that don’t meet the following criteria for PATs in use: Should always be scoped (roles). Shouldn’t be global (can access more than one organization). Shouldn’t allow write or manage permissions on build or releases. Should have an expiration date. Should be kept secret. Your tokens are as critical as passwords. Should have an expiration date. Shouldn’t be hardcoded. It can be tempting to simplify code to get a token for a prolonged period and store it in your application, but don’t do that. They could end up in source code that could be stolen. Keep your PATs secret. Your tokens are as critical as passwords. Store your tokens in a safe place. Don’t hard code tokens in applications. It can be tempting to simplify code to obtain a token for a long period of time and store it in your application, but don’t do that. Give tokens an expiration date. For more information, check out the following articles: Manage PATs with policies - for administrators Use PATs Limit access to specific IP (Internet Protocol) address ranges with Azure AD Conditional Access Policy Validation. For example, you can configure a location so that MFA isn’t required for internal IP addresses. For more information, see Using the location condition in a Conditional access policy. Set up an allowlist. Implement Web application firewalls (WAFs), so they can filter, monitor, and block any malicious web-based traffic to and from Azure DevOps. Always use encryption. Validate certificates. This shouldn’t be the only planned safety mechanism to reduce the volume and severity of security bugs in your applications. For more information, see Application management best practices Enable the Limit user visibility for projects preview feature for the organization, which restricts access to only those projects that you add users to. Add users to the Project-scoped users group, so they can only see and select users and groups in the project that they're connected to from a people picker.
- 183. Secure Azure Artifacts Secure Azure Boards Secure Azure Pipelines Policies Agents Disable "Allow public projects" in your organization's policy settings to prevent every organization user from creating a public project. Azure DevOps Services allows you to change the visibility of your projects from public to private, and vice-versa. If users haven't signed into your organization, they have read-only access to your public projects. If users have signed in, they can be granted access to private projects and make any permitted changes to them. Don’t allow users to create new projects. Use EasyStart “Governed Projects,” which require approval once they're submitted. Check out the following articles for more in-depth information about setting sub-project permissions. Set wiki permissions Set feedback permissions Set dashboard permissions Set Analytics permissions Make sure you understand the difference between feeds, project, and project collection administrators. For more information, see Configure Azure Artifacts settings. For more information, see Set feed permissions. Review Configure and customize Azure Boards before you customize a process. See the following articles: Set work tracking and plan permissions Default permissions and access to Azure Boards Set query permissions Use extends templates. For more information about how to set permission levels for pipelines, see Set pipeline permissions. Require at least one reviewer outside of the original requester. The approver takes co-ownership of the changes and should be held equally responsible for any impact it may have. Require CI build to pass, which is useful for establishing baseline code quality, such as code linting, unit tests, and even security checks like virus and credential scans. Ensure that the original pull requester can’t approve the change. Disallow completion of a PR (Pull Request), even if some reviewers vote to wait or reject. Reset code reviewer votes when recent changes get pushed. Lock down release pipelines by running them only on specific production branches. Enable “Enforce settable at queue time for variables” in your organization’s pipeline settings. Don’t allow “Let users override this value when running this pipeline,” for variables set in the editor. Grant permissions to the smallest possible number of accounts. Have the most restrictive firewall that leaves your agents usable. Update pools regularly to ensure the build fleet isn’t running vulnerable code that can be exploited by a malicious actor. Use a separate agent pool for build artifacts that get shipped or deployed to production. Segment “sensitive” pool from non-sensitive pools, and only allow the use of credentials in build definitions
- 184. Definitions Input Tasks Repositories and branches Secure Azure Repos Secure Azure Test Plans that are locked to that pool. Manage pipeline definitions with YAML (Yet Another Markup Language). YAML is the preferred method for managing pipeline definitions, as it provides traceability for changes and can follow approval guidelines. Secure the pipeline definition Edit access to the minimum number of accounts. Include sanity checks for variables in build scripts. A sanity check can mitigate a command injection attack through the settable variables. Set as few build variables as possible to “Settable at release time.” Avoid remotely fetched resources, but, if necessary, use versioning and hash checking. Don’t log secrets. Don’t store secrets in pipeline variables, use Azure KeyVault. Regularly scan your build pipelines to ensure secrets aren’t being stored in build pipeline variables. Don’t let users run builds against arbitrary branches or tags on security-critical pipelines. Disable inheritance on the pipeline, as inherited permissions are broad and don’t accurately reflect your needs for permissions. Limit job authorization scopes in all cases. Set the “Require a minimum number of reviewers,” policy to on, so that every pull request gets reviewed by at least two approvers. Configure security policies specific to each repository or branch, instead of project wide. Security policies reduce risk, enforce change management standards, and improve your team’s quality of code. Store production secrets in a separate KeyVault and ensure that access is only granted on a need-to-know basis to keep non-production builds separate. Don’t mix test environments with production, including use of credentials. Disable forking. The more forks there are, the harder it is to keep track of each fork’s security. Also, a user can easily fork a copy of a repository to their own private account. Don't provide secrets to fork builds. Consider manually triggering fork builds. Use Microsoft-hosted agents for fork builds. For Git, check your production build definitions in the project’s git repository, so they can be scanned for credentials. Configure a branch control check so that only pipelines running in the context of the production branch may use the prod-connection . For more information, see Other security considerations. For more information about granular permission controls that can be configured according to the project’s needs, see Security groups, service accounts, and permissions in Azure DevOps. Improve code quality with branch policies. For more information about branch permissions and policies, see Set branch permissions.
- 185. Secure Azure DevOps - general Related articles Check out the following articles: Set permissions and access for testing Supported scenarios and access requirements Disable inheritance where possible. Due to the allow-by-default nature of inheritance, unexpected users can get access or permissions. For more information, read about inheritance. Only give users and services the minimum amount of access to perform their business functions. Periodically review audit events to monitor and react to unexpected usage patterns by administrators and other users. Check out the following articles: Permissions and role lookup guide Permissions, security groups, and service accounts reference Valid user groups Project-scoped user groups Manage conditional access Unit testing best practices with .NET Core and .NET Standard
- 186. Plan your organizational structure 6/9/2022 • 15 minutes to read • Edit Online What's an organization? Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Use your business structure as a guide for the number of organizations, projects, and teams that you create in Azure DevOps. This article helps you plan for different structures and scenarios for Azure DevOps. Consider the following structures for your business and collaborative work in Azure DevOps: Number of organizations Number of projects under an organization You also may want to plan for the following scenarios: Map your organizations and projects in Azure DevOps to your enterprise, business unit, and team structure Structure your repositories (repos) Structure your teams- it can either help or hinder teams to be Agile and autonomous Manage access to data - who needs to have access and who doesn't? Reporting needs Promote common practices - use foundational elements to create an agile mindset and culture Have at least one organization, which may represent your company, your larger collection of code projects, or even multiple related business units. An organization in Azure DevOps is a mechanism for organizing and connecting groups of related projects. Examples include business divisions, regional divisions, or other enterprise structures. You can choose one organization for your entire company, one organization for yourself, or separate organizations for specific business units. Each organization gets its own free tier of services (up to five users for each service type) as follows. You can use all the services, or choose only what you need to complement your existing workflows. Azure Pipelines: One hosted job with 1,800 minutes per month for CI/CD and one self-hosted job Azure Boards: Work item tracking and Kanban boards Azure Repos: Unlimited private Git repos Azure Artifacts: Package management Unlimited Stakeholders Five Azure DevOps users (Basic) Free tier of Microsoft-hosted CI/CD (one concurrent job, up to 30 hours per month) 2 GiB of Azure Artifacts storage One self-hosted CI/CD concurrent job
- 187. NOTE How many organizations do you need? TIP What's a team? Create a team for each distinct product or feature team What's a project? While Azure DevOps cloud-based load testing service is deprecated, Azure Load Testing Preview is available. Azure Load Testing Preview is a fully managed load testing service that enables you to use existing Apache JMeter scripts to generate high-scale load. To learn more, see What is Azure Load Testing Preview?. To learn more about the deprecation of Azure DevOps load testing and other, alternative services see Changes to load test functionality in Visual Studio and cloud load testing in Azure DevOps. Start with one organization in Azure DevOps. Then, you can add more organizations—which may require different security models—later. A single code repo or project only needs one organization. If you have separate teams that need to work on code or other projects in isolation, consider creating separate organizations for those teams. They'll have different URLs. Add projects, teams, and repos, as necessary, before you add another organization. Take some time to review your work structure and the different business groups and participants to be managed. For more information, see Map your projects to business units and Structure considerations. For company-owned Azure AD organizations, consider restricting users from creating new organizations as a way to protect your IP. For more information, see Restrict organization creation via Azure AD tenant policy. Users can create organizations using their MSA or GitHub accounts with no restrictions. A team is a unit that supports many team-configurable tools. These tools help you plan and manage work, and make collaboration easier. Each team owns their own backlog. To create a new backlog, you create a new team. Configure teams and backlogs into a hierarchical structure, so program owners can more easily track progress across teams, manage portfolios, and generate rollup data. A team group gets created when you create a team. You can use this group in queries or to set permissions for your team. A project in Azure DevOps contains the following set of features: Boards and backlogs for agile planning Pipelines for continuous integration and deployment Repos for version control and management of source code and artifacts Continuous test integration throughout the project life cycle Each organization contains one or more projects In the following image, the fictitious Contoso company has four projects within their Contoso-Manufacturing organization.
- 188. How many projects do you need? NOTE Single project TIP Have at least one project to start using an Azure DevOps service, such as Azure Boards, Azure Repos, or Azure Pipelines. When you create your organization, a default project gets created for you. In your default project, there's a code repo to start working in, backlog to track work, and at least one pipeline to begin automating build and release. Within an organization, you can do either of the following approaches: Create a single project that contains many repos and teams Create many projects, each with its own set of teams, repos, builds, work items, and other elements Even if you have many teams working on hundreds of different applications and software projects, you can manage them within a single project in Azure DevOps. However, if you want to manage more granular security between your software projects and their teams, consider using many projects. At the highest level of isolation is an organization, where each organization is connected to a single Azure AD tenant. A single Azure AD tenant, however, can be connected to many Azure DevOps organizations. If the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization, users added to the Project-Scoped Users group won't be able to access projects that they haven't been added to. For more information, see Manage your organization, Limit user visibility for projects and more. A single project puts all of the work at the same "portfolio" level for the entire organization. Your work has the same set of repos and iteration paths. With a single project, teams share source repos, build definitions, release definitions, reports, and package feeds. You might have a large product or service that's managed by many teams. Those teams have tight inter-dependencies across the product life cycle. You create a project and divide the work using teams and area paths. This setup gives your teams visibility into each other's work, so the organization stays aligned. Your teams use the same taxonomy for work item tracking, making it easier to communicate and stay consistent. When multiple teams work on the same product, having all teams on the same iteration schedule helps keep your teams aligned and delivering value on the same cadence. For example, our organization in Azure DevOps has over 40 feature teams and 500 users within a single project - this works well because we're all working on a common product set with common goals and a common release schedule.
- 189. Many projects TIP ONE PROJECT, MANY TEAMS ONE ORGANIZATION, MANY PROJECTS, AND TEAMS MANY ORGANIZATIONS General guidance Best for smaller organizations or larger organizations with highly aligned teams. Good when different efforts require different processes. Useful as part of TFS legacy migrations and for hard security boundaries between organizations. Used with multiple projects and teams within each organization. Scale Supports tens of thousands of users and hundreds of teams, but best at this scale if all teams are working on related efforts. Same as with one project, but many projects may be easier. A high volume of queries and boards can make it hard to find what you're looking for. Depending on the architecture of your product, this difficulty can bleed into other areas such as builds, releases, and repos. Make sure to use good naming conventions and a simple folder structure. When you add a repo to your project, consider your strategy and determine whether that repo could be placed into its own project. You can best determine project structure by how you ship the product. Having several projects shifts the administration burden and gives your teams more autonomy to manage the project as the team decides. It also provides greater control of security and access to assets across the different projects. Having team independence with many projects creates some alignment challenges, however. If each project is using a different process or iteration schedule, it can make communication and collaboration difficult if the taxonomies aren't the same. If you use the same process and iteration schedules across all your projects, your ability to roll-up data and report across teams improves. Azure DevOps provides cross-project experiences for managing work. You may want to add another project due to the following scenarios: To prohibit or manage access to the information within a project To support custom work tracking processes for specific business units within your organization To support entirely separate business units that have their own administrative policies and administrators To support testing customization activities or adding extensions before rolling out changes to the working project When you're considering many projects, keep in mind that Git repo portability makes it easy to migrate repos (including full history) between projects. Other history can't be migrated between projects. Examples are push and pull request history. When you map projects to business units, your company gets a single organization and sets up many projects with one or more projects representing a business unit. All Azure DevOps assets of the company are contained within this organization and located within a given region (for example, Western Europe). Consider the following guidance for mapping your projects to business units:
- 190. Process Aligned processes across teams; team flexibility to customize boards, dashboards, and so on. Independent processes for each project. For example, different work item types, custom fields, and so on. Same as many projects. Collaboration Highest default visibility and reuse between work and assets of different teams. Good visibility and reuse are possible, but it's easier to hide assets between projects whether intentional. Poor visibility, collaboration, and reuse between organizations. Roll-up reporting and portfolio management Best ability to roll up across teams and coordinate between teams. Good reporting possible across projects. More difficult for cross-project roll-up and team coordination. No roll-up or coordination between organizations. Security/isolation Can lock down assets at a team level, but default is open visibility and collaboration. Better ability to lock down between projects. By default, provides good visibility within projects and good isolation across projects. Hard boundaries across organizations; excellent isolation and minimal ability to share across organizations. Context switching Easiest for teams to work together and for users to switch between efforts. Relatively easy for users to work together and switch contexts between efforts. More difficult for users having to work across different organizations. Information overload By default, all assets are visible to users who make use of “favorites” and similar mechanisms to avoid “information overload.” Reduced risk of information overload; most project assets hidden across project boundaries. Assets across organizations are isolated, reducing risk of information overload. Administrative overhead Much administration is delegated down to individual teams. Easiest for user licensing and org-level administration. More work may be needed if alignment is required between efforts. More administration at the project level. More overhead, but can be useful when projects have different administrative needs. As with more projects, there's more administrative overhead, which enables more flexibility between orgs. ONE PROJECT, MANY TEAMS ONE ORGANIZATION, MANY PROJECTS, AND TEAMS MANY ORGANIZATIONS Structure repos and version control within a project Consider the specific strategic work scoped to one of the organizations you created previously and who needs access. Use this information to name and create a project. This project has a URL defined under the organization you created it in and can be accessed at https://dev.azure.com/{organization-name}/{project-name}. Configure your project in Project settings.
- 191. Manage version control Git vs. Team Foundation Version Control (TFVC) One vs. many repos For more information about managing projects, see Manage projects in Azure DevOps. You can move a project to a different organization by migrating the data. For more information about migrating your project, see Migration options. In projects where the Azure Repos service is enabled, version control repos can store and revise code. Consider the following options when you're configuring repos. Azure Repos offers the following version control systems for teams to choose from: Git and TFVC. Projects can have repos of each type. By default, new projects have an empty Git repo. Git enables a great amount of flexibility in developer workflows and integrates with nearly every relevant tool in the developer ecosystem. Any project can use Git repos. There's no limit on the amount of Git repos that can be added to a project. TFVC is a centralized version control system that is also available. Unlike Git, only one TFVC repository is allowed for a project. But, within that repo, folders, and branches are used to organize code for multiple products and services, if wanted. Projects can use both TFVC and Git, if appropriate. Do you need to set up multiple repos within a single project or have a repo set up per project? The following guidance relates to the planning and administration functions across those repos.
- 192. TIP Shared repo vs. forked repos One project containing multiple repos works well if the products/services are working on a coordinated release schedule. If developers are frequently working with multiple repos, keep them in a single project to ensure the processes remain shared and consistent. It's easier to manage repo access within a single project, as access controls and options like case enforcement and max file size get set at the project level. You can manage the access controls and settings individually, even if your repos are in a single project. If the products stored in multiple repos work on independent schedules or processes, you can split them into multiple projects. Git repo portability makes it easy to move a repo between projects and still keep full-fidelity commit history. Other history, such as pull requests or build history, aren't easily migrated. Base your decision for one vs. many repos on the following factors and tips: code dependencies and architecture put each independently deploy-able product or service in its own repo don't separate a codebase into many repos if you expect to make coordinated code changes across those repos, as no tools can help coordinate those changes if your codebase is already a monolith, keep it in one repo. For more information about monolithic repos, see How Microsoft develops modern software with DevOps articles if you have many disconnected services, one repo per service is a good strategy Consider managing your permissions, so not everyone in your organization can create a repo. If you have too many repos, it's hard to keep track of who owns which code or other content stored in those repos. We recommend using a shared repo within a trusted organization. Developers use branches to maintain isolation of their changes from one another. With a good branching and release strategy, a single repo can scale to support concurrent development for more than a thousand developers. For more information about branching and release strategy, see Adopt a Git branching strategy and Release Flow: Our Branching Strategy. Forks can be useful when you're working with vendor teams that shouldn't have direct access to update the main repository. Forks can also be useful in scenarios where many developers contribute infrequently, such as in an open-source project. When you're working with forks, you may want to maintain a separate project to isolate the forked repos from the main repo. There may be added administrative overhead, but it keeps the main project cleaner. For more information, see the Forks article. The following image displays a sample of how "your company" could structure its organizations, projects, work items, teams, and repos.
- 193. More about organizational structure Choose your organization administrator account type Use your Microsoft account Use your Azure AD account Map organizations to business units When you create an organization, the credentials that you sign in with define which identity provider your organization uses. Create your organization with a Microsoft account or Azure AD instance. Use those credentials to sign in as an administrator to your new organization at https://dev.azure.com/{YourOrganization} . Use your Microsoft account if you don't need to authenticate users for an organization with Azure AD. All users must sign in to your organization with a Microsoft account. If you don't have one, create a Microsoft account. If you don't have an Azure AD instance, create one for free from the Azure portal or use your Microsoft account to create an organization. Then, you can connect your organization to Azure AD. You might have an Azure AD account already if you use Azure or Microsoft 365. If you work for a company that uses Azure AD to manage user permissions, you probably have an Azure AD account. If you don't have an Azure AD account, sign up for Azure AD to automatically connect your organization to your Azure AD. All users must be members in that directory to access your organization. To add users from other organizations, use Azure AD B2B collaboration. Azure DevOps authenticates users through your Azure AD, so that only users who are members in that directory have access to your organization. When you remove users from that directory, they can no longer access your organization. Only specific Azure AD administrators manage users in your directory, so administrators control who accesses your organization. For more information on managing users, see Manage users. Each business unit within your company gets its own organization in Azure DevOps, along with its own Azure AD tenant. You can set up projects within those individual organizations, as required, based on teams or ongoing work. For a larger company, you can create multiple organizations using different user accounts (most likely Azure AD accounts). Consider what groups and users share strategies and work, and group them into specific organizations. For example, the fictional Fabrikam company created the following three organizations:
- 194. TIP Related articles Fabrikam-Marketing Fabrikam-Engineering Fabrikam-Sales Each organization has a separate URL, such as: https://dev.azure.com/Fabrikam-Marketing https://dev.azure.com/Fabrikam-Engineering https://dev.azure.com/Fabrikam-Sales The organizations are for the same company, but are mostly isolated from each other. You don't need to separate anything this way. Only create boundaries when it makes sense to your business. You can more easily partition an existing organization with projects, than combine different organizations. Create an organization Create a project Connect your organization to Azure AD Set up billing Set user preferences
- 195. What is source control? 6/9/2022 • 2 minutes to read • Edit Online NOTE Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 A source control system, also called a version control system, allows developers to collaborate on code and track changes. Source control is an essential tool for multi-developer projects. Our systems support two types of source control: Git (distributed) and Team Foundation Version Control (TFVC). TFVC is a centralized, client-server system. In both Git and TFVC, you can check in files and organize files in folders, branches, and repositories. Manage your repos, branches, and other code development operations from Azure Repos. With Git, each developer has a copy of the source repository on their dev machine. The source repo includes all branch and history information. Each developer works directly with their local repository. Changes are shared between repositories as a separate step. Developers can commit each set of changes and perform version control operations, such as history and compare without a network connection. Branches are lightweight. When developers need to switch contexts, they create a private local branch. Developers can quickly switch from one branch to another to pivot among different variations of the code base. Later, developers can merge, publish, or dispose of the branch. Git in Visual Studio and Azure DevOps is standard Git. You can use Visual Studio with third-party Git services. You can also use third-party Git clients with Azure DevOps Server.
- 196. Next steps Related articles With TFVC, developers have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and are created on the server. Start sharing your code or get your code by using source control. Code with Git Azure Repos documentation Git repositories documentation
- 197. Tools and clients that connect to Azure DevOps 6/9/2022 • 6 minutes to read • Edit Online Desktop client developer tools Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Our platform of software development tools began more than 20 years ago. We released Visual Basic and Visual Studio as an integrated development environment (IDE). Visual Studio supports many plug-ins that extend its functionality. In particular, the Team Explorer plug-in allows the Visual Studio client to connect to Azure DevOps to support source control, work tracking, build, and test operations. Developers have access to many tools through these versions of Visual Studio and plug-ins. To download any version of Visual Studio, go to the Visual Studio Downloads page. To understand what features you get with the Visual Studio versions, see Compare Visual Studio offerings. Visual Studio Community: A fully featured and extensible IDE for creating modern applications for Android, iOS, and Windows, including web applications and cloud services. (Replaces Visual Studio Express.) Visual Studio Professional: Development tools and services to support individual developers or small teams. Visual Studio Enterprise: Integrated, end-to-end development tools and solutions for teams of any size, and with a need to scale. It supports designing, building, and managing complex enterprise applications. Visual Studio Test Professional: Provides access to Microsoft Test and development tools to support quality and collaboration throughout the development process. Visual Studio Team Explorer: Free solution for non-developers to interact with Azure DevOps. Eclipse/Team Explorer Everywhere: Free plug in to support teams running Eclipse on Linux, macOS, or Windows that connects to Azure DevOps. Android Studio with the Azure DevOps Services Plug-in for Android Studio: Free plug in to support Android developers and connect to Git repositories on Azure DevOps. IntelliJ with the Azure DevOps Services Plugin for IntelliJ: Free plug in to support developers who use IntelliJ IDEA or Android Studio to connect to Git repositories on Azure DevOps. Visual Studio Code: Free, open-source code editor with a free extension to support connecting to Git repositories on Azure DevOps. To get started with client libraries, see Client library samples. Team Explorer plug-in Team Explorer, a plug-in to all Visual Studio versions, connects Visual Studio to projects defined in Azure DevOps. You can manage source code, work items, and builds. To learn more, see Work in Team Explorer.
- 198. HOME PAGE WITH GIT HOME PAGE WITH TFVC Office integration tools Visual Studio Git experience Visual Studio 2019 and later versions provide a new Git experience through the Git menu as shown below. To learn more, see Git experience in Visual Studio and Side-by-side comparison of Git and Team Explorer. You can integrate the following Microsoft Office tools with Azure DevOps. Excel: Use Excel to add and bulk modify work items.
- 199. IMPORTANT TIP Task-specific clients Browser-based web tools Web portal Starting with Visual Studio 2019, the Team Foundation plug-in for Office is deprecating support for Microsoft Project. Project integration and the TFSFieldMapping command is not supported for Azure DevOps Server 2019 nor for Azure DevOps Services. However, you can continue to use Microsoft Excel. Excel: Use Excel to add and bulk modify work items. Check to make sure the Azure DevOps Office Integration component is selected in the Visual Studio Installer, per the following example. When you install any edition of Visual Studio or Team Foundation Server Standalone Office Integration 2015 (free), the Team Foundation plug-in integrates work item tracking with select Office clients. The Team Foundation plug-in installs to your existing Office client. The plug-in supports Office 2007, Office 2010, or Office 2013 versions. Excel: Use Excel to add and bulk modify work items. Project: By using Project, you can plan projects, schedule tasks, assign resources, and track changes. You have access to features that TFS doesn't support, such as a project calendar, Gantt charts, and resource views. PowerPoint Storyboarding: Illustrate user stories and requirements by using PowerPoint. The Team Foundation plug-in installs to your existing PowerPoint client. The following clients support specific tasks, such as managing testing efforts, providing feedback, or modifying work items: Azure Test Plans: Manage your test efforts, create and run manual tests, and create and track bugs that are found during test efforts. Test & Feedback extension (previously called the Exploratory Testing extension): This extension provides a lightweight plug-in to a web browser. Stakeholders can respond to feedback requests for user stories and features created in Azure DevOps. This extension is free to Stakeholders. Microsoft Feedback Client: Your Stakeholders can use this client to record feedback for your application as video, audio, or type-written comments. This client is installed with all versions of Visual Studio, or it can be installed from the free download. All feedback is stored in the work item data store and requires Stakeholders to have permissions.
- 200. VERSION EDGE INTERNET EXPLORER SAFARI (MAC) FIREFOX CHROME Azure DevOps Services Azure DevOps Server 2020.1 Most recent Not supported 14.1 and later Most recent Most recent Azure DevOps Server 2020 Azure DevOps Server 2019 TFS 2018 TFS 2017 Most recent 11 and later 14.1 and later Most recent Most recent TFS 2015 Most recent 9 and later 5 and later Most recent Most recent TFS 2013 9 and later 5 and later Most recent Most recent Browser-based extensions Command-line tools The collaboration tools supported through the web portal are summarized under Essential services. New features are deployed every three weeks for Azure DevOps Services, and quarterly for Azure DevOps Server. For release notes, see Azure DevOps Services Features Timeline. You can use the following browsers to access the web portal: Microsoft Edge, Firefox, and Chrome automatically update themselves, so Azure DevOps supports the most recent version. For more information, see Web portal navigation. Several extensions are built and maintained by the Azure DevOps Services product team: Code search: Increase cross-team collaboration and code sharing. Enables developers to quickly locate relevant information within the code base of all projects that are hosted within an organization or collection. You can discover implementation examples, browsing definitions, and error text. Work item search: To quickly find relevant work items, search across all work item fields over all projects in an organization. Do full-text searches across all fields to efficiently locate relevant work items. Use inline search filters, on any work item field, to quickly narrow down a list of work items. Find more extensions in Azure DevOps Organization settings > Extensions > Browse marketplace. See also, Overview of extensions for Azure Boards. You can do many code development and administrative tasks by using the following command-line tools: az devops commands Git commands TFVC commands TCM commands Manage permissions with command line tool (az devops security) witadmin (work item tracking) Git commands TFVC commands
- 201. Integrated tool support for third-party applications Marketplace extensions REST APIs Related articles TCM commands witadmin (work item tracking) TFSConfig TFSDeleteProject TFSSecurity TFSServiceControl The following tools provide support for monitoring and interacting with Azure DevOps from a third-party application. Azure Boards: Use the Azure Boards app with Slack to manage work items Use the Azure Boards app in Microsoft Teams Azure Repos: Azure Repos with Slack Azure Repos with Microsoft Teams Azure Pipelines: Use Azure Pipelines with Microsoft Teams Azure Pipelines with Slack Integrate with ServiceNow change management Continuously deploy from a Jenkins build Visual Studio and Azure DevOps provide a wealth of features and functionality. They also provide a means to extend and share that functionality. Extensions are simple add-ons that you can use to customize and extend your DevOps and work tracking experiences. They're written with standard technologies—HTML, JavaScript, and CSS. You can develop your own extensions by using your preferred dev tools. You build extensions by using our RESTful API library. Publish your extensions to the Azure DevOps Marketplace. You can privately maintain or share them with millions of developers who use Visual Studio and Azure DevOps. To learn more, visit the Azure DevOps Marketplace and see Overview of extensions. The Azure DevOps APIs are based on REST, OAuth, JSON, and service hooks—all standard web technologies broadly supported in the industry. REST APIs are provided to support building extensions to Azure DevOps. To learn more, see REST API overview. A tour of services Software development roles Pricing Azure DevOps data protection overview
- 202. Software development roles supported by Azure DevOps 6/9/2022 • 4 minutes to read • Edit Online Contributor roles Software developers Product owners Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 If you're a sole developer or work in a small setting, you track issues, plan features, code, test, build, and deploy. If you work in a large setting, you might be more focused on a specific set of tasks that aligns with specific roles. These specific roles could be software development, product and scrum management, or DevOps. The following article describes the features and tasks available to you, based on your role. Team members are contributors who have access to the following areas and more: code base work item tracking Agile tools build pipelines test tools If you need to lock down specific areas to a select set of contributors, see permission management. Developers use Visual Studio or other tools to develop their applications. They then check in their changes to a Git or Team Foundation Version Control (TFVC) repository hosted in Azure DevOps. From the web portal or a supported IDE, they can view repositories, check history, and more. To get started with using Git, see one of the following resources: Share your code with Git and Visual Studio Share your code in Git by using Eclipse Share your code in Git by using Xcode Share your code in Git by using IntelliJ Get started with using Git and Azure DevOps Services To get started with using TFVC, see one of the following resources: Develop and share your code in TFVC by using Visual Studio Share your code in TFVC by using Eclipse Share your code in TFVC by using Xcode Product owners typically plan the feature set to deliver, set priorities, and track the status of work, code defects, and customer issues. The suite of web-based Agile tools in Azure DevOps provides product owners with the views and features that they need to do these tasks. All work gets captured within a work item. Each work item represents a specific type such as a user story, task, or bug. Use the product backlog to quickly define and prioritize user stories, features, and other work items
- 203. Scrum masters DevOps: builders, testers, and release managers Stakeholders Administrator roles Team administrators Use the sprint backlog and task board to implement Scrum practices Use the Kanban board to work with Kanban methods Use queries to list and update work items, create status and trend charts, and post charts to dashboards Use dashboards to share information, status, and trends with your team or organization For more information about getting started, see About Azure Boards and Agile tools. You can integrate Microsoft Excel with Azure DevOps to plan and track your work. For more information, see Bulk modify by using Excel. Scrum masters help to facilitate scrum to the larger team by ensuring the scrum framework gets followed. They're committed to the practices, but stay flexible and open to opportunities for the team to improve their workflow. Scrum masters utilize the same features as product owners. An advantage of working with Azure DevOps is the suite of tools and integrated functionality that support build, testing, and deploying software applications. See the following general DevOps-associated tasks that Azure DevOps supports. Define builds Unit test your code Run tests with your builds Perform exploratory tests Define, manage, track, and approve releases Deploy applications to Azure, a virtual machine, Docker containers, and more To get started, see the overviews in Azure Pipelines and Azure Test Plans. With Stakeholder access, anyone in your organization can check project status and provide feedback. Stakeholders can track project priorities and provide direction, feature ideas, and business alignment to a team. Stakeholders also contribute to plans by adding and modifying work items. They can't, however, contribute to the code base or exercise test tools. Stakeholder access essentially provides free access to a limited set of feature to project sponsors and supporters. To learn more, see Work as a Stakeholder. A distinct advantage to working in Azure DevOps Services is the reduced overhead of server maintenance. But there are several administrative tasks required to support a collaborative, integrated software development environment. The main tasks are grouped as follows by membership in a security group or role. Responsible for configuring team settings, which include: Backlog and board settings Team areas and iterations (sprints) Team members Team dashboards Team work item templates
- 204. Project administrators Organization Owners and Project Collection Administrators Project Collection Administrators Azure DevOps Server administrators Related articles Team alerts To get started, see Manage teams and configure team tools. Responsible for configuring project-level resources, including: Area paths and iteration paths Project permissions and repository security Build agents, pools, and service connections Test and release retention policies Area paths and iteration paths Project permissions and repository security Customizing work tracking objects Build agents, pools, and service connections Test and release retention policies Responsible for configuring organization-level resources, including the following tasks: Manage billing Add and manage projects Manage collection-level permissions Customize work tracking processes Install and manage extensions To get started, see Manage organizations and Settings. Responsible for configuring collection-level resources. These tasks include: Add and manage projects Manage collection-level permissions Install and manage extensions To get started, see Settings. Responsible for installing, upgrading, and maintaining an on-premises Azure DevOps Server deployment, including the: Install Azure DevOps Server Update servers running Azure DevOps Server Manage database backups Manage server administrative settings and permissions Build retention policies Add and manage project collections To get started, see Server Administration (Azure DevOps Server). A tour of services
- 205. Plan your organizational structure in Azure DevOps
- 206. Troubleshoot connecting to a project 6/9/2022 • 5 minutes to read • Edit Online Troubleshoot connectivity Troubleshoot signing in Scenario 1 Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 As a first step in resolving connectivity issues with Azure DevOps, complete the following steps: 1. Sign out of your browser. To do so, select the Visual Studio sign out link. 2. Delete the cookies in your browser. To delete cookies in most browsers, select Ctrl+Shift+Del. 3. Open Internet Explorer and delete the browser cookies. The Visual Studio IDE uses Internet Explorer cookies. 4. Close all browsers and close the Visual Studio IDE. 5. Use a private browser session to retry the connection. If the issue is with the Visual Studio IDE, remove the connection, and then readd it. Two types of identities can sign in: Microsoft accounts and Azure Active Directory (Azure AD) accounts. Depending on your account, you might experience one of the following errors. 401 - Not Authorized The most common error page is the 401 Not Authorized error, which occurs when your identity doesn't have permissions to enter an organization. See the following common reasons for the error: Your identity isn't a member of the organization. Your identity has an invalid or missing license assignment. Your identity doesn't have enough memberships to access the resource. For example, membership to the Reader/Contributors group. Your identity is a B2B guest in the tenant, and the invitation hasn't been accepted. If you think you're a member of the organization, but are blocked by this error page, contact Support. Your work or school Azure AD account doesn't have access, but your personal Microsoft account does. 401 - Work or school, or Personal account
- 207. Mitigation TIP Scenario 2 Mitigation A highly specific 401 error case. In this case, both a personal Microsoft account and a work or school account (Azure AD) that have the same sign-in address exist. You've signed in with your work or school account, but your personal account is the identity with access to the organization. In some cases, you might not know you have two identities with the same sign-in address. The work or school Azure AD account might have been created by an administrator when you were added to Office365 or Azure AD. To sign out of your current work or school Azure AD account, select Sign in with your personal MSA account, and then sign in by using your personal Microsoft account. After authentication, you should have access to the organization. If you can´t access to the organization, make sure that your Azure Active Directory still exists and that your work or school account is in the Azure AD tenant. To avoid seeing this prompt, you can rename your Microsoft account. Then, only one identity, your work or school account, or Azure AD account, uses your sign-in address. Your personal Microsoft account doesn't have access, but your Azure AD account does. This scenario is an opposite version of the 401 error page. In this case, the personal account (Microsoft account identity) doesn't have access to the organization and the work or school account (Azure AD identity) does. The same guidance from Scenario 1 applies, but in reverse. 401 - Work or school, or Personal account When you get redirected back to the original sign-in page, we recommend that you clear all cookies, and then reattempt to sign in. If that doesn't fix the issue, contact Support.
- 208. Troubleshoot Azure DevOps Server connectivity Switch organizations Connect to Azure DevOps Server with Secure Sockets Layer Clear the cache on client computers Here's a list of the most frequently reported connection problems and what to do about them. Complete the list in the order indicated. 1. Verify that you have the required permissions. If the errors that you receive indicate read-only or blocked actions, you might not have permissions to act on the data. 2. Verify that your computer is connected to the network and that it can access network resources. 3. Verify that Azure DevOps Server hasn't been taken offline. Talk with your Azure DevOps Server administrator. 4. Check whether your project has been moved to another project collection in Azure DevOps Server. If it has been moved, you must create a connection to the new server name. For additional troubleshooting tips, see TF31002: Unable to connect to this Azure DevOps Server. When you use two or more organizations that are linked to Azure AD, the sign-out function might not work as expected. For example, you can't switch between different organizations to connect to multiple organizations that are linked to directory tenants. When this problem occurs, a blank screen flashes several times. Then, one of the following error messages appears after you connect to or add a new connection in the Connect to Azure DevOps Server dialog box: TF31003: Either you have not entered the necessary credentials, or your user account does not have permission to connect to the Azure DevOps Server TF31002: Unable to connect to this Azure DevOps Server To resolve this issue, apply Visual Studio 2013.2 or install a later version from the Visual Studio download website. Another solution is to delete your browser cookies. For more information, see the support article You can't switch between different organizations in Visual Studio Codespaces. If you connect to an Azure DevOps Server instance that has Secure Sockets Layer (SSL) configured, install a certificate and clear the client cache. For details, see Set up HTTPS with Secure Sockets Layer (SSL) for Azure DevOps Server - Configuring client computers. When the on-premises Azure DevOps Server configuration changes, such as when you move or split a project collection, clear the cache. 1. Sign in to your client computer for Azure DevOps Server by using the credentials of the user whose cache you want to clear. 2. Close any open instances of Visual Studio. 3. Open a browser and go to one of the following folders, depending on the operating system your computer runs on:
- 209. Windows 10 Drive:Users<i>UserNameAppDataLocalMicrosoftTeam Foundation6.0Cache Windows 8 Drive:Users<i>UserNameAppDataLocalMicrosoftTeam Foundation4.0Cache Windows 7 or Windows Vista Drive:Users<i>UserNameAppDataLocalMicrosoftTeam Foundation2.0Cache 4. Delete the contents of the Cache directory, including all subfolders.
- 210. TF31002: Unable to connect 6/9/2022 • 5 minutes to read • Edit Online You receive this error when you try to connect to Azure DevOps Services PROBLEM RESOLUTION You don't have an active account or license. Check with your administrator that you're a member of the account and have an active, valid license. See Assign licenses to users for details. Your Azure DevOps Services organization is connected to the Azure Active Directory. When your Azure DevOps Services organization is connected to a directory that is associated with a Microsoft 365 or Microsoft Azure subscription, only members in the directory can access the account. Check with your directory administrator to have them create an organizational account for you or add your account to the directory as external member. You can't switch between different organizational accounts. If you work with several organizations that connect to different directories, such as accounts created from the Microsoft Azure Portal, the sign-out function might not work as expected. For example, you can't switch between different organizational accounts to connect to multiple accounts that are linked to directory tenants. When this problem occurs, you see a flashing blank sign in dialog box several times. Then, you receive either TF31002 or TF31003 error after you connect to or add a new connection in "Connect to Team Foundation Server" dialog box. To resolve this problem, apply the most recent Visual Studio update . To learn more, see You can't switch between different organizational accounts in Visual Studio Online. You want to sign in to Azure DevOps Services from Visual Studio using different credentials. See Connect to projects, Sign in with different credentials. When you try to connect to an on-premises Azure DevOps Server from your client computer Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 You might receive this error when you try to connect to Azure DevOps Services or an on-premises Azure DevOps Server from Visual Studio. If you determine that you're receiving this error from one computer but not others, or others aren't receiving this error, then check the problem resolutions that are outlined below.
- 211. PROBLEM RESOLUTION Your password has expired. Verify that you entered your user ID and password correctly, and that your password hasn't expired. You've entered an incorrect server URL. Verify that you've entered the server URL correctly including the server name, port number, and protocol (http/https). See Connect to projects to learn more. The TFS configuration has changed. If the configuration for the on-premises Azure DevOps Server has changed, you must create a new connection. You might also need to clear the client cache. You work remotely and need to connect to a TFS Proxy server to check in files to Team Foundation version control. Configure Visual Studio to connect to TFS Proxy. You're connecting to a later version of TFS than your Visual Studio client version. Your version of Visual Studio or Team Explorer might be incompatible with Team Foundation Server. You might need to install one or more GDR packs. See Requirements and compatibility for details. Your firewall is blocking TFS services. See Allow a program to communicate through Windows Firewall. Visual Studio stops responding when you run a query in Visual Studio. Your computer might be configured to bypass the proxy server. Verify the configuration of the BypassProxyOnLocal setting on your computer. For more information, see BypassProxyOnLocal Configuration. Several users can't connect to an on-premises Azure DevOps Server PROBLEM RESOLUTION The TFSService account password has expired or is incorrect. Many services for Team Foundation Server will stop running when the service account for Team Foundation has expired. For more information, see Change the service account or password for Team Foundation Server. The application-tier server for Team Foundation is unavailable. Verify whether each required service is running. If a required service isn't running, you must restart it. If necessary, set it to start automatically. For more information, see Stop and start services, application pools, and websites. The network is unavailable. Verify whether your network is operational. A website identity for Team Foundation is configured incorrectly. Verify or correct the server binding assignments that are made to websites for Team Foundation. If the problem occurs on more than one computer, contact your administrator to confirm whether the server is operational and available on the network. As an administrator, check the event logs for the application-tier server to try to pinpoint the problem. Also, you can use the following table to determine whether the server is misconfigured. In the table, problems that are more likely to occur appear first. Try the resolutions in the order in which they appear, which increases the chance that you can solve the problem quickly.
- 212. Access to a website for Team Foundation has been restricted. Verify or correct restrictions that are made to those websites that are based on IP addresses and domain names. The firewall or ports are configured incorrectly. Verify or correct port binding assignments for websites and port assignments for the firewall. First, you should open the administration console for Team Foundation, display the Application Tier page, and review the URL assignments. If necessary, you can click Change URL to modify the URL of a website. Next, you should verify the port assignments for Internet Information Services (IIS) and the ports that are allowed through the firewall. For more information, see Review Server Status and Settings and Verify or Correct Port Assignments. Trust relationships between domains aren't configured correctly. If a group of users can't access Team Foundation Server, you might have trust issues between domains. When users connect to different versions of TFS from Visual Studio, for example, they connect to TFS 2012 and then TFS 2008, they can get the TF31002 error. This error can occur because the GUIDs for the TFS 2012 collection are the same as TFS 2008. The local client cache gets confused because it tries to maintain the same GUID- based local cache for both the 2008 server and the new Project Collection in 2012. To fix, run the TFSConfig ChangeServerID command. See TFSConfig ChangeServerID command. PROBLEM RESOLUTION
- 213. Troubleshoot access and permission issues 6/9/2022 • 10 minutes to read • Edit Online TIP Common access and permission issues ISSUE TROUBLESHOOTING ACTION Their access level doesn’t support access to the service or feature. To discover if this is the cause, you want to determine the user's access level and subscription status. Their membership within a security group doesn’t support access to a feature or they have been explicitly denied permission to a feature. To discover if this is the cause, trace a permission. The user has been recently granted permission, however a refresh is required for their client to recognize the changes. Have the user refresh or re-evaluate their permissions. The user's trying to exercise a feature granted only to a team administrator for a specific team, however they haven’t been granted that role. To add them to the role, see Add, remove team administrator. The user hasn’t enabled a preview feature. Have the user open the Preview features and determine the on/off status for the specific feature. For more information, see Manage preview features. Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Azure DevOps security and permission structure is extensive, so you may find yourself needing to investigate why you or a project member doesn’t have the access to a project, service, or feature that they expect to have. Find step-by-step guidance to understand and address problems a project member may be having in connecting to a project or accessing an Azure DevOps service or feature. Before using this guide, we recommend that you're familiar with the following content: Get started with permissions, access, and security groups Default permissions and access quick reference. Quick reference index to Azure DevOps security When you're creating an Azure DevOps security group, label it in a way that is easy to discern if it's created to limit access. Permissions get set at one of the following levels: object level project level organization or project collection level security role team administrator role See the following most common reasons a project member can’t access a project, service, or feature:
- 214. Project member has been added to a limited scope security group, such as the Project-Scoped Users group. To discover if this is a cause, look up the user’s security group memberships. ISSUE TROUBLESHOOTING ACTION Less common access and permission issues ISSUE TROUBLESHOOTING ACTION A project administrator disabled a service. In this case, no one has access to the disabled service. To determine whether a service is disabled, see Turn an Azure DevOps service on or off. A Project Collection Administrator disabled a preview feature, which disables it for all project members in the organization. See Manage preview features. Group rules governing the user’s access level or project membership are restricting access. See Determine a user's access level and subscription status. Custom rules have been defined to a work item type’s workflow. see Rules applied to a work item type that restrict select operation. Determine a user's access level and subscription status REASON FOR LOSS OF ACCESS TROUBLESHOOTING ACTION The user's Visual Studio subscription has expired. Meanwhile, this user can work as a Stakeholder, or you can give the user Basic access until the user renews their subscription. After the user signs in, Azure DevOps restores access automatically. The Azure subscription used for billing is no longer active. All purchases made with this subscription are affected, including Visual Studio subscriptions. To fix this issue, visit the Azure account portal. The Azure subscription used for billing was removed from your organization. Learn more about linking your organization Less common reasons for limited access are when one of the following events has occurred: You can assign users or groups of users to one of the following access levels: Stakeholder Basic Basic + Test Plans Visual Studio subscription For more information about access level restriction in Azure DevOps, see Supported access levels. To use Azure DevOps features, users must be added to a security group with the appropriate permissions. Users also need access to the web portal. Limitations to select features get based on the access level and security group to which a user is assigned. Users can lose access for the following reasons: Otherwise, on the first day of the calendar month, users who haven't signed in to your organization for the
- 215. Trace a permission longest time lose access first. If your organization has users who don't need access anymore, remove them from your organization. For more information about permissions, see Permissions and groups and the Permissions lookup guide. Use permission tracing to determine why a user's permissions aren't allowing them access to a specific feature or function. Learn how a user or an administrator can investigate the inheritance of permissions. To trace a permission from the web portal, open the permission or security page for the corresponding level. For more information, see Request an increase in permission levels. If a user's having permissions issues and you use default security groups or custom groups for permissions, you can investigate where those permissions are coming from by using our permissions tracing. Permissions issues could be because of delayed changes. It can take up to 1 hour for Azure AD group memberships or permissions changes to propagate throughout Azure DevOps. If a user's having issues that don't resolve immediately, wait a day to see if they resolve. For more information about user and access management, see Manage users and access in Azure DevOps. If a user's having permissions issues and you use default security groups or custom groups for permissions, you can investigate where those permissions are coming from by using our permissions tracing. Permissions issues could be because the user doesn't have the necessary access level. Users can receive their effective permissions either directly or via groups. Complete the following steps so administrators can understand where exactly those permissions are coming from and adjust them, as needed. 1. Select Project settings > Permissions > Users, and then select the user.
- 216. You should now have a user-specific view that shows what permissions they have. 2. To trace why a user does or doesn't have any of the listed permissions, select the information icon next to the permission in question.
- 217. The resulting trace lets you know how they're inheriting the listed permission. You can then adjust the user's permissions by adjusting the permissions that are provided to the groups that they're in. 1. Select Project settings > Security, and then enter the user name into the filter box.
- 218. You should now have a user-specific view that shows what permissions they have. 2. Trace why a user does or doesn't have any of the listed permissions. Hover over the permission, and then choose Why.
- 219. The resulting trace lets you know how they're inheriting the listed permission. You can then adjust the user's permissions by adjusting the permissions that are provided to the groups they're in.
- 220. 1. Go to the Security page for the project that the user is having access problems. 2. Enter their name into the box in the upper left-hand corner. You should have a user-specific view that shows what permissions they have. 3. Trace why a user does or doesn't have any of the listed permissions. Hover over the permission, and then choose Why.
- 221. Refresh or reevaluate permissions Problem Solution The resulting trace lets you know how they're inheriting the listed permission. You can then adjust the user's permissions by adjusting those permissions provided to the groups they're in. For more information, see Grant or restrict access to select features and functions or Request an increase in permission levels. See the following scenario where refreshing or reevaluating permissions may be necessary. Users get added to an Azure DevOps or Azure AD group. This action grants inherited access to an organization or project. But, they don't get access immediately. Users must either wait or sign out, close their browser, and then sign back in to get their permissions refreshed. Users get added to an Azure DevOps group. This action grants inherited access to an organization or project. But, they don't get access immediately. Users must either wait or sign out, close their browser, and then sign back in to get their permissions refreshed. Within User settings, on the Permissions page, you can select Reevaluate permissions. This function reevaluates your group memberships and permissions, and then any recent changes take effect immediately.
- 222. Rules applied to a work item type that restrict select operations Hide organization settings from users View, add, and manage permissions with CLI Use tools to fix permission Before you customize a process, we recommend that you review Configure and customize Azure Boards, which provides guidance on how to customize Azure Boards to meet your business needs. For more information about work item type rules that apply toward restricting operations, see: Apply rules to workflow states (Inheritance process) Sample rule scenarios Define area paths and assign to a team If a user's limited to seeing only their projects, or from seeing the organization settings, the following information may explain why. To restrict users from accessing organization settings, you can enable the Limit user visibility and collaboration to specific projects preview feature. Examples of restricted users include Stakeholders, Azure Active Directory (Azure AD) guest users, or members of a security group. Once enabled, any user or group added to the Project-Scoped Users group gets restricted from accessing the Organization Settings pages, except for Overview and Projects. They're restricted to accessing only those projects to which they've been added. Examples of restricted users include Stakeholders, or members of a security group. Once enabled, any user or group added to the Project-Scoped Users group gets restricted from accessing the Organization Settings pages, except for Overview and Projects. They're restricted to accessing only those projects to which they've been added. For more information about hiding organization settings from users, see Manage your organization, Limit user visibility for projects and more. You can view, add, and manage permissions at a more granular level with the az devops security permission commands. For more information, see Manage permissions with command line tool. You can use the following tools to fix a user's permission issue. TFSSecurity.exe - TFSSecurity is a command-line tool that can be used to view and update and delete permissions or groups. Example usage:
- 223. Group rules with lesser permissions Example 1: Group rule gives me more access Example 2: Group rule gives me the same access Work with GitHub Problem Solution Other areas where permissions might be applied tfssecurity /a+ Identity "81e4e4b5-bde0-4f2c-a7a5-4d25c2e8a81f" Read "Project Collection Valid Users" ALLOW /collection:{collectionUrl} tfssecurity /a- Identity "3c7a0a47-27b4-4def-8d42-aab9b405fc8a" Write n:"[Project1]Contributors" DENY /collection:{collectionUrl} Use the public sproc Example usage: Use prc_pSetAccessControlEntry or prc_pRemoveAccessControlEntries to add or remove ACEs directly from the security tables if TFSSecurity doesn't work for you. For more information, see Use TFSSecurity to manage groups and permissions for Azure DevOps. Group rule types get ranked in the following order: Subscriber > Basic + Test Plans > Basic > Stakeholder. Users always get the best access level between all the group rules, including Visual Studio (VS) subscription. See the following examples, showing how subscriber detection factors into group rules. If I have a VS Pro subscription and I'm in a group rule that gives me Basic + Test Plans – what happens? Expected: I get Basic + Test Plans because what the group rule gives me is greater than my subscription. Group rule assignment always provides the greater access, rather than limiting access. I have a Visual Studio Test Pro subscription and I'm in a group rule that gives me Basic + Test Plans – what happens? Expected: I get detected as a Visual Studio Test Pro subscriber, because the access is the same as the group rule. I'm already paying for the Visual Studio Test Pro, so I don't want to pay again. See the following troubleshooting information for when you're trying to deploy code in Azure DevOps with GitHub. You can't bring the rest of your team into the organization and project, despite adding them as organization and project members. They receive emails but when signing in they receive an error 401. You're likely signed into Azure DevOps with an incorrect identity. Complete the following steps. 1. Close all browsers, including browsers that aren't running Azure DevOps. 2. Open a private or incognito browsing session. 3. Go to the following URL: https://aka.ms/vssignout. A message displays that says, "Sign out in progress." After you sign out, you're redirected to dev.azure.microsoft.com. 4. Sign in to Azure DevOps again. Select your other identity. Area path permissions
- 224. Related articles Work item tags Moved work items out of a project Deleted work items Quick guide to default permissions and access for Azure Boards Custom rules Sample custom rule scenarios Custom backlogs and boards Custom controls Manage permissions with the command line tool Change individual or group permissions Security best practices Security and permission management tools Add users to an administrator role
- 225. Allowed IP addresses and domain URLs 6/9/2022 • 6 minutes to read • Edit Online TIP Domain URLs to allow Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 If your organization's secured with a firewall or proxy server, you must add certain internet protocol (IP) addresses and domain uniform resource locators (URLs) to the allowlist. Adding these IPs and URLs to the allowlist helps to ensure that you have the best experience with Azure DevOps. You know that you need to update your allowlist if you can't access Azure DevOps on your network. See the following sections in this article: Domain URLs to allow IP addresses and range restrictions So that Visual Studio and Azure Services work well with no network issues, you should open select ports and protocols. For more information, see Install and use Visual Studio behind a firewall or proxy server, Use Visual Studio and Azure Services. Network connection issues could occur because of your security appliances, which may be blocking connections - Visual Studio uses TLS 1.2 and above. When you're using NuGet or connecting from Visual Studio 2015 and later, update the security appliances to support TLS 1.2 and above for the following connections. To ensure your organization works with any existing firewall or IP restrictions, ensure that dev.azure.com and *.dev.azure.com are open. The following section includes the most common domain URLs to support sign in and licensing connections.
- 226. https://*.dev.azure.com https://*.vsassets.io https://*gallerycdn.vsassets.io https://*vstmrblob.vsassets.io https://aadcdn.msauth.net https://aadcdn.msftauth.net https://aex.dev.azure.com https://aexprodea1.vsaex.visualstudio.com https://amcdn.msftauth.net https://amp.azure.net https://app.vssps.dev.azure.com https://app.vssps.visualstudio.com https://*.vsblob.visualstudio.com https://*.vssps.visualstudio.com https://*.vstmr.visualstudio.com https://azure.microsoft.com https://azurecomcdn.azureedge.net https://cdn.vsassets.io https://dev.azure.com https://go.microsoft.com https://graph.microsoft.com https://live.com https://login.live.com https://login.microsoftonline.com https://management.azure.com https://management.core.windows.net https://microsoft.com https://microsoftonline.com https://static2.sharepointonline.com https://visualstudio.com https://vsrm.dev.azure.com https://vstsagentpackage.azureedge.net https://*windows.net https://login.microsoftonline.com https://app.vssps.visualstudio.com https://{organization_name}.visualstudio.com https://{organization_name}.vsrm.visualstudio.com https://{organization_name}.vstmr.visualstudio.com https://{organization_name}.pkgs.visualstudio.com https://{organization_name}.vssps.visualstudio.com Various domain URL descriptions NOTE https://*.vsassetscdn.azure.cn https://*.gallerycdn.azure.cn More domain URLs Azure Artifacts We recommend you open port 443 to all traffic on these IP addresses and domains. We also recommend you open port 22 to a smaller subset of targeted IP addresses. Azure DevOps uses Content Delivery Networks (CDNs) to serve static content. Users in China should also add the following domain URLs to an allowlist: Ensure the following domain URLs are allowed for Azure Artifacts:
- 227. https://*.blob.core.windows.net https://*.visualstudio.com NuGet connections https://azurewebsites.net https://nuget.org NOTE SSH connections ssh.dev.azure.com vs-ssh.visualstudio.com Azure Pipelines Microsoft-hosted agents Azure Pipelines Self-hosted agents IP addresses and range restrictions Outbound connections Also allow all IP addresses in the "name": "Storage.{region}" section of the following file (updated weekly): Azure IP ranges and Service Tags - Public Cloud. {region} is the same Azure Geography as your organization. Ensure the following domain URLs are allowed for NuGet connections: Privately owned NuGet server URLs might not be included in the previous list. You can check the NuGet servers you're using by opening %APPData%NugetNuGet.Config . If you need to connect to Git repositories on Azure DevOps with SSH, allow requests to port 22 for the following hosts: Also allow IP addresses in the "name": "AzureDevOps" section of this downloadable file (updated weekly) named: Azure IP ranges and Service Tags - Public Cloud If you use Microsoft-hosted agent to run your jobs and you need the information about what IP addresses are used, see Microsoft-hosted agents IP ranges. See all Azure virtual machine scale set agents. For more information about hosted Windows, Linux and macOS agents, see Microsoft-hosted agent IP ranges. If you're running a firewall and your code is in Azure Repos, see Self-hosted Linux agents FAQs, Self-hosted macOS agents FAQs or Self-hosted Windows agents FAQs. This article has information about which domain URLs and IP addresses your private agent needs to communicate with. Outbound connections originate from inside your organization and that target Azure DevOps or other dependent sites. Examples of such connections include: Browsers connecting to Azure DevOps website as users go to and use features of Azure DevOps Azure Pipelines agents installed on your organization's network connecting to Azure DevOps to poll for pending jobs CI events sent from a source code repository that's hosted within your organization's network to Azure DevOps Ensure the following IP addresses are allowed for outbound connection, so your organization works with any
- 228. 13.107.6.0/24 13.107.9.0/24 13.107.42.0/24 13.107.43.0/24 NOTE Inbound connections REGION IP V4 RANGES Australia East 20.37.194.0/24 Australia South East 20.42.226.0/24 Brazil South 191.235.226.0/24 Central Canada 52.228.82.0/24 Asia Pacific (Singapore) 20.195.68.0/24 South India 20.41.194.0/24 Central United States 20.37.158.0/23 West Central United States 52.150.138.0/24 East United States 20.42.5.0/24 existing firewall or IP restrictions. The endpoint data in the following chart lists requirements for connectivity from a machine in your organization to Azure DevOps Services. IP V4 ranges IP V6 ranges If you're currently allowing the 13.107.6.183 and 13.107.9.183 IP addresses, leave them in place, as you don't need to remove them. Azure Service Tags aren't supported for outbound connection. Inbound connections originate from Azure DevOps and target resources within your organization's network. Examples of such connections include: Azure DevOps Services connecting to endpoints for Service Hooks Azure DevOps Services connecting to customer-controlled SQL Azure VMs for Data Import Azure Pipelines connecting to on-premises source code repositories such as GitHub Enterprise or Bitbucket Server Azure DevOps Services Audit Streaming connecting to on-premises or cloud-based Splunk Ensure the following IP addresses are allowed for inbound connection, so your organization works with any existing firewall or IP restrictions. The endpoint data in the following chart lists requirements for connectivity from Azure DevOps Services to your on-premises or other cloud services.
- 229. East 2 United States 20.41.6.0/23 North United States 40.80.187.0/24 South United States 40.119.10.0/24 West United States 40.82.252.0/24 West 2 United States 20.42.134.0/23 Western Europe 40.74.28.0/23 United Kingdom South 51.104.26.0/24 REGION IP V4 RANGES NOTE Other IP addresses 40.82.190.38 52.108.0.0/14 52.237.19.6 52.238.106.116/32 52.244.37.168/32 52.244.203.72/32 52.244.207.172/32 52.244.223.198/32 52.247.150.191/32 Azure DevOps ExpressRoute connections Azure Service Tags are supported for inbound connection. Instead of allowing the previously listed IP ranges, you may use the AzureDevOps service tag for Azure Firewall and Network Security Group (NSG) or on- premises firewall via a JSON file download. The Service Tag or previously mentioned inbound IP addresses don't apply to Microsoft Hosted agents. Customers are still required to allow the entire geography for the Microsoft Hosted agents. If allowing the entire geography is a concern, we recommend using the Azure Virtual Machine Scale Set agents. The Scale Set agents are a form of self-hosted agents that can be auto-scaled to meet your demands. Hosted macOS agents are hosted in GitHub's macOS cloud. IP ranges can be retrieved using the GitHub metadata API using the instructions provided here. Most of the following IP addresses pertain to Microsoft 365 Common and Office Online. For more information, see Worldwide endpoints and Adding IP address rules. If your organization uses ExpressRoute, ensure the following IP addresses are allowed for both outbound and inbound connections. IP V4 ranges IP V6 ranges
- 230. 13.107.6.175/32 13.107.6.176/32 13.107.6.183/32 13.107.9.175/32 13.107.9.176/32 13.107.9.183/32 13.107.42.18/32 13.107.42.19/32 13.107.42.20/32 13.107.43.18/32 13.107.43.19/32 13.107.43.20/32 Azure DevOps import service Related articles For more information about Azure DevOps and ExpressRoute, see ExpressRoute for Azure DevOps. During the import process, we highly recommend that you restrict access to your virtual machine (VM) to only IP addresses from Azure DevOps. To restrict access, allow only connections from the set of Azure DevOps IP addresses, which were involved in the collection database import process. For information about identifying the correct IP addresses, see (Optional) Restrict access to Azure DevOps Services IPs only. Available service tags Microsoft-hosted agents IP address ranges Self-hosted Windows agents FAQs Configure Azure Storage firewalls and virtual networks Install and use Visual Studio behind a firewall or proxy server
- 231. Get support and provide feedback 6/9/2022 • 4 minutes to read • Edit Online Get live help Documentation feedback Tips for effective feedback Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Share your feedback and ideas with us, or join our communities. We're always working to improve Azure DevOps, and we want you to be part of the process! Do you need to do any of the following? Get advice Visit StackOverflow for Azure DevOps Services or Azure DevOps Server. Report a bug Submit it through our Developer Community for Azure DevOps Services or Azure DevOps Server. Suggest a feature or a fix Submit your idea or issue through our Developer Community for Azure DevOps Services or Azure DevOps Server. Find out what's new in Azure DevOps Check out the current Azure DevOps Release Notes. These notes are updated every three weeks. Chat with our virtual support agent Get help with common issues, troubleshooting steps, or create a request to change the region your Azure DevOps instance is hosted in using our virtual support agent. We offer a live chat (English only) support option. Choose from Technical Support, Sales Support, Visual Studio (For your Company), and Account, Subscription, and Billing Support. Select your country from the dropdown menu, and then select Live Chat (English). All docs on docs.microsoft.com have a ratings tool in the lower right-hand corner of the page. It asks "Is this content helpful?" Answer Yes or No depending on your experience. Add more detailed feedback by selecting the Tell us more link after selecting Yes or No. Check an appropriate box and enter what we can do to improve the content for you! Although we can't reply back, we collect and review this feedback regularly, and use your sentiments in our content planning. If you just want to vent about the product or the docs, that's okay. It helps us a lot to know when you're happy or unhappy with an experience. For the most impact, though, provide details so we can better understand what we're doing right or wrong. Provide a little context. What problem were you trying to solve? At what point did it go wrong? What's your role? We don't need personal or professional details. Are you a dev? A manager? A business owner? When we understand our audience, we can come up with better solutions for you and other customers doing similar work. What version of the product were you using? What other products were you using with it? The best feedback we get is clear and precise. For example: Product feedback: "I'm a project manager for a small start-up. I'm using Azure DevOps. I'm trying to create work item templates through the UI, but my changes don't seem to persist. It's not clear what I'm doing
- 232. What platform/version am I using? Azure DevOps Services Azure DevOps Server https://ServerName:8080/tfs/_home/About ON-PREMISES RELEASE UPDATE VERSION NUMBER 18.181.31202.1 Azure DevOps Server 2020 2020.1 18.181.31230.2 wrong." Doc feedback: "I'm a dev in a large organization that works on Java apps. I tried to use Maven with your build system in Azure DevOps Server 2017 Update 1 (15.112.26307.0), but I couldn't get the configuration shown in the docs to work." The more details, the better! You can tell what platform you use from the URL you use to connect to Azure DevOps Services or Azure DevOps Server. An Azure DevOps URL consists of an organization name and dev.azure.com, for example: https://dev.azure.com/{yourorganization} . To learn the version number, enter the following address in a web browser: https://dev.azure.com/{yourorganization}/_home/About A page similar to the following example opens showing the version number. An on-premises URL consists of a server name, port number, and collection name, for example: https://ServerName:8080/tfs/CollectionName To learn the version number, enter the following address in a web browser: A page similar to the following example opens showing the version number.
- 233. 2020.0.1 Patch 3 18.170.31228.1 2020.0.1 Patch 2 18.170.31123.3 RTW 18.170.30830.2 RC2 18.170.30331.4 RC1 18.170.30308.2 Azure DevOps Server 2019 2019.1 17.153.29522.3 RTW 17.143.28511.3 Azure DevOps Server 2018 2018.3 16.131.28106.2 2018.2 16.131.27701.1 2018.1 16.122.27409.2 RTW 16.122.27102.1 RC2 16.122.26918.3 RC1 16.121.26818.0 Azure DevOps Server 2017 Update 3 15.117.27024.0 Update 3 RC 15.117.26912.0 Update 2 15.117.26714.0 Update 1 15.112.26307.0 RTW 15.105.25910.0 RC1 15.103.25603.0 Azure DevOps Server 2015 Update 3 14.102.25423.0 Update 2.1 14.95.25229.0 Update 2 14.95.25122.0 Update 2 RC 2 14.95.25029.0 Update 2 RC 1 14.95.25005.0 ON-PREMISES RELEASE UPDATE VERSION NUMBER 18.181.31202.1
- 234. Update 1 14.0.24712.0 Update 1 RC 2 14.0.24626.0 Update 1 RC 1 14.0.24606.0 RTM 14.0.23128.0 RC2 14.0.23102.0 RC 14.0.22824.0 CTP 14.0.22604.0 Azure DevOps Server 2013 Update 5 12.0.40629.0 Update 4 12.0.31101.0 Update 4 RC 12.0.31010.0 Update 3 12.0.30723.0 Update 3 RC 12.0.30626.0 Update 2 12.0.30324.0 RTM 12.0.21005.1 RC 12.0.20827.3 Azure DevOps Server 2012 Update 4 11.0.61030.0 Update 3 11.0.60610.1 Update 2 11.0.60315.1 CU 1 11.0.60123.100 Update 1 11.0.51106.1 RTM 11.0.50727.1 Azure DevOps Server 2010 CU 2 10.0.40219.371 SP1 10.0.40219.1 RTM 10.0.30319.1 ON-PREMISES RELEASE UPDATE VERSION NUMBER 18.181.31202.1
- 235. Azure DevOps Server 2008 SP1 9.0.30729.1 RTM 9.0.21022.8 Azure DevOps Server 2005 SP1 8.0.50727.762 RTM 8.0.50727.147 ON-PREMISES RELEASE UPDATE VERSION NUMBER 18.181.31202.1 Related articles Azure DevOps features timeline Report a problem with Visual Studio
- 236. Navigate in Visual Studio Team Explorer 6/9/2022 • 7 minutes to read • Edit Online TIP Prerequisites Connect to a project or repository TIP Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 You use Team Explorer to coordinate your code efforts with other team members to develop a software project. In addition, you can manage work and that is assigned to you, your team, or your projects. Team Explorer is a plug-in that installs with Visual Studio and Team Explorer Everywhere is a plug-in that installs with Eclipse. Developers can effectively collaborate using Team Explorer connected to projects hosted on Azure DevOps Services or an on-premises Azure DevOps Server (previously named Team Foundation Server (TFS)). You can install the latest version of Visual Studio clients from the Visual Studio downloads page. Additional options for connecting to Azure DevOps Services or TFS include: Team Explorer Everywhere Azure DevOps Plugin for Android Studio Azure DevOps Plugin for IntelliJ Visual Studio Code For information about compatibility among client and server versions, see Requirements and compatibility. If you don't need Visual Studio, but want to connect to a project in Azure DevOps, you can install the free Visual Studio Community. You must have a project in Azure DevOps. If you need to add a project, see Create a project. You must be a member of the project you connect to. To get added, see Add users to a project or team. Team Explorer connects Visual Studio to projects in Azure DevOps. You can manage source code, work items, and builds. The operations available to you depend on which source control option—Git or Team Foundation version control (TFVC) —was selected to manage source code when the project was created. If you open Visual Studio and the Team Explorer pane doesn't appear, choose the View>Team Explorer menu option from the tool bar. From the Connect page, you can select the projects you want to connect to and quickly switch connection to a different project and or repository. For details, see Connect to a project.
- 237. Git version control and repository NOTE VISUAL STUDIO 2019 VISUAL STUDIO 2017 VISUAL STUDIO 2015 The Git and TFVC repos support different pages and functions. For a comparison of the two version control systems, see Choosing the right version control for your project. The following images show the pages available when you connect to a Git repository from Team Explorer. Visual Studio 2019 version 16.8 and later versions provide a new Git menu for managing the Git workflow with less context switching than Team Explorer. Procedures provided in this article under the Visual Studio 2019 tab provide information for using the Git experience as well as Team Explorer. To learn more, see Side-by-side comparison of Git and Team Explorer.
- 238. Team Foundation version control To learn more about each page, see the following articles. Home and Builds Git version control Work items Home Web portal Task Board Builds Create build pipelines View and manage builds Manage the build queue Install Continuous Delivery (CD) Tools for Visual Studio Configure and execute Continuous Delivery (CD) for your app Create a new repo Clone an existing repo Changes: Save work with commits Branches: Create work in branches Pull Requests: Review code with pull requests" Sync: Update code with fetch and pull Tags: Work with Git tags Git preferences Git command reference Default experience (Visual Studio 2019 and later versions) View and add work items Set the Work Items experience in Visual Studio Legacy experience (All Visual Studio versions) Add work items Query editor Query folders Query permissions Open query in Excel Email query results using Outlook Create reports from query in Excel The following images show the pages available when you connect to a TFVC repository from Team Explorer.
- 239. VISUAL STUDIO 2019 VISUAL STUDIO 2017 VISUAL STUDIO 2015 To learn more about each page, see the following articles. Home and Builds TFVC Work items Home Web portal Task Board Builds Create build pipelines View and manage builds Manage the build queue Install Continuous Delivery (CD) Tools for Visual Studio Configure and execute Continuous Delivery (CD) for your app Configure workspace Suspend/resume work, Code review Pending Changes: Manage pending changes, Find shelvesets, Resolve conflicts Source Control Explorer: Add/view files and folders Add Check-In Policies Version control commands Default experience (Visual Studio 2019 and later versions) View and add work items Set the Work Items experience in Visual Studio Legacy experience (All Visual Studio versions)
- 240. Team Explorer plug-in for Eclipse HOME PAGE WITH GIT (ECLIPSE) HOME PAGE WITH TFVC (ECLIPSE) Add work items Query editor Query folders Query permissions Open query in Excel Email query results using Outlook Create reports from query in Excel If you work in Eclipse or on a non-Windows platform, you can install the Team Explorer plug-in for Eclipse. Once installed, you can share your Eclipse projects by adding them to Azure DevOps Services or TFS using Git or TFVC. To learn more about each page, see the following articles. Home and Builds Version control Work items Home Web portal Builds Create build pipelines View and manage builds Manage the build queue Install Continuous Delivery (CD) Tools for Visual Studio Configure and execute Continuous Delivery (CD) for your app Git repo
- 241. Reports NOTE Settings Share your code Git preferences Git command reference TFVC repo Share your code Pending changes Source Control Explorer Add Check-In Policies Version control commands Add work items Query editor Query folders Query permissions Some pages, such as Reports, only appear when an on-premises TFS is configured with the required resources, such as SQL Server Reporting Services. The Reports page opens the Reporting Services report site. This page appears only when your project has been configured with SQL Server Analysis Services and Reporting Services. Also, the option to Create Report in Microsoft Excel appears only when reporting has been configured for the project. If your project is missing one or more pages, you may be able to add functionality to your on premises TFS deployment. From the Settings page, you can configure administrative features for either a project or project collection. To learn more about each page, see the following articles. Most of the links open to a web portal administration page. Not all settings are available from the Team Explorer plug-in for Eclipse. Project Security, Group Membership Security, Source Control (TFVC) Work Item Areas Work Item Iterations Portal Settings Project Alerts Project Collection Security, Group Membership Source Control (TFVC) Process Template Manager Other Git Global Settings
- 242. Refresh Team Explorer or Team Explorer Everywhere Resolve images that don't display in Team Explorer Related articles Additional tools provided with TFS Power Tools Git Repository Settings To learn more about settings, see About team, project, and organizational-level settings. If data doesn't appear as expected, the first thing to try is to refresh your client. Refreshing your client updates the local cache with changes that were made in another client or in TFS. To refresh Team Explorer, do one of the following actions: To refresh a page that you are currently viewing, choose Refresh in the menu bar (or choose F5). To refresh the project you currently have selected, choose Home, and then choose Refresh (or choose F5). To refresh the set of teams defined for the project that you currently have selected, choose Connect, and then choose Refresh (or choose F5). To avoid potential errors, you should refresh your client application under the following circumstances: Process changes are made. Work item type definitions are added, removed, renamed, or updated. Area or iteration paths are added, removed, renamed, or updated. Users are added to or removed from security groups, or permissions are updated. A team member adds a new shared query or changes the name of a shared query. A build pipeline is added or deleted. A team or project is added or deleted. If an inline image isn't displayed in a work item form that you view in Visual Studio Team Explorer, but the image is displayed in the web portal, your credentials might have expired. You can resolve this by completing the following steps: 1. In Visual Studio, select View > Other Windows > Web Browser (or use the shortcut Ctrl+Alt+R). 2. In the web browser, locate your organization. 3. Sign in with your credentials. 4. Refresh your work item in Team Explorer. Troubleshoot connection Create a project By installing TFS Power Tools, you gain access to these additional tools through the Team Explorer plug-in for Visual Studio: Process Template Editor Additional check-in policies for Team Foundation Version Control Team Explorer enhancements including Team Members Team Foundation Power Tool Command Line Test Attachment Cleaner Work Item Templates Additional requirements may apply.
- 244. Service and rate limits for Azure DevOps Services 6/9/2022 • 2 minutes to read • Edit Online Work items Area and iteration paths CONFIGURATION OBJECT LIMIT Projects 1000 per organization for Azure DevOps Services No prescribed limit for on-premises (See also Work tracking, process, and project limits Teams 5,000 per organization Work item tags 150,000 tag definitions per organization Area Paths 10,000 per organization Area Path Depth 14 Area Paths per team 300 Iteration Paths 10,000 per organization Iteration Path Depth 14 Iteration Paths per team 300 Azure DevOps Services Azure DevOps Services, like many Software-as-a-Service solutions, uses multi-tenancy to reduce costs and to enhance scalability and performance. This leaves users vulnerable to performance issues and even outages when other users of their shared resources have spikes in their consumption. To combat these problems, Azure DevOps Services limits the resources individuals can consume and the number of requests they can make to certain commands. When these limits are exceeded, subsequent requests may be either delayed or blocked. This article specifies certain limits placed on the use and configuration of Azure DevOps services. For more information, see Rate limits and Work tracking, process, and project limits. A long text field can contain 1M characters. You can't assign more than 100 tags to a work item. You can't add more than 1,000 links to a work item. You can't add more than 100 attachments to a work item. You can't add an attachment size larger than 60 MB to a work item. You can have up to 1,000 tasks on a task board You can have up to 10,000 work items on a backlog You are limited to 5,000 teams in a project You can't create more than 150,000 tag definitions per project
- 245. Queries Process customization Wiki TIP Data import Related articles The execution time limit for queries is 30 seconds. See Optimization best practices to improve query performance. Query results are limited to 20,000 Queries are limited in length to 32,000 characters When customizing the work item types (WITs) defined in the Inheritance or Hosted XML process models, be aware of the limits placed on objects defined in Work tracking, process, and project limits. Wikis defined for a project are limited to 1 GB per git repository. To derive the size of a wiki/git repository, download the repo to your local computer, unzip the file, and then open the Properties for the corresponding folder. Limited to 300 projects per organization See data import documentation for details Rate limits Work tracking, process, and project limits Configure and customize Azure Boards Usage monitoring
- 246. What are the features in Azure DevOps? 6/9/2022 • 53 minutes to read • Edit Online NOTE Access and supported clients Connect to the web portal from the latest versions of these supported browsers: - Chrome - Microsoft Edge - Firefox - Internet Explorer - Safari (Mac) Track work and integrate with your code, build, and test environments from the following clients: - Eclipse (Team Explorer Everywhere) - Visual Studio - Android Studio - IntelliJ - Visual Studio Code To learn how to connect, see Connect to a project. Use features supported by these familiar clients to manage your project and illustrate your requirements. - Excel - Manage users (Azure DevOps Services) - Change access levels (Azure DevOps Server) Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Learn about all the features available to help you plan and track your projects and code, build, test, and release your software applications in Azure DevOps. If you're new to Azure DevOps, see our overview articles that are designed to give beginners an understanding of the server-client structure and tools supported. For a description of the core services supported through the web portal, see Essential services. Some features are platform-dependent, based on the following two platforms: Azure DevOps Services - cloud service Azure DevOps Server - on-premises Browsers Integrated Development Environments (IDE) Office integration clients Manage users and groups Add members to your project adds them to the Contributor group. When managing a large group of users, use built-in groups to manage users and their permissions. Add team members To share and contribute to your project, add users to Azure DevOps Services or your Azure DevOps Server. Azure Active Directory (Azure AD) (Azure DevOps Services) Control who can access your team's critical resources and key business assets by managing access with Azure Active Directory groups. Access levels All users that you add to your Azure DevOps organization or to your Azure DevOps Server project have access to Basic features by default, except Stakeholders who have access to a limited set of features, or those added to the Advanced access level in Azure DevOps Server. Permissions Control access to specific features by setting permissions for a user or group. Area and iteration paths - Build & Release - Git - TFVC - Dashboards - Queries - Manage teams and configure team tools - Test - Work item tags
- 247. Agile tools to plan and track work Backlogs Create your backlog Plan your project by adding a work item for each user story or requirement you plan to develop. Organize your backlog Group items into a hierarchical list using portfolio backlogs and quickly reorder and re-parent items to effectively manage your deliverables. Forecast Use the forecast tool to estimate work to be completed in future sprints. Move work item to a different project (Azure DevOps Services) Choose Change project, Actions menu in a work item form to move the work item to a different project. Full screen mode Choose or to enter or exit full screen mode. Backlog and board settings Choose to configure team backlogs and boards, including show bugs on backlogs and boards and set team backlog levels. View portfolio backlog hierarchy Use Parents Show/Hide to drill down into the backlog hierarchy. Multi-team backlog ownership Easily view and track items owned by other teams and quickly reorder and re-parent items to effectively manage your backlog. Change work item type (Azure DevOps Services) If you added a task instead of a bug and want to change the work item type to bug, you can. Choose Change type Actions menu in a work item form to change the work item type. Filter your backlog Use Show/Hide in progress to only show or hide items which have moved from the new or proposed state to active or in progress state. Additionally, you can list a subset of items based on keywords keywords or tags. Request feedback Request feedback on working software and easily track responses that capture interaction with video, verbal, or type-written comments. Feedback client
- 248. Bug, task, and issue tracking Provide the free Microsoft feedback client to capture their responses to your feedback requests. Track issues and other types of work Different types of work items track different types of work - such as bugs, test cases, risks, issues, and more. Bulk modify Quickly change one or more fields in several work items using bulk modify in the web portal or bulk modify using Excel. Copy or clone a work item Copy an existing work item or bulk copy several using Excel. Follow a work item Choose / Follow/Following to quickly start or stop tracking changes made to a work item. Estimates and time tracking Track estimated, completed, and remaining work for tasks and other work items. Several reports and dashboards provide charts that display data based on team capacity and remaining work. New work item experience The new work item experience provides access to a more modern form, additional features, and the ability to add fields and apply other customizations to the work item type. Manage bugs Capture and triage bugs using different kinds of tools. Choose how you want to track bugs Each team can choose to manage bugs on their backlog or along with tasks. Share plans and information Share information using work items and generate summary lists with links to backlogs or queries. Remove or delete a work item Remove work items from the backlog by changing their State to Removed. Or, move them to the recycle bin or permanently delete them. Tags Add tags to work items to filter backlogs and queries. Bulk update work items or use work item templates to add or remove tags. Discussion Add or review comments added to a work item. Start by choosing discussion. Integrate Git development with work tracking Drive Git development and stay in sync as a team to complete backlog items and tasks using the Git Development section. Add branches, create pull requests, and view all development done to support the specific work item. Verify a bug, rerun test case Choose Verify from the bug work item form context menu to launch the relevant test case in the web runner. For more information, see Run tests for web apps. Link work items Track related work, dependencies, and changes made over time by linking work items. Add or modify a field Add a custom field (Azure DevOps
- 249. Customize (Azure DevOps Services) Rich text comments Describe and comment on work using formatted text, hyperlinks, and inline images. Choose or to expand or contract the viewing area. Clear HTML formatting Use or CTRL+Spacebar to remove formatting from highlighted text. Attachments To support collaboration of work in progress, add emails, documents, images, log files, or other file types to work items. Work item templates Quickly add new work items based on templates with pre-populate values for your team's commonly used fields. History & auditing Review and query work item change history to learn of past decisions and support future ones. Services | Azure DevOps Server to support tracking additional data requirements or modify an existing field to apply optional rules. Restrict access Limit who can create or modify work items or a work item field based on area path, work item type, or based on your specific conditions. Field index Find descriptions and usage information for each field from the work item field index.
- 250. Customize (Azure DevOps Server) Create an inherited process The first step in customizing a project is to create an inherited process. You can only customize inherited processes. New work item experience The new work item experience provides access to a more modern form, additional features, and the ability to add fields and apply other customizations to the work item type. Customize a process Customizations you make to an inherited process automatically update all team projects that reference that process. You can customize your project as follows: Add and modify fields Modify the web form layout Modify the workflow states Add a custom work item type Add a custom control Change the process used by a project To apply customizations to one or more team projects, you change the process they reference to a customized inherited process. Enable/disable a process To make sure no one creates a project from a process that you don't want used, you can disable it. Add or modify a field Add a custom field to support tracking additional data requirements or modify an existing field to apply optional rules. Remove a field from a form You can remove a custom field and select inherited fields from a work item form. You can also relabel the fields that appear on the form. Area path pick lists Change the pick list of area paths to support grouping work items by team, product, or feature area. Sprint/iteration pick lists Change the pick list of iteration paths to support grouping work into sprints, milestones, or other event-specific or time-related period. Activate sprints for each team. Review fields You can review the list of fields defined for a process, their data type, and the WITs which reference them. For descriptions and usage of each field, see Work item field index. Delete a field from the collection You can delete a custom field if you find it's no longer required. Customize the web form For each work item type, you can add custom pages to group additional custom fields and you can organize your forms by placing logically related groups and HTML fields on separate pages within a form. Add a custom work item type You can add and modify a custom work item type. Customize the workflow For each work item type, you can add custom workflow states to support your business tracking needs. Delete a process Delete those inherited processes that you no longer want used. Choose Delete. Set process permissions To customize a process, add custom fields, or change the layout of a work item form, you must be a member of the Project Collection Administrators group or be granted explicit permissions to edit a specific process.
- 251. Kanban Add or modify a field Add or modify a field to support work tracking and reporting by editing the WIT definition. Add rules to a field Apply various rules to custom fields to qualify the value it can have, to copy a value, to specify a default, to restrict who can modify it, to enforce pattern matching, or to enforce conditional values. Remove a field Stop tracking a field by removing the field from the work item form of select work item types. Area path pick lists Change the pick list of area paths to support grouping work items by team, product, or feature area. Sprint/iteration pick lists Change the pick list of iteration paths to support grouping work into sprints, milestones, or other event-specific or time-related period. Custom pick lists Define or modify pick list values by editing the work item type definition. Modify the workflow Design your custom workflow by adding states, transitions, reasons, and optional actions. Change the work item form Change the layout of your work item form by adding fields, custom controls, or tabs. Add a custom work item type Add a custom work item type to track different data requirements.
- 252. Scale Kanban basics Use your Kanban board to visualize and track the flow of work from idea to completion as well as quickly update work item fields Drag-n-drop Drag and drop items on the Kanban board to update status and to reorder and reparent items. Add task checklists Add and mark tasks as done with lightweight tasks checklists. Filter Use key words to filter and find items on the Kanban board. Set WIP limits Set constraints on the amount of work your team undertakes at each work stage to gain access to sprint backlogs and task boards. Split columns Turn on split columns to track the lag between when items are done in one state and work actually starts in a new state. Map your workflow Customize columns to support your team's workflow and track work from start to finish. Expedite work with swimlanes Use swimlanes to track work at different service-level classes. Definition of done Support your team to be in sync by specifying requirements to fulfill prior to handoff of items to a downstream work stage. Filter by field values or parent work items Choose field filter to filter the board based on assignment, iteration, work item type, or tags. Cumulative Flow Diagram With the CFD, you can monitor the count of work items as they progressively move through various states which you define. Customize cards Add fields to cards that you can edit directly on your Kanban and task boards. Live updates Enable live updates to automatically refresh your Kanban board when changes are made by others or to the board settings. Add inline tests Add, run, and update tests with inline test on your Kanban board. Add checklists to features and epics Add and mark user stories and other work items as done from your Kanban features or epics boards. Set team's card reorder preference You can preserve the backlog priority when you move a card to a new column by setting your team's Kanban board card reordering setting. Enable/disable card annotations Turn on or off task checklists or inline tests for your Kanban board. Configure inline tests Configure how new inline tests are added to the Kanban board: create a new test plan/test suite or choose an existing test plan.
- 253. Scrum Workflow Add another team Add and structure teams and organize work to support team autonomy and organizational alignment. Teams can manage their work independently of one another while the organization gains visibility across all teams. Set team defaults Several Agile tools reference the team's default area path, iteration path, and activated sprints to automatically filter the set of work items they display. Understand how defaults are used. Set up a team hierarchy By configuring your teams and backlogs into an hierarchical structure, program owners can more easily track progress across teams, manage portfolios, and generate rollup data. Autonomy and alignment As your organization grows, your tools can grow to support a culture of team autonomy and organizational alignment. Scale your tools and practices Incrementally adopt practices that scale to create greater rhythm and flow within your organization, engage customers, improve project visibility, and develop a productive workforce. Portfolio management Manage a portfolio of backlogs and gain insight into each team's progress as well as the progress of all programs. Scaled Agile Framework Structure team projects to support epics, release trains, and multiple backlogs to support the Scaled Agile Framework. Define sprints Schedule and activate your team's sprints to gain access to sprint backlogs and task boards. Select team sprints, set team defaults Several tools reference the team's default and active iteration paths or sprints. For the Agile tools to work best, each team needs to set their team area path(s) and iteration paths to support their work tracking activities. Plan sprints Build your sprint backlog, add tasks, and load balance work across your team as you plan your sprint. Track work on your task board Use your task board during your daily Scrum meetings to view and update progress. Velocity & forecasting Use velocity charts and forecast tools to estimate work that can be completed in future sprints. Sprint burndown charts Monitor progress and review team patterns from sprint burndown charts. Manage resources Use capacity planning tools to track individual, team, and activity over and under capacity for a sprint.
- 254. Alerts and notifications What is workflow? You use workflow to track the progress of work as it moves from new, active, to complete or closed. Each workflow consists of a set of states, the valid transitions between the states, and the reasons for transitioning the work item to the selected state. Default workflows Each process defines the workflow for each work item type to track progress from newly defined, to in progress, to completed or closed. Kanban workflow You can fully customize your Kanban board to map the workflow your team uses by adding and renaming columns Customize the workflow For Azure DevOps Services: add custom workflow states to support your business tracking needs. For Azure DevOps Server: Design your custom workflow by adding states, transitions, reasons, and optional actions. States States allow you to track the status of work. For example, a bug moves from Active, Resolved, and Closed to correspond to when it's defined, fixed, and verified as fixed. Transitions Transitions specify the valid progressions and regressions from state to state for a work item type. Reasons Each transition specifies a default reason as well as optional reasons for tracking the change in state. Update fields during workflow changes (Azure DevOps Server) You can define rules that change a field value whenever you change the state, perform a transition, or select a reason. Apply workflow conditional field rules (Azure DevOps Server) You can define rules that change a field value based on the contents of other fields during workflow changes. Restrict who can make changes during workflow transitions (Azure DevOps Server) Set a condition field rule that applies to a group to restrict who can make changes to a workflow or a field. Event-generated workflow changes or field assignments (Azure DevOps Server) Add an action to a custom workflow definition to automatically transition work items or specify a field value based on an internal Azure DevOps Server event or external event. Visual workflow design tool (Azure DevOps Server) You can change the workflow or view the workflow state diagram by using the Process Editor, a power tool for Visual Studio.
- 255. Code Personal and team notifications or alerts Get notified as changes occur to work items, code reviews, source control files, and builds by setting personal notifications or team notifications. Share queries and sprint plans Email a query or sprint plan. Quick alerts to team members Use the @mention control to send email to team members to bring them into a discussion around work changes, pull requests, or other items. Client feature flag updates Alert flag within the IDE automatically notifies you of the latest client changes. Follow a work item Choose / to quickly start or stop tracking changes made to a work item. Follow a pull request To track the progress of a single pull request, choose from the menu. Manage work items you follow From the Work>Queries page you can view the list of work items that you're following. Frequent on-line feature updates Check the News for product updates, or read about them by accessing the News link in your web portal.
- 256. Code: Git
- 257. Get started with Git in Visual Studio To get started working with Git, clone a repository, add code, and create branches in Azure DevOps Services or Visual Studio. Learn how to commit, publish, and conduct a pull request of your changes. Clone repositories To work locally, you clone a repository. Commit changes Enter commit messages and quickly push your local changes to the shared repo. Pull requests Use pull requests to review and merge branch code to a main branch. Sync Quickly sync your local branch with a shared repo. Get started using Eclipse Work with Git repositories using the Team Explorer Everywhere IDE for Eclipse. Add reviewers to get feedback Use the @mention control to add reviewers to your pull request to get their feedback about your changes. Resolve Git merge conflicts Merge conflicts occur when commits have changes to the same files as other newer commits in the branch history. Learn how to prevent and resolve merge conflicts. Code search Maximize cross-team collaboration and code sharing by finding code across all the projects to which you have access. Narrow down your results and focus in on code by using filters, preview code, view history, compare versions, and more Get notified about pull requests Subscribe to email alerts to get notified about new pull requests, changes, approvals, and rejections. Set branch policies To improve code quality, set branch policies to require code reviews or automatically add reviewers. Automatically build pull requests Set a branch policy to automatically generate a build for a pull request to selected branches. Create Git repositories When you create a project with Git as your version control system, you automatically create a Git repo. You can Create additional Git repos from the admin context. Rename a Git repository Integrate Git development with work tracking Drive Git development and stay in sync as a team to complete backlog items and tasks using the Git Development section. Add branches, create pull requests, and view all development performed to support the specific work item. Quickly link work items to pull requests Use the #ID control to link work items to your pull request to support tracking work. Get started using Xcode Work with Git repositories using the Xcode IDE. Git commands Use Git command line tools when you need to perform select manual tasks or to automate work using a script. Bypass a branch policy Grant an Exempt from policy enforcement permission to a user or group. Rebase a branch Before merging a branch into main, you may choose to first rebase your branch onto the latest commit in main. Git permissions Set permissions on a Git project, repository, or branch from the context menu or from the web portal administration page.
- 258. Code: TFVC Azure Artifacts (Azure DevOps Services) Rename Git repos from the admin context. Get started with TFVC in Visual Studio Develop and share your code. Learn how to configure your workspace, check-in your code, compare file changes, and view file history. Set up local or server workspaces Create a local workspace that maps to the code base of interest. Resolve conflicts Support for Resolve conflicts that arise when several people work concurrently on a file. Compare files and folders Compare server folders and local folders to each other, and view the differences between the contents of each folder. Track changesets Find information about which branches have received a particular set of changes and when those changes were merged. Request code review Increase overall code quality and reduce the risk of creating bugs by requesting a code review when you check-in code. Review history of a file Get detailed information about what changes have been made to your files. Suspend work Use shelvesets when you need to set aside some or all of your work in progress. Manage branches, isolate risk Use branches and locks to isolate risk introduced by work done by different teams. Merge branches Integrate work completed in different branches during certain phases of your project. Set check-in and check-out policies Enforce practices that lead to better code and more efficient group development by setting check-in/check-out rules. Code search Find code across all the projects to which you have access. Narrow down your results and focus in on code by using filters, preview code, view history, compare versions, and more Subscribe to alerts when check-ins occur Get notified when someone checks in code to your TFVC project by subscribing to receive email alerts. Version control locks Lock files or folders when you need to prevent them from being checked out or modified. Download files from the server Get the latest files from the server on a regular basis so that the code you develop is compatible with the code developed by others on your team. TFVC permissions Set permissions on select code management tasks from the context menu for TFVC files or folders or the admin context for the project.
- 259. Continuous delivery Build What is Azure Artifacts? Azure Artifacts is the new name for what was previously Package Management. Azure Artifacts helps you manage code sharing by automating common tasks for discovering, consuming, and sharing components. Create feeds Create feeds to share code through packages. Move existing file shares to the cloud Eliminate dependencies on on- premises file shares and hosted instances of NuGet.Server by moving your packages to Azure DevOps Services. Discover and consume packages Consume packages by connecting to a feed. Publish packages to feeds Publish packages to share code with your team and your organization. Add identities to your feeds Give teams and service identities access to your feeds. Upstream sources use a single feed to manage packages from different sources. Publish and install packages from your feed and public registries with Upstream Sources. Remove a NuGet package from a feed Unlist or remove a package Delete packages and recover deleted packages from the recycle bin in Azure Artifacts you no longer want users to discover. Secure feeds Control who can contribute to or consume from a feed. Define builds Start from a build template and customize your build from there. Build for Windows, iOS, Android, Java (Ant, Maven, or Gradle), or Linux using the same domain-specific languages you use every day on your dev machine. Build Xamarin apps for both iOS and Android and run tests on the Xamarin Test Cloud as part of the build. Customize build process using scripts Use a script to add your team's business logic to your build process. Build agents and agent pools At least one agent is required to build your code. As you scale your system with more code, people, and builds, you'll need more build agents organized within agent pools. You can use both on-premises or Microsoft-hosted agent pools. Gated check-in (TFVC, Azure DevOps Services) Use gated check-in to protect against breaking changes when checking code into TFVC. Branch policies (Git) Improve code quality by setting branch policies to ensure builds are never broken or getting the right people to review changes. Specify your build steps Add steps to specify what you want to build, the tests to run, and all the other steps needed to complete the process. pipelinestasksbuildmedia Build an Android app using Gradle
- 260. Sign and align Android APK files Build with Apache Ant Build using a Gradle wrapper script Grunt: The JavaScript Task Runner Gulp: Node.js task-based build system Index source code and publish symbols Build with Apache Maven Build with MSbuild SonarQube for MSbuild Visual Studio and MSbuild Build an Android app with Xamarin Build an iOS app with Xamarin on macOS Build variables Use predefined variables or add your custom variables when configuring your build definition or your build scripts. Continuous integration builds Define a CI build that compiles and tests your solutions whenever your team checks in code. Build summary charts View real-time build status and add build summary charts to your dashboards. Code coverage charts From the Code Coverage tab on a Build summary page, you can view percentage of code coverage as well as upload code coverage data in Jacoco or Cobertura formats. Audit changes Determine who changed what in the build definition and when they did it. Build retention policies
- 261. Release Define policies to automatically delete old completed builds to minimize clutter. Build permissions Determine who can define, delete, and manage builds. Automate deployments Reduce time-to-market and respond to customer feedback with greater agility by automating your release process. Deploy applications across platforms to all environments of the pipeline with just one selection. When to use Azure Pipelines or Build & Release in Azure DevOps Server? Evaluate how Azure Pipelines and Build & Release in Azure DevOps Server can help you in your development and deployment efforts. Release definitions Add a release definition by choosing the build version, target release environments, and tasks. Release environments Define and clone release environments, logical entities that represent where you want to deploy a release, such as a collection of servers, a cloud, multiple clouds, or an app store. Artifacts A release is fundamentally defined by versioned artifacts that make up the release. As you deploy the release to various environments, you deploy and validate the same artifacts on all environments. Tasks Automate release deployment by defining the events that trigger a Works for any app Deploy any type of application across multiple platforms including Windows and Linux, whether on- premises or in the cloud. Approval workflows Streamline your application release workflow by routing pre- and post-deployment approvals to multiple approvers or teams. Release notifications Receive email messages as releases occur. Approvers receive notifications automatically when a release is waiting for approval. Full traceability Monitor the status of your release pipelines and track every deployment in each of the environments. Retain full audit history of all activities performed on a release with detailed release logs and approval tracking. Release logs View or download log files as zip files. Log files contain the status for each step or task of a release, for each of the environments in the release definition. Each completed release--succeeded, failed, or abandoned--includes a live log file, details, and history for each step or task. Triggers Automate release deployment by defining the events that trigger a release. Variables Lookup the description for all release system, global, and agent variables. Release names Specify the naming and numbering scheme you want used when adding releases. Global configuration properties Simplify management of custom values that you use to configure multiple releases by specifying custom values for any of the tasks in any of the environments of a release definition. View test results Open the Tests tab to view a summary of the test results, including pass/fail percentages and run duration. Sort the test results into groups or filter the results to show just passed, failed, or other results. Add release summary to dashboard (Azure DevOps Services) Add a release summary chart to a team dashboard. Extend and customize Create workflows tailored to your process by customizing our tasks, or extend with your own custom tasks.
- 262. Test release. Agents and agent pools Agent pools are the execution containers that specify the security context and runtime environment for the agents that run when you deploy a release. Manage permissions Grant or deny permissions to manage release definitions, environments approvers, or release permissions. Set permissions for users, groups, or per release definition.
- 263. Dashboards and reports Comprehensive testing Perform exploratory, manual, system, and user acceptance tests for any app, in any language. Using Visual Studio or 3rd-party test frameworks, you can include automated tests with builds and releases for continuous integration and deployment. Unit testing with Git Create unit tests and run them frequently to make sure your code is working properly. Manual test plans and test cases Get started by creating test plans and test cases to track manual testing for sprints or milestones. Shared steps and shared parameters Create shared steps to include often repeated sequence of steps in your manual test cases, such as logging in. Repeat manual tests with different data using shared parameters. Coded UI testing Use Visual Studio to create coded UI tests to test your application's user interface. Run test with your builds for continuous integration Use continuous integration builds to run tests automatically. Review automated test results after a build Review your test results to analyze any problems that were found. Quickly assign configurations to test plan, test suite, or test case From the context menu of a test plan, test suite, or test case, you can assign a configuration. Exploratory testing Explore user stories without test cases or test steps using Azure Test Plans and exploratory testing. Or, download and install the Test & Feedback extension. Capture screenshots, annotate them, and submit bugs while you explore your web app - all directly from your Chrome browser. Record and play back manual tests With Azure Test Plans, you can record your keystrokes and gestures while you test an application. The next time you run the test, you can play back your actions quickly and accurately. Track test status and test results Quickly view the status of your testing using lightweight charts. Test environments Specify a combination of hardware and software that represents a user or machine environment in which your app runs. Test permissions Set permissions on who can manage test configurations, test environments, and publish and delete test results.
- 264. Charts and dashboards | Multiple team dashboards Each team can create several team dashboards to help keep both the team and Stakeholders in sync. Each dashboard tile provides quick access to the progress of builds, status of work items, or latest code changes. Build history charts Add build history charts to your dashboards. Test charts Track the status of your test progress and test runs. Optionally add these charts to a dashboard. Test quality trend charts Add failure and duration charts for tests run as part of your build to your team dashboard. Restrict or allow team members to manage dashboards (Azure DevOps Services) Set permissions to restrict or allow team members to manage dashboards. Capacity planning and tracking Easily track how much work your team has completed and has left to do in a sprint by adding the sprint capacity chart widget to your dashboard. Share dashboards with Stakeholders Grant non-licensed users access as Stakeholders (Azure DevOps Services | Azure DevOps Server) so they can view progress, run queries, and contribute ideas. Velocity charts Team velocity tracks the total estimated effort (story points or size) of backlog items (user stories or requirements) completed or still in progress within each sprint. Sprint burndown charts Monitor progress and review team patterns from sprint burndown charts Add release summary to dashboard (Azure DevOps Services) Edit dashboard mode Add, remove, move, and configure widgets by choosing Edit dashboard. Select the checkmark to exit. Auto-refresh dashboards You can enable auto-refresh for any team dashboard, and it automatically updates every five minutes. This is a useful feature for when your dashboard serves as a team wallboard. Widget catalog Add widgets to your dashboard to provide information and monitor the data your team needs. Work item query charts View the status of work in progress by charting the results of a flat-list query. You can create several types of charts—such as pie, column, or trend—for the same query. Optionally add these charts to a dashboard. Drag-n-drop layout Configure the layout to your specifications by dragging tiles into the sequence you want. Cumulative flow diagrams Track the progress of work on your backlogs through the CFD charts. Power BI dashboards (Azure DevOps Services) You can create dashboards, individual reports, or explore data collected for your Azure DevOps organization once you connect to Power BI.
- 265. Power BI dashboards and reports SQL Server Reports (Azure DevOps Server) Add a release summary chart to a team dashboard. Basic Power BI concepts The 3 major building blocks of Power BI are dashboards, reports, and datasets. Get started You can create dashboards, individual reports, or explore data collected for your organization once you connect to Power BI. Connect to Power BI Steps required to authorize Power BI to access your organization. Available data The Power BI Data Connector supports building reports to track status and trend work items. Reporting Services reports You can analyze the progress and quality of your project by using the out-of-the-box reports in SQL Server Reporting Services. These reports aggregate metrics from work items, version control, test results, and builds. They are uploaded when you create a project based on the process Agile, Scrum, or CMMI that you choose. Add Reporting Services reports If you need to add reporting services to a project or on-premises Azure DevOps Server after you've created your team projects, you can by adding a report server and uploading reports. Manage the data warehouse The reporting warehouse is a traditional data warehouse that consists of a relational database and an Analysis Services database. You manage it through the following activities: Manually process the data warehouse Rebuild the data warehouse Resolve schema conflicts Change a process control setting Build reports Build reports track the quality of software under development. By defining tests to run automatically as part of each build definition and instrumenting tests to gather code coverage data, you can gain insight about the quality of the builds, tests, and code. Build Quality Indicators Build Success Over Time Build Summary Test and bug reports Test planning reports support monitoring the test progress and coverage of backlog items or user stories. Bug tracking reports illustrate the team's capacity to find and resolve bugs. Test Case Readiness Test Plan Progress" Bug Status Bug Trends Reactivations Required team activities to generate useful reports To gain useful, actionable information from your
- 266. Widgets Informational content and other links Plan and track work Plan and track work (continued) reports, team members must perform certain activities. Project management Project management reports provide insight into how much work the team is tackling within a sprint or release, and the rate of their progress. By linking work items and updating specific fields as work is performed, you can track the progress of individual stories and be able to more accurately estimate future activities. Scrum reports Backlog Overview Release Burndown Sprint Burndown Velocity Agile and CMMI Burndown and Burn Rate Remaining Work Requirements Overview (CMMI) Status of All Iterations Stories Overview (Agile) Stories Progress (Agile) Unplanned Work Set permissions to view or create reports Enable members of your team to view or manage Reporting Services reports. To create or modify reports, you need to grant them access to read databases. What is a widget? You build your dashboards by adding information tiles or widgets. The widget catalog provides a number of predefined widgets. Drag-and-drop widgets Drag widgets, tiles, or charts anywhere on a dashboard to configure the layout you want. Markdown widget Adds a configurable tile to your dashboard to display any type of information, guidance, or links that you want using Markdown syntax. Team member Opens the team's quick dialog to add or remove team members. Assigned to me widget Provides quick access to work items assigned to the logged in user. Chart for work items Adds a configurable tile to display the chart for a shared query. New work item Add work items pre-scoped to your team's default area and iteration paths. Sprint burndown Adds a burndown chart for tracking a team's Scrum progress for the current sprint. Sprint capacity Adds a chart for tracking remaining capacity when tracking a team's Scrum progress for the current sprint. Sprint overview Displays a visual overview of the current sprint progress for tracking a team's Scrum progress for the current sprint, indicating the number of backlog items in progress, completed, or not started. Work links
- 267. Code widgets Build and test widgets Extensibility Extensibility Marketplace Visual Studio widget Provides links to open or download Visual Studio. The Visual Studio IDE client comes with the Team Explorer plug-in which provides quick access to several features (some of which aren't available through the web portal). Welcome widget Provides quick access to getting started info on how to track work, code, build, and test. Code tile Configurable tile to display status and links to a Git or TFVC code repository, branch, or folder. Pull request Adds a configurable tile to display active pull requests requested by the team, or assigned to or requested by the person logged in. You select the Git repository for the pull requests of interest. Other links widget Provides quick access links from a team dashboard to request feedback, define sprints, and modify your team's area paths. Query tile Configurable tile to display the results and link to a shared query. Query results Adds a configurable query results list to a team dashboard. Requirements quality Displays a configurable widget that you can use to track quality continuously from a build or release definition. Provides quick access links from a team dashboard to open the team backlog, Kanban board, task board, and queries. Chart for build history Configurable tile to display the histogram for a specific build definition. Deployment status (Azure DevOps Services) Configurable tile that shows you a consolidated view of the deployment status and test pass rate across multiple environments for a recent set of builds. Release definition overview Configurable tile to view and track the status of a release definition. The widget shows the release as a series of environments, with the name of the release and the date or time it was started. Test trend results Provides trend of test results, such as passed or failed tests, for a selected build definition. Marketplace widgets You can find additional widgets by browsing the Marketplace Dashboard widget SDK Create a dashboard widget using the REST API service. Feature availability: You can add Marketplace extensions from the web portal for Azure DevOps or for Visual Studio or Visual Studio Code.
- 268. REST APIs Service hooks What is the Marketplace? From the Marketplace, you can extend the functionality available to you by installing free extensions or purchasing a subscription or paid extension. Extensions support adding new capabilities to Visual Studio, Visual Studio Code, and Azure DevOps. Subscriptions Visual Studio subscriptions are a way for you to get the Visual Studio IDE, team collaboration benefits like Azure DevOps, and subscriber benefits like dev/test use of Windows, Windows Server, and SQL Server. Extensions You can get and quickly install extensions to add functionality to Visual Studio, Visual Studio Code, or Azure DevOps Services. Try Azure Test Plans for free You can start a trial for Azure Test Plans for free. Get extensions for... Azure DevOps Services Visual Studio Visual Studio Code Get cloud subscriptions Buy cloud subscriptions in the Marketplace. Get started with REST APIs Learn the basic patterns for using the REST APIs for Azure DevOps. Authorization Get authorization from your customers to access Azure DevOps Services resources using OAuth 2.0. REST API reference Use the REST APIs to work with Azure DevOps resources. .NET client libraries For .NET developers building Windows apps and services that integrate with Azure DevOps, client libraries are available for integrating with work item tracking, version control, build, and other services are now available. These packages replace the traditional TFS Client OM installer and make it easy to acquire and redistribute the libraries needed by your app or service. REST API samples Here are a number of samples that work with the REST APIs directly. C# client library samples Here are a few quick samples to help you get started with the client libraries. Integrate with service hooks Service hooks enable you to perform tasks on other services when events happen in your Azure DevOps Projects Create integrations Integrate other services like HipChat, Slack, and UserVoice with Azure DevOps using service hooks. Authorize Authorize other services to access your organization using the industry standard OAuth 2.0. Oauth 2.0 provides safe, secure access to your resources like work items, source code and build results by those other services.
- 269. Global Currently, the visualstudio.com content is only available in English. Monitor Application Insights (Preview) Web portal preferences Choose your name to access your profile settings and set your web portal preferences which include language (currently only English is supported for Azure DevOps), date and time pattern, and time zone. Language Interface Packs (LIPs) By using a Windows Language Interface Pack (LIP), you can install a language version of Windows, and then install various User Interface Language Packs. Language packs switch your English Visual Studio Professional user interface into any of these languages and have a majority of the user interface localized. Localized content Most content that supports Azure DevOps is localized into the following 14 languages. English Chinese Simplified Chinese Traditional Czech German French Italian Japanese Korean Polish Portuguese (Brazil) Russian Spanish Turkish Visual Studio language pack Install the language pack to switch the UI display to different languages. Visual Studio provides localized UI support for these 14 languages. English Chinese Simplified Chinese Traditional Czech German French Italian Japanese Korean Polish Portuguese (Brazil) Russian Spanish Turkish Eclipse plug-in language support Install Team Explorer Everywhere, which includes language support for English, French, German, Japanese, and Simplified Chinese.
- 270. HockeyApp What is Application Insights Application Insights, an extensible analytics service that monitors your live web application, supports developers to continuously improve the performance and usability of apps. With it you can detect and diagnose performance issues, and understand what users actually do with your app. Web site availability monitoring Know when your site or service goes down by setting up tests and performance thresholds to monitor both uptime and responsiveness. Web site performance & usage Open the Performance blade to see request, response time, dependency and other data. Power BI integration Get even more flexible views of your telemetry, and present your web app telemetry alongside data from devices and other business sources. Dashboard Get the full picture with customizable dashboards that track application health alongside usage metrics and app crashes. Within the dashboard, you can filter, search, and drill down to an event instance for more detail or to segment data. Diagnose failures and exceptions Quickly diagnose causes and correlate failed requests with exceptions and other events at both the client and server. Usage analysis Gain a clear view of where your users are coming from and how they use your app . Add custom instrumentation to determine usage patterns and next version investment areas. Diagnose dependency issues See how long your application waits for dependencies and how often a dependency call fails. Dependencies are external components that your app calls such as an HTTP service, database, or file system. Custom data collectors Add custom data collectors to your app using the Application Insights API to customize your telemetry data. Continuous data export Perform custom analysis on your telemetry through continuous export of your data. Get HockeyApp for mobile app development Distribute mobile apps for testing, collect user metrics and feedback, and respond to crashes more easily by adding HockeyApp to your Agile, continuous integration, and continuous delivery workflows. Simplified distribution Manage distribution of development and production versions of your apps and use independent bundle identifiers that can run in parallel on the same device. Integrate with Azure DevOps Integrate HockeyApp directly in Azure DevOps to upload your Android, iOS, or Windows builds. Comprehensive dashboard Manage all your apps, users, and devices from a single dashboard. Monitor crashes and feedback as well. As an admin, you'll have full control over which user can see and install which app. Invite or recruit testers Invite beta testers and distribute your beta versions through the dashboard. Usage Get advanced metrics to understand the testing performed on your app. See which devices were tested, which testers used the app for how long, and which language was tested. Crash reports Get the information you need to analyze and respond to crashes by getting symbolicated stack traces and environment details. Webhooks Use webhooks to receive notifications about new versions, crash groups, and feedback.
- 271. Navigation Web portal Operational hubs Each hub—Home, Code, Work, build, and Test—supports specialized functions to share information, view and create dashboards, collaborate on code, plan and track work, build and test your applications, plus much, much more. Project page To view and quickly go to teams, team projects, branches, work items, pull requests and other objects that are relevant to you, use your Project page. Your profile and preferences Choose your name to access your profile settings, set preferences, create personal access tokens (Azure DevOps Services), set alerts, and log-in or out. Switch team context Go to a different team or project from the top row. Change team settings Customize features to meet your team needs by configuring your team assets. Home Provide team guidance through Welcome (Markdown format) pages and add team dashboards to monitor progress and trends. Code Manage source code using distributed Git repositories or Team Foundation version control. to Work Plan and track work by creating a product backlog, and managing work using Kanban or Scrum processes. Find work items you want to review or update by creating queries, or visualize progress by creating query-based charts Build Define and monitor builds and set up continuous builds to improve the quality of your app. Test Create and run manual tests for your app. Package (Azure DevOps Services, Preview) Share code as binary assets and control dependencies by subscribing to and working with Azure Artifacts feeds. Release (Azure DevOps Services, Preview) Manage the release of your app by deploying it to a specific environment for each separate release step, and by controlling the process through approvals for each step. Code search Search within your code branches (TFVC) and repositories (Git) to find files, commits, and more using powerful filters to obtain rich results. Collection-project-team structure The collection-project-team structure provides teams a high- level of autonomy to configure their tools in ways that work for them. It also supports administrative tasks to occur at the appropriate level. My favorites From any context, you can drag folders, queries, or builds to My favorites when working in the Code, Work, or Build hubs to provide quick access to those items. Team favorites From your team context, drag shared queries, builds, and folders to Team favorites to provide quick access to those items. Project admin context Open the admin context to add teams and manage permissions. From any project hub, choose to open the admin context. Project collection admin context
- 272. Search, queries, and filters Keyboard shortcuts Increase your productivity by working with hot keys and shortcuts. Find work items When in the Work hub, enter IDs or keywords to start a query to find work items that you want to review, triage, or update. From the collection admin context, you can manage collection-level permissions, and set build policies, and manage extensions. Choose to open the admin context, and then choose DefaultCollection. Quick work item search Find work items based on ID, assignment, changed date, or keyword. Code search Find code based on keywords and search filters across your Git repositories. CodeLens search Find references and changes to your code, linked bugs, work items, code reviews, and unit tests. Work item queries Open shared queries or create your own query using the query editor to list work items or show hierarchical or dependent items. >Manage risks and dependencies Link work items to track related work, dependencies, and changes made over time. History & auditing Review and query work item change history to learn of past decisions and support future ones. Bulk add or modify using Excel Bulk add items to track or modify multiple field values using Excel. Charts Turn your queries into a status or trend chart and share them with your team, organization, and Stakeholders. Tags Add tags to work items to filter backlogs and queries. Bulk update work items to add or remove tags: Azure DevOps Services | Azure DevOps Server. Bulk modify Edit or update multiple work items from any backlog or query result. Supported tasks include: Modify field values Add or remove tags Reassign Move to an iteration Delete Link to a new or existing work item Change work item type Move to another project Create a new Git branch Query by date or current iteration List work items based on when changes occurred or if they belong to the team's current sprint. Query by workflow Find and list work items based on their current state, such as new, in progress, resolved, done, or closed. Query by Kanban board change Track status and trends of work items based on changes made to the Kanban board.
- 273. Security Manage users and groups Add users to built-in groups to grant them access to your project. Optionally, create groups to customize access based on your business requirements. Permission states Understand how Allow, Deny, Not set and other permissions states control access to features and objects. Manage work access (Azure DevOps Services) Control user access with a directory to enforce policies about accessing company resources. Azure Active Directory (Azure DevOps Services) Easily control access to your team's critical resources and key business assets with Azure Active Directory groups. Set up groups (Azure DevOps Server) Create Windows or Active Directory groups to manage access to your team projects and collections. Built-in groups Understand the permissions granted to built-in groups and use them to manage access to your team projects and collections. DevOps permissions Grant or restrict access to: Git repositories Git branches TFVC source code and folders Build Test) Release Work item tracking permissions Control access to specific features by setting permissions for a user or group. Area and iteration paths Query permissions Work item tags Move work items to another project Permanently delete work items Provide feedback through the Microsoft Feedback client Team admin role and permissions Add users as team administrators to enable them to configure team settings and manage team assets. Manage administrative permissions Add users to one of the following built-in groups to provide them permissions assigned to that group: Project Administrators, who manage shared features for a project Project Collection Administrators, who manage collection-level features Azure DevOps Server Administrators, who manage on-premises application servers Restrict access You can restrict access to several features and tasks by setting the permission state to Deny to individual users or a security group. Stakeholder access Grant Stakeholders, non-licensed users, limited access to contribute ideas and access team dashboards. Query permissions Grant permissions to create shared queries and query folders. Process permissions To customize a process, add custom fields, or change the layout of a work item form, you must be a member of the Project Collection Administrators group or be granted explicit permissions to edit a specific process. Valid users Understand how valid user groups are populated and the permissions they're granted. Permission reference Provide or restrict access for practically any feature, function, or object at the collection or project level. SharePoint permissions (Azure DevOps Server) Grant permissions to view and contribute to SharePoint project portals. SQL Server reporting permissions (Azure DevOps Server) Grant permissions to view and author Excel and SQL Server reports.
- 274. Set up and installation Teams, team projects, and processes Processes and process guidance Free developer offers To get started, download and install Visual Studio an integrated development environment (IDE) that works with Azure DevOps. Migrate from on-premises to hosted You can migrate source code and work items from an on-premises Azure DevOps Server to the cloud. Sign up for Azure DevOps Services Store your code, tests, and test results in the cloud with Azure DevOps Services, as well as plan your project and track progress. Install Azure DevOps Server Download and install the latest version of Azure DevOps Server. Azure DevOps Server provides the collaboration hub to support your teams DevOps tasks. at the center of the Microsoft devops solution. Email configuration (Azure DevOps Server) For feedback requests, alerts, and other special controls to work, you must configure an SMTP server for your on-premises Azure DevOps. Automated, scheduled backups (Azure DevOps Server) Reduce the risk of lost data by scheduling automated backups of the data store. Built-in SQL Server database (Azure DevOps Server) For small teams, you can install Azure DevOps Server using SQL Server Express which installs with Azure DevOps Server. What is a process? A process defines the building blocks of the work item tracking system as well as other sub- systems you access through your project. Compare and choose a process Compare the three core system processes--Agile, Scrum, CMMI-- before you choose one to create a project. Agile process Choose Agile when your team uses Agile planning methods, including Scrum, and tracks development and test activities separately. With Agile, you can track user stories and bugs on the Kanban board, or track bugs and tasks on the task board. Kanban process tools You can use the Kanban board with any process--Agile, Scrum, CMMI--or project that you select or create. Agile Kanban tools support working with the Kanban board, adding task checklists, setting WIP limits, custom columns, split columns, custom swimlanes, and customizing cards. Scrum process Choose Scrum when your team practices Scrum and you want to track product backlog items (PBIs) and bugs on the Kanban board, or break PBIs and bugs down into tasks on the task board. Scrum work items and workflow process guidance Scrum process tools Scrum processes can be used with any process--Agile, Scrum, CMMI- -or project that you select or create. Agile Scrum tools support sprint planning, capacity planning, task boards, and burndown charts. Manage processes (Azure DevOps Services) Add users to built-in groups to grant them access to your project. Optionally, create groups to customize access based on your business requirements. CMMI process Choose CMMI when your team follows more formal project methods that require a framework for process improvement and an auditable record of decisions. CMMI supports tracking requirements, change requests, risks, and reviews.
- 275. Process templates (Azure DevOps Server) Team projects Customize a process (Azure DevOps Services) Customizations you make to an inherited process automatically update all team projects that reference that process. You can customize your project as follows: Add and modify fields Modify the web form layout Modify the workflow states Add a custom work item type Manage processes (Azure DevOps Services) Create inherited processes and migrate team projects to use them. Set the default process and enable, disable, or delete processes you no longer want to use. Plan and track your work using the work item types and workflow supported by the Scrum process. Agile work items and workflow process guidance Plan and track your work using the work item types and workflow supported by the Agile process. Work item field index For descriptions and usage of each field used by the core and inherited processes, see Work item field index. CMMI work items and workflow process guidance Plan and track your work using the work item types and workflow supported by the CMMI process. What is a process template? A process template is the forerunner and on-premises version of a process. It provides the building blocks of the work item tracking system as well as other sub-systems you access through your project. Process templates support full customization of all its objects. Manage process templates Download and upload process templates to support customization and upgrade of your work tracking experience and team projects. Process template files You customize the initial configuration of team projects by customizing one or more process template files. By customizing these files, you can define the initial configuration of all team projects that are created from the process template. Configure Features Wizard Use the Configure Features Wizard to configure team projects after an Azure DevOps Server upgrade to access new features. Changes made to process templates For a catalog of changes, see Changes made to process templates. Customize the Microsoft Project field mapping file You can customize how work item fields that are defined in Team Foundation map to fields in Microsoft Project. And, you can change how specific fields are published.
- 276. Teams What is a project? A project provides a repository for source code and a place for a group of developers to plan, track progress, and collaborate on building software solutions. A project lives within a project collection. You can grant permissions to and customize a project to support your business needs. Create a project You can create a project hosted in the cloud (Azure DevOps Services), avoiding maintenance and administrative overhead, or create a project on an on-premises Azure DevOps Server. Rename a project Rename a project as needed to reflect changes that occur within your org. Delete a project Simplify the navigation to team projects that are in use by deleting team projects you no longer use. Collection-project-team structure The collection-project-team structure provides teams a high- level of autonomy to configure their tools in ways that work for them. It also supports administrative tasks to occur at the appropriate level. Change the process (Azure DevOps Services) You change the process of a project to apply customizations you've made to an inherited process. You can add and modify fields and modify the layout of each work item type defined for that process. View your work across teams and team projects From your Project page, you can view and quickly go to teams, team projects, branches, work items, pull requests and other objects that are relevant to you and that are stored in different team projects within the organization or collection. Customize a project (Azure DevOps Server) You customize a project defined on an on-premises Azure DevOps Server by modifying definition files for work item types or process configuration, or changing field attributes. Update a project after an upgrade (Azure DevOps Server) Some features added when you upgrade your on-premises application server may require you to configure features to access them. Upload reports (Azure DevOps Server) Upload the latest reports provided for your process or add reports after you've already created a project by adding SQL Server Reporting Services.
- 277. Traceability What is a team? A team is an organizing unit used to support a number of team- configurable tools to plan and manage work and facilitate collaboration. Add team members Add organizations-Azure DevOps Services | Azure DevOps Server-- to a team to enable users to share code, plan and track work, and access other team assets and resources. Add a team As your organization grows, consider moving from your default team of one to two or more teams to support feature-focused groups within your org. Add a team admin Add users to the team admin role to enable them to Manage teams and configure team tools. Team settings can only be configured by a team or project admin. Support Stakeholders Members within your org who don't have a license or contribute to developing the code base can track project priorities and provide direction, feature ideas, and business alignment to a team. Team dashboards Share progress, status, and guidance with your team using configurable team dashboards. Team welcome page Provide in-project guidance through the Welcome page and other pages you format using Markdown. Setup a team hierarchy By configuring your teams and backlogs into an hierarchical structure, program owners can more easily track progress across teams, manage portfolios, and generate rollup data. Set team defaults Several Agile tools reference the team's default area path, iteration path, and activated sprints to automatically filter the set of work items they display. Understand how defaults are used] (../organizations/settings/about- teams-and-settings.md). Select team sprints Select your team's sprints to gain access to sprint backlogs and task boards. Configure team settings Configure, customize, and manage all team-related activities Team alerts As changes occur to work items, code reviews, source control files, and builds, your team can automatically receive email notifications for alerts that you define. Team groups A team group is created when you create a team. Use this group in queries or to set permissions for your team.
- 278. Related articles Get started today using our cloud offering, Azure DevOps Services, or our on-premises Azure DevOps Server. Work item history & auditing Review and query work item change history to learn of past decisions and support future ones. Manage risks and dependencies Link work items to track related work, dependencies, and changes made over time. Create queries based on link type to monitor dependencies. Rich text comments Describe and comment on work to perform using formatted text, hyperlinks, and inline images. Discussion (Azure DevOps Services) Add or review comments added to a work item. Start by choosing . Git code changes Get detailed information about what changes have been made to your local and centralized branches and repositories, compare files and folders, review history of commits and file changes. Integrate Git development with work tracking (Azure DevOps Services) Drive Git development and stay in sync as a team to complete backlog items and tasks using the Git Development section. Add branches, create pull requests, and view all development performed to support the specific work item. TFVC code changes Get detailed information about what changes have been made to your files, compare files and folders, view where and when changesets have been merged, and view file changes using annotate. Build changes Determine who changed what in the build definition and when they did it. Release audit history Retain full audit history of all activities performed on a release with detailed release logs and approval tracking. Release logs View or download log files as zip files. Log files contain the status for each step or task of a release, for each of the environments in the release definition. Each completed release--succeeded, failed, or abandoned- -includes a live log file, details, and history for each step or task. We add new features frequently. We'll work to keep this list up-to-date. Other resources you might want to bookmark: Azure DevOps Services - Features update Azure DevOps Blog
- 279. Get started with Azure DevOps CLI 6/9/2022 • 2 minutes to read • Edit Online NOTE Command usage $ az devops -h Azure DevOps Services With the Azure DevOps extension for Azure Command Line Interface (CLI), you can manage many Azure DevOps Services from the command line. CLI commands enable you to streamline your tasks with faster and flexible interactive canvas, bypassing user interface workflows. The Azure DevOps Command Line Interface (CLI) is only available for use with Azure DevOps Services. The Azure DevOps extension for the Azure CLI does not support any version of Azure DevOps Server. To start using the Azure DevOps extension for Azure CLI, perform the following steps: az extension add --name azure-devops az devops configure --defaults organization=https://dev.azure.com/contoso project=ContosoWebApp 1. Install Azure CLI: Follow the instructions provided in Install the Azure CLI to set up your Azure CLI environment. At a minimum, your Azure CLI version must be 2.10.1. You can use az --version to validate. 2. Add the Azure DevOps extension: You can use az extension list or az extension show --name azure-devops to confirm the installation. 3. Sign in: Run az login to sign in. Note that we support only interactive or log in using user name and password with az login . To sign in using a Personal Access Token (PAT), see Sign in via Azure DevOps Personal Access Token (PAT). 4. Configure defaults: We recommend you set the default configuration for your organization and project. Otherwise, you can set these within the individual commands themselves. Adding the Azure DevOps Extension adds devops , pipelines , artifacts , boards , and repos groups. For usage and help content for any command, enter the -h parameter, for example:
- 280. Group az devops : Manage Azure DevOps organization level operations. Related Groups az pipelines: Manage Azure Pipelines az boards: Manage Azure Boards az repos: Manage Azure Repos az artifacts: Manage Azure Artifacts. Subgroups: admin : Manage administration operations. extension : Manage extensions. project : Manage team projects. security : Manage security related operations. service-endpoint : Manage service endpoints/service connections. team : Manage teams. user : Manage users. wiki : Manage wikis. Commands: configure : Configure the Azure DevOps CLI or view your configuration. feedback : Displays information on how to provide feedback to the Azure DevOps CLI team. invoke : This command will invoke request for any DevOps area and resource. Please use only json output as the response of this command is not fixed. Helpful docs - https://docs.microsoft.com/rest/api/azure/devops/. login : Set the credential (PAT) to use for a particular organization. logout : Clear the credential for all or a particular organization. Open items in browser az pipelines build show --id 1 --open Related articles You can use --open switch to open any artifact in Azure DevOps portal in your default browser. For example : This command shows the details of build with id 1 on the command-line and also opens it in the default browser. Sign in via Azure DevOps Personal Access Token (PAT) Output formats Index to az devops examples Azure DevOps CLI Extension GitHub Repo
- 281. Cross-service integration and collaboration overview 6/9/2022 • 16 minutes to read • Edit Online Collaboration across Azure DevOps Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 One of the major strengths of Azure DevOps is the integration it supports across its core services. Azure DevOps supports multiple integration points across each of the major services—Azure Boards, Azure Repos, Azure Pipelines, and Azure Test Plans. Review this article to understand how to use various features to support collaboration and traceability for all your devops tasks. Collaborating within and across teams is supported with many of the features summarized in the following table. Feature Description @mentions (add to discussions and comments) You can @mention a team member or an entire team within a work item form discussion or the comment section of a commit, pull request, or changeset. For details, see Use @mentions in work items and pull requests. #ID (link to a work item) To support end-to-end traceability, you can link to work items from commits, pull requests, and changesets. For details, see Link to work items from other objects. Teams Each team gets access to a suite of Agile tools and team assets. These tools let teams work autonomously and collaborate with other teams across the enterprise. Each team can configure and customize each tool to support how they work. For quick navigation, they can favorite repositories, pipelines, and test plans. To learn more, see: About teams and Agile tools Set personal or team favorites Unsubscribe from default notification Manage team, group, and Global notifications. Set up alerts Configure or opt out of personal, team, project, or organization-level alerts. Subscribe to email alerts when changes occur to work items, code reviews, pull requests, source control files, builds and more. To learn more, see: About notifications Manage personal notifications Unsubscribe from default notification
- 282. Azure Boards - Azure Repos Manage team, group, and Global notifications. Share summaries by email Email a list of work items Email query items Send release summaries by email Wiki Embed Azure Boards query results in Wiki. The following table summarizes the integration points between Azure Boards and Azure Repos. Through various link types, you can track code changes—commits and pull requests for Git, and changesets and versioned items for Team Foundation Version Control (TFVC)—that support development of user stories and features. The link types used to construct these links include Branch , Commit, Pull Request, and Tag for Git repositories, and Changeset, and Versioned Item for TFVC repositories. To learn more, see Link to work items from other objects, View list of linked objects. Feature Description Drive Git development from work item(s) You can initiate a Git branch or link to Git commits or pull requests and drive your Git development cycle for a work item from within the work item form. For details, see Drive Git development from a work item. Automatically link and transition work items with Git commits You can enable or disable the following options for a single Git repository:
- 283. Azure Boards - Azure Pipelines Automatically create links for work items mentioned in a commit comment Allow mentions in commit comments to close work items Remember user preferences for completing work items with pull requests. For details, see Configure branch policies to support integration. Check for linked work items in a Git branch Encourage traceability by checking for linked work items on pull requests. For details, see Configure branch policies to support integration. Auto complete work items with pull requests When you link a work item to a pull request (PR), you have the option to automatically complete those work items when you successfully complete the PR. The system defaults to your selection for future PRs. For details, see Auto complete of work items with pull requests. View list of code objects a single work item is linked to You can link work items to code changes, builds, and releases—providing an audit trail of how a feature has been developed The following table summarizes the integration points between Azure Boards and Azure Pipelines. Several features provide support for end-to-end traceability as user stories and features move through the development cycle. As with Azure Repos, you can link work items to pipeline objects with the following link types: Build, Integrated in build, and Integrated in release. Feature Description Manually link work items to builds. Link work items to builds in the same or other project within the organization or collection. Link work items to builds in the same project within the organization or collection. Set integration option to automatically create Integrated in build links to work items linked to a branch, commit, or pull request associated with a pipeline. Required to populate the Development control with Integrated in build links. The work items or commits that are part of a release are computed from the versions of artifacts. For example, each build in Azure Pipelines is associated with a set of work items and commits. For details, see Configure pipelines to support integration.
- 284. Set option and branch to automatically create Integrated in build and Integrated in release stage links to work items linked to a branch, commit, or pull request associated with a Classic or YAML pipeline. Required to populate the work item form Development control with Integrated in build links and the Deployment control with Integrated in release stage links when running a Classic or YAML pipeline. For details, see Configure pipelines to support integration. Set integration option to automatically create Integrated in release stage links to work items linked to a branch, commit, or pull request associated with a release. Required to populate Deployment control in work item form with Integrated in release stage links. For details, see Release pipelines, How do I integrate and report release status?. View list of work items linked to a Classic release pipeline Lists all work items linked to a build or release. View and open list of work items linked to a Classic or YAML pipeline. Lists all work items linked to a release since the previous selected release. Can sort the list by each column. View list of build or release objects a single work item is linked to You can link work items to builds and releases—providing an audit trail of how a feature has been built and deployed. To learn more, see Link to work items from other objects, View list of linked objects. Query for external links. You can query for work items that contain external links. For details, see Query by link or attachment count View and quickly navigate to release stages a work item is linked to. The work item form Deployment control lists set of stages work item is associated with. You can expand a stage to view status of select runs and quickly open each stage or run. For details, see Link and view work items to builds and deployments.
- 285. Azure Repos - Azure Pipelines Create a work item on failure, optionally set values for a work item field (Classic) Automatically create a work item and set fields when a build fails. For details, see Build options. Create a work item on failure (Classic or YAML), optionally set values for a work item field (Classic) Automatically create a work item and set fields when a build fails. For details, see Build options for Classic pipelines, and Customize pipelines, Create work item on failure. Query Work Items task. Ensure the number of matching work items returned from a query is within a threshold. Use this task to ensure the number of matching items returned by a work item query is within the configured thresholds. For details, see Query Work Items task, Control deployments with gates and approvals. Azure Pipelines provides support for building code stored in Azure Repos, either a Git or Team Foundation Version Control (TFVC) repository. Other repositories that Azure Pipelines supports are listed in Supported source repositories. The following table summarizes the integration features between Azure Repos and Azure Pipelines. Feature Description Report deployment status Indicates the status of a deployment on the Files, Commits, and Branches pages for Git repositories. This feature improves the traceability from code commit to deployment. You can configure the release environments to report deployment status. For details, see Release pipelines, How do I integrate and report release status?.. Release status badge
- 286. Azure Boards - Azure Repos - Azure Test Plans NOTE Post the status of your most recent pipeline build in your repository. To learn how, see Create your first pipeline, Add a status badge to your repository. Code coverage Publish and review code coverage results that indicate the proportion of your project's code that is actually being tested. To learn more, see Publish Code Coverage Results task and Review code coverage results. Several collaboration scenarios are supported through Azure Boards work item types. As with other work item types, you can use managed queries and the Azure DevOps search function to find and list work items. Several of these work item types—such as Feedback Request, Code Review Request, Shared Steps, and Shared Parameters — are designed to be created through a specific tool or form. They aren't meant to be created manually. Therefore, they are added to the Hidden Types category. Work item types that are added to the Hidden Types category don't appear in the menus used to add work items. Also, for the Inherited process model, you can only customize the following work item types: Test Plan, Test Suite, Test Case. Scenario Work item type Description Request code review Code Review Request Tracks information entered into the TFVC New Code Review form. To learn more, see Get your code reviewed with Visual Studio. Provide code review Code Review Response Tracks review comments provided by code reviewers in response to a code review request. To learn more, see Respond to the code review request. Request feedback Feedback Request Tracks information entered into a request feedback form. There are two forms that you can use to initiate a feedback request. Request stakeholder feedback Get feedback. Provide feedback Feedback Review
- 287. Test work item types Enables stakeholders to provide feedback based on request for feedback or by volunteering feedback using the Microsoft Test & Feedback marketplace extension. To learn more, see the following articles: Provide feedback Voluntarily provide stakeholder feedback Give feedback. Manual testing Test Plan Groups one or more test suites and individual test cases together. Test plans include static test suites, requirement-based suites, and query-based suites. To get started, see Create test plans and test suites. Manual testing Test Suite Groups one or more test cases into separate testing scenarios within a single test plan. Grouping test cases makes it easier to see which scenarios are complete. To learn more, see Create test plans and test suites. Manual testing Test Case Defines steps used to validate individual parts of your code to ensure your code works correctly, has no errors, and meets business and customer requirements. You can add individual test cases to a test plan without creating a test suite. More than one test suite or test plan can refer to a test case. You can effectively reuse test cases without having to copy or clone them for each suite or plan. To learn more, see Create manual test cases. Manual testing Shared Steps Enables sharing steps across several test cases. For details, see Share steps between test cases. Manual testing Shared Parameters Enables repeating the same test cases with different data. For more information, see Repeat a test with different data. Work item types that support the test experience are linked together using the link types shown in the following image. These include Tested By/Tests, Test Cases/Shared Steps, and Reference By/References.
- 288. Bug tracking Azure Pipelines - Azure Test Plans From the web portal, you can view which test cases are defined for a test suite, and which test suites are defined for a test plan. However, these objects aren't connected to each other through specific link types. When tracking bugs using the Bug work item type, note the following supported integrations. Scenario Description Create a bug from a testing tool You can add a bug from Test Runner or the Test & Feedback extension. To learn more, see Define, capture, triage, and manage bugs. Create inline tests linked to bugs or user stories When your team tracks bugs as requirements, you can use the Kanban board to add tests to verify bug fixes or user stories. To learn more, see Add, run, and update inline tests. Track build information with bugs The Bug work item form contains System Info, Found in Build, and Integrated in Build that support tracking code defects found and resolved within pipeline builds. To learn more, see Query based on build and test integration fields. Azure Test Plans is fully integrated with Azure Pipelines to support testing within continuous integration/continuous deployment (CI/CD). Test plans and test cases can be associated with build or release pipelines. Pipeline tasks can be added to pipeline definitions to capture and publish test results. Test results can be reviewed via built in progress reports and pipeline test reports. The following table summarizes the integration points between Azure Pipelines and Azure Test Plans. Feature Description Test plans setting With test plan settings, you configure the Test Run settings to associate build or release pipelines and Test Outcome settings. To learn more, see Run automated tests from test plans Pipeline test-enable tasks Specify test-enable tasks within a pipeline definition. Azure Pipelines provides several tasks, including those listed below, that support a comprehensive test reporting and analytics experience. Publish Test Results task: Use to publish test results to Azure Pipelines. Visual Studio Test task: Use to run unit and functional tests (Selenium, Appium, Coded UI test, and more) using the Visual Studio Test Runner. .NET Core CLI task: Use to build, test, package, or publish a dotnet application. For additional tasks, see Publish Test Results task Run automated tests in build pipelines Associate test plans with a build pipeline so that they run with each build. To learn more, see Run automated
- 289. Dashboards, reporting, and Analytics tests from test plans. Associate automated tests with test cases See Associate automated tests with test cases Set retention policy for automated test results associated with builds You can set the test retention policy for automated buidls from the Pipelines>Retention page. See Set test retention policies Requirements traceability The Requirements quality widget supports tracking quality continuously from a build or release pipeline. The widget shows the mapping between a requirement and latest test results executed against that requirement. It provides insights into requirements traceability. to learn more, see Requirements traceability. Test results trend The Test results trend configurable widget displays the trend of test results for the selected build or release pipeline. The widget helps you visualize the test trends over a period of time, thereby surfacing patterns about test failures, test duration etc. To learn more, see Configure the Test Results Trend (Advanced) widget Deployment status The Deployment status configurable widget shows a combined view of the deployment status and test pass rate across multiple environments for a recent set of builds. You configure the widget by specifying a build pipeline, branch, and linked release pipelines. To view the test summary across multiple environments in a release, the widget provides a matrix view of each environment and corresponding test pass rate. See Associate automated tests with test cases View test results in builds and releases Both build and release summaries provide details of test execution. Review these summaries to assess pipeline quality, review traceability, and troubleshoot failures. Choose Test summary to view the details in the Tests tab. To learn more, see Review test results, Tests tab. Test analytics for builds Each build summary includes an Analytics tab that hosts the Test analytics report. To learn more, see Test Analytics Dashboards provide an easy way to monitor progress and status. Using widgets, teams can add configurable widgets to support their goals. To learn more, see About dashboards, charts, reports, & widgets. The Analytics service is the reporting platform for Azure DevOps, replacing the previous platform based on SQL Server Reporting Services. Built for reporting, Analytics is optimized for fast read-access and server-based aggregations. The Analytics service provides: Analytics widgets that you can add to your dashboards In-context Analytics reports available from select Azure DevOps pages Rollup bars and counts for Azure Boards backlogs Custom reports you can create using Power BI Custom reports you can create using OData queries
- 290. Dashboards and reporting Support to develop and add your custom Analytics widgets you can add to dashboards To learn more, see What is the Analytics service? Dashboards provide an easy way to monitor progress and status. Using widgets, teams can add configurable widgets to support their goals. To learn more, see About dashboards, charts, reports, & widgets. SQL Server reports provide additional monitoring capabilities. To learn more, see Reporting Services reports. Built-in widgets you can add to your dashboard are listed below. They are organized under the service they support. You may find additional widgets from the Azure DevOps Marketplace. Widgets are annotated as follows: Analytics: Widget derives data from Analytics data Build: Widget derives data for a selected build pipeline Project: indicates you can select the project and team when configuring the widget Release: Widget derives data for a selected release pipeline Team: Widget is scoped to a single team Teams: Widget is scoped to one or more teams User: Widget is scoped to the logged in user account Build: Widget derives data for a selected build pipeline Release: Widget derives data for a selected release pipeline Team: Widget is scoped to a single team User: Widget is scoped to the logged in user account Boards Assigned to me (User) Burndown chart (Analytics, Project, Teams) Burnup chart (Analytics, Project, Teams) Chart for work items Cumulative flow diagram (Team) Cycle time (Analytics) (Analytics, Team) Lead time (Analytics) (Analytics, Team) New Work item Query results Query tile Sprint burndown (Analytics, Team) Sprint burndown - Legacy (Team) Sprint capacity (Team) Sprint overview (Team) Velocity (Analytics, Team) Work links Boards Assigned to me (User) Burndown chart (Analytics) Burnup chart (Analytics)
- 291. Chart for work items Cumulative flow diagram Cycle time (Analytics) (Analytics) Lead time (Analytics) (Analytics) New Work item Query results Query tile Sprint burndown Sprint capacity Sprint overview Velocity (Analytics) Work links Work Assigned to me (User) Chart for work items New Work item Query results Query tile Sprint burndown Sprint capacity Sprint overview Work links Code Code tile (Repository, Branch, Folder) Pull request (Team, User) Code Code tile (Repository, Branch, Folder) Pull request (Team) Pipelines Build history (Build pipeline) Deployment status (Build pipeline) Release pipeline overview (Release pipeline) Requirements quality (Query, Build or Release pipeline) Test Plans Chart for test plans Test results trend (Advanced) (Analytics, Build or Release pipeline) Test results trend (Build or Release pipeline) Information and links Embedded web page Markdown
- 292. Data available from Analytics Other links Team members (Team) Visual Studio Shortcuts Welcome Build & Release Build history (Build pipeline) Deployment status (Build pipeline) Release pipeline overview (Release pipeline) Requirements quality (Query, Build or Release pipeline) Test Chart for test plans Test results trend (Build or Release pipeline) Information and links Embedded web page Markdown Other links Team members (Team) Visual Studio Shortcuts Welcome Analytics provides the reporting platform for Azure DevOps. Analytics is generally available for Azure DevOps Service and Azure DevOps Server 2020. It is in preview for Azure DevOps Server 2019. You can access the following data from Analytics. Service Data availability Azure DevOps Services Azure DevOps Server 2020 Azure DevOps Server 2019 Boards Widgets In-context reports OData Power BI ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️
- 293. Related articles ✔ ️ ✔ ️ Repos None Pipelines Test Analytics Pipeline Analytics OData Preview ✔ ️ ✔ ️ ✔ ️ ✔ ️ Test Plans Progress Report ✔ ️ Artifacts None End-to-end traceability Data model for Analytics
- 294. Azure DevOps and GitHub integration overview 6/9/2022 • 6 minutes to read • Edit Online Sign-in with GitHub credentials Azure Boards and GitHub integration Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 Azure Boards and Azure Pipelines provide several integration points with GitHub and GitHub Enterprise. Azure DevOps simplifies deployment from your repository with seamless access to the Azure portal and Azure DevOps using your GitHub account credentials. Feature Description Invite GitHub collaborators into Azure DevOps Provides support for inviting GitHub account users to collaborate within an Azure DevOps project. For details, see Invite GitHub collaborators into Azure DevOps (Release Notes). Sign into Azure DevOps using your GitHub credentials Allows users to sign in using their GitHub credentials and link their GitHub account to a Microsoft account. For details, see Signing into Azure DevOps using your GitHub credentials (Release Notes). Connect to a GitHub repository from Visual Studio Provides a user interface to support cloning GitHub repositories, pushing and pulling commits, and more. For details, see Side-by-side comparison of Git and Team Explorer. By connecting Azure Boards with GitHub repositories, you enable linking between GitHub commits, pull requests, and issues to work items. You can use GitHub for software development while using Azure Boards to plan and track your work. To get started, see Azure Boards-GitHub integration. Feature Description Connect Azure Boards project to GitHub repos Supports establishing connection of one or more GitHub repositories to an Azure Boards project. For details, see Azure Boards-GitHub integration. Connect Azure Boards project to repositories hosted in a GitHub Enterprise Server instance Supports establishing connection of one or more GitHub repositories hosted in a GitHub Enterprise Server. For details, see Azure Boards-GitHub integration. Link work items to GitHub commits, pull requests, and issues. Quickly view and open linked objects from the Kanban board.
- 295. Azure Pipelines and GitHub integration Supports linking GitHub commits, pull requests, and issues to Azure Boards work items. Mentioned work items in GitHub comments are configured as hyperlinks to support quick navigation to Azure Boards work items. For details, see Link GitHub commits, pull requests, and issues to work items. Add status badges of Azure Boards to a GitHub repository README file. Supports adding Markdown syntax to a GitHub repo README.md file to display the status of a Kanban board. For details, see Configure status badges to add to GitHub README files. Work items linked to GitHub commit in Release Summary Review list of all work items linked to GitHub commits in the Release summary page. This helps teams track and retrieve more information about the commits that have been deployed to an environment. Sync GitHub Issues to Azure Boards Work Items Using the GitHub Action, GitHub Issues to Azure DevOps you can sync your GitHub Issues to your Azure Boards. For details, see Sync GitHub Issues to Azure DevOps Work Items (Release Notes). You can use Azure Pipelines to automatically build, test, package, release, and deploy your GitHub repository code. To get started, see Build GitHub repositories. You can map your GitHub repositories to one or more projects in Azure DevOps. Feature Description GitHub repository and pull request builds Automatically build pull requests from repository forks to ensure changes successfully build and tests pass
- 296. before they are merged. For details, see Build GitHub repositories. GitHub repository and pull request builds Automatically build your GitHub pull requests. After the build is done, status is reported back with a comment in your GitHub pull request. Manually run a pipeline or test suite triggered by a GitHub pull request comment. Configure draft PR validation for GitHub repository. Supports adding drafts to the pr trigger YAML syntax for GitHub draft pull requests. You can choose if you want your draft PRs to queue a build. The default option is true (a build will be queued) like it currently is for GitHub PRs. Rebuild GitHub pull request builds upon failure. Provides support for queueing a failed build. Configure draft PR validation for GitHub repositories Automatically build pull requests from repository forks to ensure changes successfully build and tests pass before they are merged. For details, see Build GitHub repositories. GitHub Enterprise builds Supports continuous integration (CI) builds for GitHub Enterprise repositories. For details, see Build GitHub repositories, CI triggers. GitHub Enterprise builds Supports continuous integration (CI) builds for GitHub Enterprise repositories. Create a pipeline to build code contained within a GitHub Enterprise repository using the the build pipeline wizard. For details, see Build GitHub repositories, CI triggers. GitHub service connections The pipeline wizard automatically creates and reuses a service connection for the repository you choose. If you wish to manually choose a connection other than the one that is automatically selected, follow the Choose connection hyperlink. For details, see Build GitHub repositories. GitHub-specific tasks and utilities Supported: Download GitHub Release task GitHub Release task Open source Azure Pipeline tasks Manage GitHub releases Inline GitHub connection as a release artifact source. Automate GitHub releases using the GitHub Release task. For details, see: CI triggers Download GitHub Release task Manage GitHub releases Inline GitHub connection as a release artifact source. Automate GitHub releases using the GitHub Release task. Link your GitHub releases as an artifact source in release pipelines. This function lets you consume the GitHub release as part of your deployments.
- 297. For details, see: CI triggers Download GitHub Release task GitHub Release task Filter GitHub branches for GitHub, GitHub Enterprise, or external Git artifacts When releasing from GitHub, GitHub Enterprise, or external Git repositories, you can configure the specific branches to release. For example, you may want to deploy only builds coming from a specific branch to production. For details, see Release triggers, Continuous deployment triggers. GitHub Actions to trigger a pipeline run automate your software development workflows from within GitHub. You can deploy workflows in the same place where you store code and collaborate on pull requests and issues. For details, see Quickstart: Trigger an Azure Pipelines run from GitHub Actions. Use build tags to trace GitHub sources Use build tags to trace GitHub sources to builds. While choosing a GitHub repository in a build definition, you can select the types of builds you want to tag, along with the tag format. For details, see Build GitHub repositories, Label sources. Use build tags to trace GitHub sources or trigger GitHub releases Use build tags to trace GitHub sources to builds. While choosing a GitHub repository in a build definition, you can select the types of builds you want to tag, along with the tag format. Use build tags to trace GitHub sources to builds. While choosing a GitHub repository in a build definition, you can select the types of builds you want to tag, along with the tag format. Specify a tag pattern to determine when to trigger a GitHub release. By specifying a tag regular expression, you can control when a GitHub release is created based on the triggering commit. For details, see Build GitHub repositories, Label sources. GitHub packages support in YAML pipelines In your YAML pipeline, specify a package type (NuGet or npm) that you want to consume from GitHub. For details, see Resources: packages. Status checks, tracking, and traceability GitHub Checks: Display status for each pipeline job: Run a pipeline or test suite to validate a GitHub pull request from the comments section of the GitHub pull request. GitHub Checks allows for sending detailed information about the pipeline status, test, code coverage, and errors. Status is posted to GitHub Checks for each job in the pipeline. Status badges: Supports adding Markdown syntax to a GitHub repo README.md file to display the pipeline status. GitHub artifacts show associated commits deployed in a release. To enhance traceability, you can see all the commits that were deployed to an environment for GitHub repositories, as a part of a specific release. Track GitHub commits and associated issues in releases. Lists commits made in GitHub repos and the associated GitHub issues that are being deployed with a release. For details, see Track GitHub commits and associated issues in releases (Release Notes). For details, see:
- 298. Related articles Create your first pipeline, Add a status badge to your repository. GitHub Checks API Display status for each pipeline job in GitHub Checks (Release Notes). Azure Boards-GitHub integration Build GitHub repositories Git experience in Visual Studio
- 299. Deploy to Azure 6/9/2022 • 6 minutes to read • Edit Online Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Azure Pipelines combines continuous integration (CI) and continuous delivery (CD) to test and build your code and ship it to any target. While you do not have to use Azure services with Pipelines, Pipelines can help you take advantage of Azure. You can use Pipelines to integrate your CI/CD process with most Azure services. To learn more about selecting an Azure service for hosting your application code, see Choose an Azure compute service for your application. If you're just getting started, we recommend you review and get started with the following resources. Azure service Integration points Azure DevOps Projects/Azure DevOps Starter Start using Azure Pipelines to automate the setup of a CI/CD of your application to Azure. Choose where to deploy your application such as Virtual Machines, Azure App Service, Azure Kubernetes Services (AKS), Azure SQL Database, or Azure Service Fabric. To learn more, see Overview of DevOps Starter. Azure portal The Azure portal is a web-based, unified console from which you can build, manage, and monitor everything from simple web apps to complex cloud deployments. Also, you can create custom dashboards for an organized view of resources and configure accessibility options. If you have an Azure DevOps Services organization, you have access to the Azure portal. Sign in to your Azure portal. DevOps solutions on Azure Use end-to-end solutions on Azure to implement DevOps practices throughout application planning, development, delivery, and operations. Apply the right combination of DevOps technologies, culture, and processes to enable continual software delivery and better value for customers. Get started with the following learn modules: Deploy applications with Azure DevOps Build applications with Azure DevOps Deploy and maintain cloud-native apps with GitHub actions and Azure Pipelines Load test Azure web apps by using Azure DevOps Follow the links provided in the following table to learn more about the Azure services that support continuous integration (CI) and continuous delivery (CD) using Azure Pipelines. For a complete list of Azure pipeline tasks, see Build and release tasks. Azure service Integration points
- 300. Azure App Service An HTTP-based service for hosting web applications, REST APIs, and mobile back ends; the Azure App Service employs Azure Pipelines to deliver CI/CD. To learn more, see: App Service overview Deploy an Azure Web App Deploy a web app to Azure App Service (Classic) Use CI/CD to deploy a Python web app to Azure App Service on Linux Continuously deploy from a Jenkins build Azure App Service Deploy task Azure App Service Manage task Azure App Service Settings task Azure App Configuration Service to centrally manage application settings and feature flags. To learn more, see the following articles: Push settings to App Configuration with Azure Pipelines Pull settings to App Configuration with Azure Pipelines. Azure Blob Storage Azure Storage Store and access unstructured data at scale using Azure Pipelines and Azure Blob Storage. Azure Static Web Apps Use Azure Static Web Apps to automatically build and deploy a full stack web app to Azure from a code repository. Tutorial: Publish Azure Static Web Apps with Azure DevOps Azure Container Registry Build, store, secure, scan, replicate, and manage container images and artifacts. For example, build and publish a private Docker registry service. To learn more, see Build and push Docker images to Azure Container Registry. Azure Databases Azure SQL Database Azure Database for MySQL Azure Cosmos DB Use Azure Pipelines to deploy to Azure SQL Database, Azure Database for MySQL, or Azure Cosmos DB. To learn more, see the following articles: Deploy to Azure SQL Database Azure SQL Database Deployment task Azure Database for MySQL Deployment task Quickstart: Deploy to Azure MySQL Set up a CI/CD pipeline with the Azure Cosmos DB Emulator build task in Azure DevOps Azure Databricks Azure Data Factory Azure Machine Learning Configure a pipeline to integrate with a fully managed, serverless data integration service and unlock insights
- 301. from all your data. Create an Azure Pipeline that builds and deploys a machine learning model as a web service and to automate the machine learning lifecycle. To learn more, see the following resources: Build a data pipeline by using Azure Data Factory, DevOps, and machine learning; Configure Azure Databricks and Azure Data Factory DevOps for Azure Databricks Prepare data, train, deploy, and monitor machine learning models with Azure Pipelines. Azure DevTest Labs Quickly provision development and test stages using reusable templates. To learn more, see Manage a virtual machine in Azure DevTest Labs. Azure Functions Provides a fully managed Platform as a service (PaaS) to implement serverless architecture. To learn more, see: Deploy an Azure Function Azure Function App task Azure Function App for Containers task Azure Government Use Azure Pipelines to set up CI/CD of your web app running in Azure Government.To learn more, see Deploy an app in Azure Government with Azure Pipelines. Azure IoT Edge Use Azure Pipelines to managed services built on Azure IoT Hub. To learn more, see Continuous integration and continuous deployment to Azure IoT Edge devices and Create a CI/CD pipeline for IoT Edge with Azure DevOps Starter. Azure Key Vault Use Azure Pipelines to managed services for storing secret data. To learn more, see Use Azure Key Vault secrets in Azure Pipelines and Azure Key Vault task. Azure Kubernetes Services (AKS) Deploy and manage containerized applications with a fully managed Kubernetes service. To learn more, see Build and deploy to Azure Kubernetes Service. Azure Monitor Configure alerts on available metrics for an Azure resource. Observe the configured Azure monitor rules for active alerts in a release pipeline. Define pre or post-deployment gates based on Query Azure Monitor Alerts. For details, see the following articles: Define approvals and checks, Query Azure Monitor Alerts Release deployment control using gates Azure Monitor Alerts task Query Azure Monitor Alerts task. Azure Policy Manage and prevent IT issues by using policy definitions that enforce rules and effects for your resources. To
- 302. learn how, see Check policy compliance with gates. Azure Resource Manager (ARM) ARM Templates Use ARM templates to define the infrastructure and dependencies and streamline authentication to deploy your app using Azure Pipelines. Specifically, you can: Create an ARM service connection using automated security Create an ARM service connection with an existing service principal Create an ARM service connection to a VM with a managed service identity Connect to an Azure Government Cloud Connect to Azure Stack To learn more, see Connect to Microsoft Azure. Azure Service Bus In a release pipeline, send a message to an Azure Service Bus using a service connection. To learn more, see Publish To Azure Service Bus task and Manage service connections, Azure Service Bus service connection. Azure Service Fabric Distributed systems platform that can run in many environments, including Azure or on-premises. To learn more, see the following articles: Tutorial: Deploy an application with CI/CD to a Service Fabric cluster and Service Fabric Application Deployment task. Azure Stack Build, deploy, and run hybrid and edge computing apps consistently across your ecosystems. To learn more, see Deploy to Azure Stack Hub App Service using Azure Pipelines. Azure Virtual Machines Azure Virtual Machine Scale Sets Simplify continuous delivery to Azure VMs using Azure Pipelines. To learn more, see these articles: Build an Azure virtual machine using an Azure RM template Deploy to Azure VMs using deployment groups in Azure Pipelines Tutorial: Deploy a Java app to a virtual machine scale set Azure WebApps Use publish profile to deploy Azure WebApps for Windows from the Deployment Center. To learn more, see the following articles: Deploy an Azure Web App Deploy an Azure Web App Container Azure App Service Deploy task Azure App Service Manage task Azure App Service Settings task
- 303. Web portal navigation in Azure DevOps 6/9/2022 • 6 minutes to read • Edit Online IMPORTANT Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 The web portal for Azure DevOps is organized around a set of services, as well as administrative pages and several task-specific features such as the search box. The service labels differ depending on whether you work from Azure DevOps Services or Azure DevOps on-premises and it's version. To view the content available for your platform, make sure that you select the correct version of this article from the version selector which is located above the table of contents. Feature support differs depending on whether you are working from Azure DevOps Services or an on-premises version of Azure DevOps Server. To learn which on-premises version you are using, see What platform/version am I using? Each service provides you with one or more pages which support a number of features and functional tasks. Within a page, you may then have a choice of options to select a specific artifact or add an artifact. The web portal for Azure DevOps Server is organized around a set of services—such as, Overview, Boards, Repos, Pipelines, Test Plans, and Artifacts— as well as administrative pages and several task-specific features such as the search box. Each service provides you with one or more pages which support a number of features and functional tasks. Within a page, you may then have a choice of options to select a specific artifact or add an artifact. Each service provides you with one or more pages which support a number of features and functional tasks. Within a page, you may then have a choice of options to select a specific artifact or add an artifact. The web portal for Team Foundation Server is organized around a set of applications—such as, Dashboards, Code, Work, Build and Release—as well as administrative pages and several task-specific features such as the search box. Each service provides you with one or more pages which support a number of features and functional tasks. Within a page, you may then have a choice of options to select a specific artifact or add an artifact. Here's what you need to know to get up and running using the web portal. Open a service, page, or settings: use to switch to a different service or functional area Add an artifact or team: use to quickly add a work item, Git repo, build or release pipelines, or a new team Open another project or repo: use to switch to a different project or access work items and pull requests defined in different projects, or items you've favorited Open team artifacts, use breadcrumbs, selectors and directories: use to navigate within a service, to open other artifacts or return to a root function Work with favorites: favorite artifacts to support quick navigation
- 304. NOTE Search box: use to find code, work items, or wiki content Your profile menu: use to set personal preferences, notifications, and enable preview features Settings: use to add teams, manage security, and configure other project and organization-level resources. Open a service, page, or settings: use to switch to a different service or functional area Add an artifact or team: use to quickly add a work item, Git repo, build or release pipelines, or a new team Open another project or repo, or switch to a different team: use to switch to a different project or browse teams Work across projects: use to quickly open work assigned to you, your active pull requests, or items you've favorited Open team artifacts, use breadcrumbs & selectors: use to navigate within a service, to open other artifacts or return to a root function Work with favorites: favorite artifacts to support quick navigation Search box: use to find code, work items, or wiki content Your profile menu: use to set personal preferences, notifications, and enable preview features Settings: use to add teams, manage security, and configure other project and organization-level resources. Only those services that are enabled will appear in the user interface. For example, if Boards is disabled, then Boards or Work and all pages associated with that service won't appear. To enable or disable a service, see Turn an Azure DevOps service on or off. You select services—such as Boards, Repos, and Pipelines—from the sidebar and pages within those services. You select a service—such as Code, Work, and Build and Release—from the horizontal bar and pages within those services.
- 305. Connect to the web portal, user accounts and licensing Refresh the web portal Now that you have an understanding of how the user interface is structured, it's time to get started using it. As you can see, there are a lot of features and functionality. If all you need is a code repository and bug tracking solution, then start with the Get started with Git and Manage bugs. To start planning and tracking work, see About Agile tools. You connect to the web portal through a supported web browser—such as the latest versions of Edge, Chrome, Safari, or Firefox. Only users who have been added to a project can connect. This is typically done by the organization owner. Five account users are free as are Visual Studio subscribers and stakeholders. After that, you need to pay for more users. Find out more about licensing from Azure DevOps pricing. Limited access is available to an unlimited number of stakeholders for free. For details, see Work as a Stakeholder. You connect to the web portal through a supported web browser—such as the latest versions of Edge, Chrome, Safari, or Firefox. Only users who have been added to a project can connect. This is typically done by a member of the Project Administrators group. Limited access is available to an unlimited number of stakeholders for free. For details, see Work as a Stakeholder. Most regular contributors must have a TFS client access license (CAL). All Visual Studio subscriptions include a TFS CAL. Find out more about licensing from TFS pricing. If data doesn't appear as expected, the first thing to try is to refresh your web browser. Refreshing your client updates the local cache with changes that were made in another client or the server. To refresh the page or object you're currently viewing, refresh the page or choose the Refresh icon if available.
- 306. Differences between the web portal and Visual Studio NOTE Resources To avoid potential errors, you should refresh your client application under the following circumstances: Process changes are made Work item type definitions are added, removed, renamed or updated Area or iteration paths are added, removed, renamed or updated Users are added to or removed from security groups or permissions are updated A team member adds a new shared query or changes the name of a shared query A build definition is added or deleted A team or project is added or deleted Although you can access source code, work items, and builds from both clients, some task-specific tools are only supported in the web browser or an IDE, but not in both. Supported tasks differ depending on whether you connect to a Git or TFVC repository from Team Explorer. Web portal Visual Studio Product backlog,Portfolio backlogs, Sprint backlogs, Taskboards, Capacity planning Kanban boards Dashboards, Widgets, Charts Request feedback Web-based Test Management Administration pages to administer accounts, team projects, and teams Git: Changes, Branches, Pull Requests, Sync, Work Items, Builds TFVC: My Work, Pending Changes | Source Control Explorer, Work Items | Builds Greater integration with work items and Office-integration clients. You can open a work item or query result in an office supported client. Visual Studio 2019 version 16.8 and later versions provide a new Git menu for managing the Git workflow with less context switching than Team Explorer. Procedures provided in this article under the Visual Studio 2019 tab provide information for using the Git experience as well as Team Explorer. To learn more, see Side-by-side comparison of Git and Team Explorer. Manage projects Project & Organizational Settings
- 307. Open a service, page, or settings 6/9/2022 • 4 minutes to read • Edit Online Open a service or functional task page NOTE Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 The web portal for Azure DevOps provides support for software development teams to collaborate through the planning, development, and release cycles. You can manage source code, plan and track work, define builds, run tests, and manage releases. This article shows you how to navigate to functional and administrative tasks available from the web portal. There are three levels of administrative tasks: team, project, and organization. If you don't have a project yet, create one. If you don't have access to the project, get invited to the team. This article shows you how to navigate to functional and administrative tasks available from the web portal. There are four levels of administrative tasks: team, project, collection, and server. If you don't have a project yet, create one. If you don't have access to the project, get invited to the team. Services support getting work done—managing code, planning and tracking work, defining and managing pipelines, creating and running tests, and so on. Only those services that are enabled will appear in the user interface. For example, if Boards is disabled, then Boards or Work and all pages associated with that service won't appear. To enable or disable a service, see Turn an Azure DevOps service on or off. You open a service by choosing the service from the sidebar and then selecting from the available pages. For example, here we select Boards>Backlogs.
- 308. Open team settings Within the page you may select a specific view or artifact, such as a team backlog or choose another page. You open a service by choosing it from the horizontal blue bar. Then, select from the available pages. For example, here we select Work>Work Items. Select configurations are made to teams through the team settings pages. For an overview of all team settings, see About user, team, project, and organization-level settings. 1. Choose Project Settings.
- 309. 2. Expand Boards and choose Team configuration.
- 310. 3. Choose one of the pages General, Iterations, Areas, or Templates to configure settings for the team. To learn more, see Manage teams. 4. If you need to switch to a different team, use the team selector within the breadcrumbs. 5. To add a team administrator, add team members, or change the team profile, choose Teams from the vertical sidebar, and then choose the name of the team you want to configure. You open team settings from the top navigation bar. Select the team you want and then choose the gear icon. To learn more about switching your team focus, see Switch project, repository, team.
- 311. Open project settings 3. 1. Choose one of the pages General, Iterations, Areas, or Templates to configure settings for the team. To learn more, see Manage teams. 2. To add a team administrator, add team members, or change the team profile, choose Overview. Administrators configure resources for a project and manage project-level permissions from the Project settings pages. Tasks performed in this context can impact the project and team functions. For an overview of all project settings, see Project administrator role and managing projects. 1. Choose Project Settings. 2. From there, you can choose a page from the list. Settings are organized based on the service they
- 312. support. Expand or collapse the major sections such as Boards, Build and release, Code, Test, and Extensions to select from the list. From a user context, open Project settings by choosing the gear icon. Open any admin page by choosing it's name. Choose or hover over the gear icon to access other administrative options. Note that you can choose any of the user-context areas—Dashboards, Code, Work— to return to the user context.
- 313. Open Organization settings Open Collection settings Organization owners and members of the Project Collection Administrators group configure resources for all projects or the entire organization, including adding users, from the Organization settings pages. This includes managing permissions at the organization-level. For an overview of all organization settings, see Project collection administrator role and managing collections of projects. Members of the Project Collection Administrators group configure resources for all projects or the entire project collection from the Collection settings pages. This includes managing permissions at the collection-level. For an overview of all collection-level settings, see Project collection administrator role and managing collections of projects. 1. Choose the Azure DevOps logo to open Projects. Then choose Admin settings.
- 314. 2. From there, you can choose a page from the list of settings. Settings are organized based on the service they support. Expand or collapse the major sections such as Boards and Build and release to select a page from the list.
- 315. Open Server settings 1. Choose the gear icon to open Organization settings or Collection settings. 2. From there, you can choose a page. Settings are organized based on the service they support. Members of the Team Foundation Server Administrators group configure resources for the server instance from the Server settings pages. 1. From the web portal home page for a project, choose or hover over the gear icon and select Server settings.
- 316. Related articles 2. Choose Access levels, to set access levels for a member or group. For details, see Change access levels. If you don't see Access levels, you aren't a TFS administrator and don't have permission. Here's how to get permissions. Manage projects About team, project, and admin settings
- 317. Add an artifact or team artifacts 6/9/2022 • 3 minutes to read • Edit Online Add work items, queries, or other work tracking artifacts Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Select the service of interest to get started adding new artifacts or objects. For example, to add work items, choose Boards or Work. Some artifacts—such as a product backlog, Kanban board, portfolio backlogs—are added when you add a team. Prior to adding an artifact, make sure that you've selected the project and repository that you want to work in. You can quickly add a query or work item when working from a Boards or Work page. Choose a Boards page—such as Work Items, Boards, or Backlogs. Then choose the plus icon and select from the menu of options. From a Work page, you can add a work item from the menu of options as shown in the following image.
- 318. Add a pull request or Git repository Or, you can open one of the pages—Boards, Backlogs, Queries, or Plans—to add an artifact specific to each of these functional pages. To add other work tracking artifacts, see one of the following articles: To add a board, backlog, or sprint backlog, first add a team which will be associated with those artifacts Add a delivery plan Add a managed work item query Add work items. You can quickly add a pull request, Git repository, or work item using the Add menu when working from Code. Expand the Repos service and choose Files, Commits, or Pull Requests (Git repos) or Files, Changesets, or Shelvesets (TFVC). Then, choose the plus icon and select from the menu of options. For details on adding a Git repository, see Git repository. From Code, open the context menu for the current repository and choose New repository. For details on adding a Git repository, see Git repository From one of the other Code pages, you can add files or folders, a new branch, or a new pull request. Note that you can only add one TFVC repository per project, but an unlimited number of Git repositories. To learn more about Git artifacts, see one of the following articles:
- 319. Add build and release pipelines Add a team View teams already defined Git repository Git branch Git pull request Add work items Expand Pipelines and choose Builds or Releases. Then choose the plus icon and select from the menu of options. From Build and Release, choose Builds, Releases, or other page to add an artifact associated with that page. To learn more about adding other pipeline related artifacts, see the following articles: Deployment groups Task groups Variable groups Secure files Agile tools and dashboards are typically associated with teams. You add teams to a project. To learn more about teams, see About teams and Agile tools. To add a team, see Add a team and team members. To view the set of defined teams, open Project settings, and choose Overview.
- 320. Add a dashboard Add a wiki To view the set of defined teams, open the admin context for the project, and choose Overview. Dashboards are associated with a team or a project. Each team can create and configure a number of dashboards. And, any team member can create one or more project dashboards. To learn how, see Add a dashboard. Dashboards are associated with a team. Each team can create and configure a number of dashboards. To learn how, see Add a dashboard. If you don't have a wiki yet, you can add one. Once added, you can add and update pages to that wiki.
- 321. Related articles Create a wiki Add and edit wiki pages Publish a Git repository to a wiki Create a wiki Add and edit wiki pages Azure Artifacts Exploratory & Manual Testing
- 322. Use breadcrumbs, selectors, and directories to navigate and open artifacts 6/9/2022 • 3 minutes to read • Edit Online Organization and project breadcrumbs Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 To quickly navigate to a feature or artifact—such as a dashboard, repository, product backlog, Kanban board, build pipeline—you can use breadcrumbs, selectors, and directories. To navigate to the project summary page, choose the project link within the breadcrumbs. To navigate to the organization page with all projects defined for the organization, choose the organization link. Horizontal navigation doesn't provide a breadcrumb structure for the organization and project levels. Instead, you can select a recent team or project from the project/team selector. Choosing Browse all opens the projects page.
- 323. Selectors NOTE Example: Dashboard selector Selectors are used to select an artifact within the current page. Most Agile tools are defined for a team and therefore require selection of the team artifact or tool. Selectors are used to select an artifact within the current page. Most Agile tools are defined for a team and therefore require selection of the team as well as the specific page. When you navigate to a specific page or artifact, the system remembers your selection. You use selectors to choose a different artifact within the current page. Within Dashboards, you open a specific dashboard from the selector. This particular selector features these navigational elements: Search box for filtering dashboards based on a team name or keyword Two pages you can choose from: Dashboards you've favorited will appear at the top of the selector Add new dashboard feature Browse all dashboards - opens Dashboards>All Mine (dashboards you created) which are organized by team All (dashboards created by everyone) which are listed alphabetically Within Dashboards, you select the team whose dashboards you want to view.
- 324. Example: Backlogs Then, choose the name of the dashboard to view it. For example, here we open the Work in Progress dashboard. From the Boards>Backlogs page, you use the selector to switch to another team's backlog. Again, favorited backlogs appear towards the top of the menu. You can also filter the list based on a team name or keyword. Or, choose Browse all team backlogs to open the Backlogs>All page. (1) Select the team from the project/team selector, choose (2) Work, (3) Backlogs, and then (4) the product backlog, which is Backlog items (for Scrum), Stories (for Agile), or Requirements (for CMMI).
- 325. Artifact breadcrumbs and selectors Example: Queries folders and breadcrumbs To choose another team, open the project/team selector and select a different team or choose the Browse option. Within select pages, breadcrumbs are provided to support navigating within the page or opening an artifact. For example, when working in the Queries pages, you can navigate to a subfolder, folder, or page. Also, you can choose a query that you've favorited from the selector menu, Or, you can choose to browse all queries which returns you to the All Queries page.
- 326. Example: Pipeline folders and breadcrumbs Directories Breadcrumb-and-selector navigation elements are used within most services that support defining and organizing artifacts within folders. This includes Pipelines or Build and Release applications pages. Choose the Deployment breadcrumb link to return to the Deployment folder. Directories provide a filterable list of all artifacts defined for a service area. Often when you navigate to an application, it will open the application's directory. For example, here is the Boards>Boards directory.
- 327. It lists boards in the following order: Your last visited board Your favorited boards All boards of teams that you belong to All boards defined for the project in alphabetical order. Choose the filter icon to filter the list as described in Filter basics. From a specific page, you can open the directory from the breadcrumbs or a selector. For example, choose Browse all boards from the Boards selector. Open from breadcrumb Open from selector
- 328. Team profiles Open a team profile to quickly access items defined for a team. The team profile is available from the Overview>Dashboards, Boards>Boards, Boards>Backlogs, and Boards>Sprints pages. A panel opens that shows all items defined for the team.
- 329. Related articles You can filter the list to show only Dashboards, Boards, Backlogs, or Sprints by choosing from the menu. To view the team admins and members of the team, choose Members. To view or change the team configuration, choose Team Settings. You can then add team members, team admins, or navigate to team notifications, or team iterations and area paths. See also Manage and configure team tools.
- 330. About teams and Agile tools Add an artifact or team Set favorites Open a service or page Filter basics
- 331. Switch project, repository, team 6/9/2022 • 3 minutes to read • Edit Online Prerequisites NOTE View and open a project Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Several features depend on the project, repository, or team that you have selected. For example, dashboards, backlogs, and board views will change depending on the project and team you select. Also, when you add a work item, the system references the default area and iteration paths defined for the team context. Work items you add from the team dashboard (new work item widget) and queries page are assigned the team default iteration. Work items you add from a team backlog or board, are assigned the team default backlog iteration. To learn more, see About teams and Agile tools. You must be added to a project as a member of the Contributors or administrator security group. To get added, Add users to a project or team. If the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization, users added to the Project-Scoped Users group won't be able to access projects that they haven't been added to. To learn more, see Manage your organization, Limit user visibility for projects and more. From the Projects page you can quickly navigate to a project that you have permissions to view. 1. Choose the Azure DevOps logo to open Projects.
- 332. The projects you most recently viewed are displayed, followed by a list of all projects in alphabetic order. 2. Hover over the dots and you can open the service of interest for that project. 3. You can filter the project and team list using the Filter projects search box. Simply type a keyword contained within the name of a project or team. Here we type Fabrikam to find all projects or teams with Fabrikam in their name. 4. Choose Create Project to add a project. You must be an account administrator or a member of the Project Collection Administrators group to add a project.
- 333. From the Projects page you can quickly navigate to a project or a team that you've accessed or worked in previously. Projects and teams are listed in the order you've last accessed, with the most recent five projects accessed appearing first. All projects you've accessed are listed within the All section. 1. Choose the Azure DevOps logo to open Projects. The projects you most recently viewed are displayed, followed by a list of all projects in alphabetic order. 2. As you hover over a project or team, you can choose one of the links to go to Home or Dashboards, Code, Work, Build and Release, Test, or Wiki pages. Choose the star icon to mark the project as a favorite. 3. You can filter the project and team list using the Filter projects and teams search box. Simply type a keyword contained within the name of a project or team. Here we type Fabrikam to find all projects or teams with Fabrikam in their name.
- 334. View and open a repository 4. Choose New Project to add a project. You must be an account administrator or a member of the Project Collection Administrators group to add a project. 1. Choose Repos>Files. 2. Select the repository of interest from the repository selector.
- 335. 1. Choose Code. 2. Select the repository from the selector.
- 336. Switch to a different team Related articles From a user page, one under—Boards, Repos, Pipelines, or Test Plans—you can't switch to a different team, you can only select team artifacts. From a Project Settings>Work>Team configuration page, you select a team from the team selector breadcrumb. You can switch your team focus to one that you've recently viewed from the project/team selector. If you don't see the team or project you want, choose Browse… or choose the Azure DevOps logo to access the Projects page. Work across projects Add teams
- 337. Tutorial: Set personal or team favorites 6/9/2022 • 6 minutes to read • Edit Online Prerequisites Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Favorite those views that you frequently access. You can favorite all sorts of Azure DevOps features and tools —such as a project, repository, build pipeline, dashboard, backlog, board, or query. You can set favorites for yourself or your team. As your code base, work tracking efforts, developer operations, and organization grows, you'll want to be able to quickly navigate to those view of interest to you and your team. Setting favorites allows you to do just that. Team favorites are a quick way for members of your team to quickly access shared resources of interest. You favorite an item for yourself by choosing the star icon. The favorited item will then show up easily from one or more directory lists. You set favorites for a team through the context menu for the definition, view, or artifact. In this tutorial you'll learn how to view your personal favorites and to favorite or unfavorite the following views: Project or team Dashboard Team backlog, board, shared query, or other Azure Boards view Repository Build and release definition Test plans Project Shared query Repository Build and release definition Test plans You must connect to a project through the web portal. If you don't have a project yet, create one. To connect to the web portal, see Connect to a project. You must be a member of the Contributors or an administrators security group of the project. To get added, Add users to a project or team. To favorite projects, backlogs, boards, queries, dashboards, or pipeline views, you must have Stakeholder access or higher. To favorite repositories, or delivery plans, you must have Basic access or higher. To favorite test plans, you must have Basic + Test Plans access level or equivalent. You must connect to a project through the web portal. If you don't have a project yet, create one. To connect to the web portal, see Connect to a project. You must be a member of the Contributors or an administrators security group of the project. To get added, Add users to a project or team. To favorite projects, backlogs, boards, queries, dashboards, or pipeline views, you must have Stakeholder access or higher. To favorite repositories, or delivery plans, you must have Basic access or higher.
- 338. View personal favorites NOTE To favorite test plans, you must have Basic + Test Plans access level or equivalent. For details about the different access levels, see About access levels. Access views that you have favorited by choosing the inbox icon, and then choosing Favorites. If a service is disabled, then you can't favorite an artifact or view of that service. For example, if Boards is disabled, then the favorite groups—Plans, Boards, Backlogs, Analytics views, Sprints, and Queries and all Analytics widgets—are disabled. To re-enable a service, see Turn an Azure DevOps service on or off. 1. Access views that you have favorited by choosing the Azure DevOps logo to open Projects. 2. Choose My Favorites to quickly access any view or item that you've marked as a favorite.
- 339. Favorite a project or team 1. To favorite a project, open the project Summary page and choose the star icon. 2. To favorite a team artifact, open Boards>Boards or Boards>Backlogs. Select the team you want to favorite from the team selector and choose the star icon. 3. To favorite other team artifacts, choose the team icon, and then choose the star icon next to one of the listed artifacts.
- 340. Favorite a project Favorite a dashboard To favorite a project, open the project Summary page and choose the star icon. Or, you can favorite a project from the Projects page by choosing the star icon next to the project. 1. From Overview>Dashboards, open the selector and choose the Browse all dashboards option.
- 341. 2. The Mine page shows your favorited dashboards, and all dashboards of teams that you belong to. The All page (shown below) lists all dashboards defined for the project in alphabetical order. You can filter the list by team or by keyword.
- 342. Favorite a team's backlog, Kanban board, or other view TIP You can change the sort order of the list by choosing the column label. 3. To favorite a dashboard, hover over the dashboard and choose the star icon. Favoriting a dashboard will cause it to appear on your Favorites page and towards the top in the Dashboards selection menu. You can favorite several Agile tools for a team from a Boards page. 1. Choose Boards, and then choose the page of interest, such as Boards, Backlogs, or Sprints. For example, here we choose (1) Work and then (2) Backlogs. To choose a specific team backlog, open the selector and select a different team or choose the Browse all team backlogs option. Or, you can enter a keyword in the search box to filter the list of team backlogs for the project.
- 343. Favorite a shared query NOTE 2. Choose the star icon to favorite a team backlog. Favorited artifacts ( favorited icon) appear on your Favorites page and towards the top of the team backlog selector menu. Open Boards>Queries and choose the All page. Expand a folder as needed. Choose the star icon next to the query you want to favorite. Or, open the context menu of the query, and then select Add to Team Favorites, and then select from the list of teams. You must be a member of at least one team for the Add to Team Favorites option to be visible. If not visible, ask your project administrator or team administrator to add you to a team.
- 344. Favorite a delivery plan You can also set a query as a personal favorite by opening the query and choosing the star icon. Open Work>Queries. Next, open the actions icon menu of the shared query you want to favorite, and then select Add to my favorites or Add to team favorites.
- 345. Favorite a repository Favorite a build pipeline To learn more about delivery plans, see Review team Delivery Plans. To mark a delivery plan as a favorite, open the Boards>Plans page and choose the star icon next to the Delivery Plan. To mark a delivery plan as a favorite, open the Work>Plans page and choose the star icon next to the Delivery Plan. From any Repos page, open the repository selector and choose the star icon for the repository you want to favorite. From any Code page, open the repository selector and choose the star icon next to the repository you want to favorite. Open Pipelines>Builds and choose either Mine or Definitions page. Choose the star icon next to the build definition you want to favorite. Or, open the context menu of the build definition, and then select Add to my favorites or Add to team favorites.
- 346. Open Build and Release>Builds and choose either Mine or Definitions page. Choose the star icon next to the build definition you want to favorite. Or, open the context menu of the build definition, and then select Add to my favorites or Add to team favorites.
- 347. Favorite a test plan Unfavorite a view you've favorited Try this next To learn more about test plans, see Create a test plan and test suite. To mark a test plan as a favorite, open Test Plans>Test Plans and choose the star icon next to a test plan from the menu that shows All test plans. To mark a test plan as a favorite, open the Test>Test Plans page and choose the star icon next to a test plan from the menu that shows All test plans. You can unfavorite an artifact from your Favorites page. Choose the inbox icon, and then choose Favorites. Choose the favorited icon of a currently favorited artifact. Similarly, you can unfavorite an artifact from the same page where you favorited it. You can unfavorite an artifact from the Projects>Favorites page and choose the favorited icon of a currently favorited artifact. Similarly, you can unfavorite an artifact from the same page where you favorited it.
- 348. Related articles Follow a user story, bug, issue, or other work item or pull request Manage personal notifications Set your preferences
- 349. Filter lists, boards, and directories 6/9/2022 • 2 minutes to read • Edit Online NOTE Filter based on keywords, tags, or fields Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Several applications and pages support filtering, which is very useful when a large number of artifacts or items have been defined. Most directory views provide one or more filter functions. You can filter most items using keywords or a user name for an author of an item or where work is assigned to them. You can filter lists and boards in the following areas: Git repositories: Branches, Commits, Commit history, Pull Requests, Pushes, and Repositories Work tracking: Work Items, Kanban boards, Backlogs, Sprint Backlogs, and Taskboards Directories: Dashboards, Boards, Backlogs, Sprints, Queries, Builds, Releases Git repositories: Branches, Commits, Commit history, Pull Requests, Pushes, and Repositories Work tracking: Work Items, Kanban boards, Backlogs, Sprint Backlogs, and Taskboards You may have fewer or additional filter options based on the features you've enabled or the platform and version that you are working from. To turn filtering on, choose the filter icon. You can filter work items by typing a keyword or using one or more of the fields provided, such as work item type, assigned to, state, and tags. Based on the keyword that you enter, the filter function will list work items based on any visible/displayed column or field, including tags. Also, you can enter a value for an ID, whether or not the ID field is visible. The filtered set is always a flat list, even if you've selected to show parents.
- 350. Characters ignored by keyword filter criteria Filter directories Related articles The filter criteria ignores the following characters: , (comma), . (period), / (forward slash), and (back slash). Choose the filter icon to filter a directory list by keyword, team, or other supported field. Keywords apply to titles, descriptions, and team names. For example, here we turn filtering on for the dashboard directory. Commit history Working with Git tags Filter backlogs and queries Filter your Kanban board Add tags to work items
- 351. Get started with search 6/9/2022 • 6 minutes to read • Edit Online Prerequisites IMPORTANT Start your search with a keyword Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 You can quickly find work items, code files, wiki pages, or packages based on a keyword, wildcards, and other supported search filters with the search function. Take an at-a-glance look at all of the search features further in this article. Every project member can use the search functions, including project members granted Stakeholder, Basic, and higher levels of access. When searching across the organization or collection, only results for which a project member has access are listed. Stakeholder wiki search results are limited to provisioned wikis. Because published wikis require access to regular repositories, which Stakeholders don't have access to, results for published wikis don't appear in the search results. Similarly, Code search results don't appear for Stakeholders. For Code search, a Collection Administrator must Install and configure search. Start your search using a keyword. You can then apply other options, as needed, to broaden or narrow your search results.
- 352. Search features, usage, and examples If you get no results matching the input, try removing filters and retry the search. Broadening the search and after you view the search results, you can apply appropriate filters again and search again for relevant results. Check for the spelling of your search terms. Currently Work item search doesn't support ignoring of users' spelling mistakes. If there are lots of hits when you're using a wildcard search, such as when you're using a simple wildcard search string, you may see a message that no matching files are found. In this case, narrow your search to reduce the number of matches. Specify more characters of the word or words that you want to find, or add a condition or filter to limit the number of possible matches. Searches aren't case-sensitive. The following features apply to all searches, including work items, code, wikis, and packages. The following features apply to all searches, including work items, code, and packages. Search feature
- 353. Usage Example Keyword Search based on one or more keywords. validate finds instances that contain the word validate. Exact match Search based on an exact match, enclosed in double-quotes. "Client not found" finds instances that contain the exact phrase match Client not found. Wildcard Add wildcard characters, * and ? , to keywords to extend the search criteria. Add * at the end of a keyword to find items that start with the keyword. Add ? in the middle to represent any alphanumeric character. Use wildcard characters anywhere in your search string except as a prefix. You can use prefix wildcards with the other search filter functions. You can use more than one wildcard to match more than one character. alpha?version finds instances of alpha1version and alphaXversion. Browser* finds instances of BrowserEdge, BrowserIE, and BrowserFirefox. CodeSenseHttp* finds files containing words that start with CodeSenseHttp, such as CodeSenseHttpClient and CodeSenseHttpClientTest. Boolean operators Find two or more keywords using Boolean operators: AND , OR , and NOT (must be uppercase). Add parenthesis to clauses to support logical groupings. Because AND is the default operator, an entry of two keywords with no operator is the same as an AND search. Validate AND revisit finds files that contain both the words validate and revisit. Validate OR revisit finds files that contain either of the words validate or revisit. Validate NOT revisit finds files that contain the word validate but not the word revisit. (Validate NOT revisit) OR "release delayed" finds files that contain the word validate but not the word revisit or files that contain the phrase release delayed. Proximity Search for files based on vicinity using proximity operators: NEAR, BEFORE, and AFTER (must be uppercase). By default, proximity search looks for terms within five tokens distance. term1 BEFORE term2 returns all files where term1 occurs BEFORE term2 within a distance of five tokens between them. term1 AFTER term2 returns the same results as term2 BEFORE term1. term1 NEAR term2 returns all files where term1 is within five token distance from term2 in any direction. term1 NEAR term2 returns the same results as term1 BEFORE term2 OR term2 BEFORE term1 .
- 354. Search from a different page TIP TIP Special characters Escape the special characters ( , ) , [ , ] , : , * , and ? by enclosing them in a phrase delimited with double-quotes. Include special characters in a search string, or search specifically for special characters, according to the following rules: CodeA23?R finds files containing words that start with CodeA23 Have any alphanumeric character next, and end with R. For example, CodeA234R and CodeA23QR. Search for any special character that isn't a part of the query language. "flatten()" finds the literal string flatten(). Search for a literal occurrence of the double-quote character " by preceding it with the escape character and enclosing the search string in double-quotes. ""react-redux"" finds the literal string "react-redux". You can search from any of the following pages: The Projects page for the organization: starts a search across all projects. The Project overview page: automatically applies a filter to search within the selected project. The Boards page for a project: automatically displays recent work items and backlogs accessed by the user. Azure Repos, Pipelines, Test Plans, or an Artifacts page for a project: automatically displays functional filters for code searches. The wiki page for a project: automatically go to a wiki page you recently opened. Use the content type filter to access a page that you recently accessed. For more information about searching and filtering in Azure Boards, see Filter backlogs, boards, and plans. For more information about searching wikis, see Provisioned vs. published wiki. No results found for ... If there's a large number of hits when using a wildcard search, such as when using a very simple wildcard search string, you may see a message that no matching files were found. In this case, narrow your search to reduce the number of matches. For example, specify more characters of the word(s) you want to find, or add a condition or filter to limit the number of possible matches.
- 355. Additional search functions NOTE Search re-index requirements Marketplace extensions To search for various settings, users, projects, and more, see the following table for other types of search tasks and corresponding actions. Search task Action Find an organization setting Go to your organization and select Organization settings. Find a project setting Go to your project and select Project settings. Find a user setting Go to your User settings page. Find a user Go to your organization and select Organization settings > Users, and then enter the name in the filter box. Find an organization Scroll through the left side of your screen, which lists all organizations. Find a project Go to your organization, and then enter the project name in the Filter projects box. View file history and compare versions Go to Repos > Files, highlight your file, and then select History. When you search from the Organization settings page, your search results include both organization-level and project-level settings. Search for Azure DevOps Server has the following limitation: If you do a disaster recovery (DR) operation and move your server back to an earlier snapshot of your SQL database, re-index all your collections. Code search - Extends search with fast, flexible, and precise search results across all your code. Required for searching repositories. Azure Paths Search - Adds a special search hub to Boards for searching within iterations and area paths without having to create and maintain custom queries.
- 356. NOTE Next steps Related articles Some extensions aren't supported features of Azure DevOps and therefore aren't supported by the product team. For questions, suggestions, or issues you have when using these extensions, visit their corresponding extension page on the Visual Studio Marketplace. Functional work item search or Functional code search or Functional artifact or package search Code search blog posts Work item search blog posts
- 357. Manage or enable features 6/9/2022 • 4 minutes to read • Edit Online NOTE Azure DevOps Services | Azure DevOps Server 2020 As new features are introduced, you can turn them on or off. That way, you can try them out, provide feedback, and work with those features that meet your requirements. Some preview features provide access to entire new functionality. Others, such as the New Wiki experience, reflect a change to the user interface, but little or no change in functionality. It may take up to three weeks after a release to Azure DevOps Services for the preview feature to appear in your organization. The latest release notes usually provide information on new preview features. You can turn on or off select features for Azure DevOps Services. Preview features become available first on Azure DevOps Services and then become standard features with an update to Azure DevOps Server. At some point, the preview feature moves out of preview status and becomes a regular feature of the web portal. There are a few features you or an administrator can enable or disable. Some features provide access to entire new functionality, while others provide a change to the user interface. The follow table indicates which preview features can be enabled per user or team member, and those that can be enabled for the organization. You must be a member of the Project Collection Administrators group to change a preview feature at the organization-level. Preview features Per user Per organization Analytics Views Copy Dashboard Experience Dependency Tracker Preview Features (ignore this setting for now) Experimental themes Full Access to Azure Pipelines for Stakeholders ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ Historical graph for agent pools Limit user visibility and collaboration to specific projects
- 358. New account manager New Artifacts (Feeds) Experience (accessbility updates) New Boards Hubs ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ New boards reports New release progress views New service connections experience New Settings Search in the organization settings panel New Teams page ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ New Wiki experience Organization Permissions Settings Page v2 Project Permissions Settings page Task Insights for Failed Pipeline Runs YAML templates editor ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ The follow table indicates those features that you can enable as a user, project administrator, or project collection administrator. These preview features are only available to manage for Azure DevOps Server 2020 RTW.
- 359. Enable features for your use Feature User Project Collection New service connections experience Selective artifacts download feature for collection/project ✔ ️ ✔ ️ ✔ ️ ✔ ️ From time to time, a new feature is introduced in Preview mode, which allows you to turn it on or off. To access the Preview features options, open your profile menu. The profile menu appears as shown below based on whether the New Account Manager feature has been enabled or not. The New Account Manager preview feature turns on enhanced user interface options for managing account information. The menu options move under the User settings icon from where they were previously under the Account manager for your account icon. New Account Manager enabled New Account Manager not enabled Choose User settings, and then choose Preview features. To enable or disable a feature, choose the slider.
- 360. Enable features at the organization level TIP For information on other user settings and preferences, see Set user preferences. When you enable a feature at the organization level, you essentially turn it on for all users of your account. Each user can then disable the feature if they so choose. If you disable a feature at the organization level, user settings are not changed. Users can enable or disable the feature on their own. If you don't see the for this account menu option, then you aren't a member of the Project Collection Administrators group. To get added as one, see Change project collection-level permissions.
- 361. Enable or disable a feature 1. Open your profile menu by choosing your image icon and select Manage features. 2. Select the level from the menu provided.
- 362. Experimental themes TIP If you don't see the for this project or for this collection menu options, then you aren't an administrator. To get added as one, see Change project collection-level permissions. 3. To enable or disable a feature, choose the slider. User-level Project-level Collection-level When you enable a feature at the project or collection-level, you essentially turn it on for all users. If you disable a feature at the project or collection-level, user settings are not changed. Users can enable or disable the feature on their own.
- 363. Features now enabled for all Azure DevOps Services General When you select Theme from the Profile menu you can select between Dark and Light themes for the display of Azure DevOps web portal. With Experimental themes enabled, you can select among a number of additional themes. New user hub New PAT experience
- 364. Azure Artifacts Azure Boards, Dashboards, and Analytics Azure Repos Azure Pipelines Azure Test Plans Related articles New Navigation Wiki Combine email recipients New experience in Code, Work Item, & Wiki search Out of the box notifications Team expansion for notifications Streamlined User Management NuGet.org upstream sources Updated package experience New Delivery Plans Experience Enable group by tags for work item chart widget on dashboard New Rich Text Editor New Queries Experience New Work Items New Dashboards Experience New TFVC pages Git Forks New Repos pull request experience New Repos settings experience New Repos landing pages Pull Request Status Policy Pipeline decorators Multi-stage pipelines Test tab in new web platform Test analytics in new web platform New builds hub Build with multiple queues New Releases Hub Approval gates in releases - New Release Definition Editor Symbol server Task tool installers New Test Plans Page New Test Plan Experience Set user preferences Azure DevOps Feature Timeline
- 365. Get started with search 6/9/2022 • 6 minutes to read • Edit Online Prerequisites IMPORTANT Start your search with a keyword Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 You can quickly find work items, code files, wiki pages, or packages based on a keyword, wildcards, and other supported search filters with the search function. Take an at-a-glance look at all of the search features further in this article. Every project member can use the search functions, including project members granted Stakeholder, Basic, and higher levels of access. When searching across the organization or collection, only results for which a project member has access are listed. Stakeholder wiki search results are limited to provisioned wikis. Because published wikis require access to regular repositories, which Stakeholders don't have access to, results for published wikis don't appear in the search results. Similarly, Code search results don't appear for Stakeholders. For Code search, a Collection Administrator must Install and configure search. Start your search using a keyword. You can then apply other options, as needed, to broaden or narrow your search results.
- 366. Search features, usage, and examples If you get no results matching the input, try removing filters and retry the search. Broadening the search and after you view the search results, you can apply appropriate filters again and search again for relevant results. Check for the spelling of your search terms. Currently Work item search doesn't support ignoring of users' spelling mistakes. If there are lots of hits when you're using a wildcard search, such as when you're using a simple wildcard search string, you may see a message that no matching files are found. In this case, narrow your search to reduce the number of matches. Specify more characters of the word or words that you want to find, or add a condition or filter to limit the number of possible matches. Searches aren't case-sensitive. The following features apply to all searches, including work items, code, wikis, and packages. The following features apply to all searches, including work items, code, and packages. Search feature
- 367. Usage Example Keyword Search based on one or more keywords. validate finds instances that contain the word validate. Exact match Search based on an exact match, enclosed in double-quotes. "Client not found" finds instances that contain the exact phrase match Client not found. Wildcard Add wildcard characters, * and ? , to keywords to extend the search criteria. Add * at the end of a keyword to find items that start with the keyword. Add ? in the middle to represent any alphanumeric character. Use wildcard characters anywhere in your search string except as a prefix. You can use prefix wildcards with the other search filter functions. You can use more than one wildcard to match more than one character. alpha?version finds instances of alpha1version and alphaXversion. Browser* finds instances of BrowserEdge, BrowserIE, and BrowserFirefox. CodeSenseHttp* finds files containing words that start with CodeSenseHttp, such as CodeSenseHttpClient and CodeSenseHttpClientTest. Boolean operators Find two or more keywords using Boolean operators: AND , OR , and NOT (must be uppercase). Add parenthesis to clauses to support logical groupings. Because AND is the default operator, an entry of two keywords with no operator is the same as an AND search. Validate AND revisit finds files that contain both the words validate and revisit. Validate OR revisit finds files that contain either of the words validate or revisit. Validate NOT revisit finds files that contain the word validate but not the word revisit. (Validate NOT revisit) OR "release delayed" finds files that contain the word validate but not the word revisit or files that contain the phrase release delayed. Proximity Search for files based on vicinity using proximity operators: NEAR, BEFORE, and AFTER (must be uppercase). By default, proximity search looks for terms within five tokens distance. term1 BEFORE term2 returns all files where term1 occurs BEFORE term2 within a distance of five tokens between them. term1 AFTER term2 returns the same results as term2 BEFORE term1. term1 NEAR term2 returns all files where term1 is within five token distance from term2 in any direction. term1 NEAR term2 returns the same results as term1 BEFORE term2 OR term2 BEFORE term1 .
- 368. Search from a different page TIP TIP Special characters Escape the special characters ( , ) , [ , ] , : , * , and ? by enclosing them in a phrase delimited with double-quotes. Include special characters in a search string, or search specifically for special characters, according to the following rules: CodeA23?R finds files containing words that start with CodeA23 Have any alphanumeric character next, and end with R. For example, CodeA234R and CodeA23QR. Search for any special character that isn't a part of the query language. "flatten()" finds the literal string flatten(). Search for a literal occurrence of the double-quote character " by preceding it with the escape character and enclosing the search string in double-quotes. ""react-redux"" finds the literal string "react-redux". You can search from any of the following pages: The Projects page for the organization: starts a search across all projects. The Project overview page: automatically applies a filter to search within the selected project. The Boards page for a project: automatically displays recent work items and backlogs accessed by the user. Azure Repos, Pipelines, Test Plans, or an Artifacts page for a project: automatically displays functional filters for code searches. The wiki page for a project: automatically go to a wiki page you recently opened. Use the content type filter to access a page that you recently accessed. For more information about searching and filtering in Azure Boards, see Filter backlogs, boards, and plans. For more information about searching wikis, see Provisioned vs. published wiki. No results found for ... If there's a large number of hits when using a wildcard search, such as when using a very simple wildcard search string, you may see a message that no matching files were found. In this case, narrow your search to reduce the number of matches. For example, specify more characters of the word(s) you want to find, or add a condition or filter to limit the number of possible matches.
- 369. Additional search functions NOTE Search re-index requirements Marketplace extensions To search for various settings, users, projects, and more, see the following table for other types of search tasks and corresponding actions. Search task Action Find an organization setting Go to your organization and select Organization settings. Find a project setting Go to your project and select Project settings. Find a user setting Go to your User settings page. Find a user Go to your organization and select Organization settings > Users, and then enter the name in the filter box. Find an organization Scroll through the left side of your screen, which lists all organizations. Find a project Go to your organization, and then enter the project name in the Filter projects box. View file history and compare versions Go to Repos > Files, highlight your file, and then select History. When you search from the Organization settings page, your search results include both organization-level and project-level settings. Search for Azure DevOps Server has the following limitation: If you do a disaster recovery (DR) operation and move your server back to an earlier snapshot of your SQL database, re-index all your collections. Code search - Extends search with fast, flexible, and precise search results across all your code. Required for searching repositories. Azure Paths Search - Adds a special search hub to Boards for searching within iterations and area paths without having to create and maintain custom queries.
- 370. NOTE Next steps Related articles Some extensions aren't supported features of Azure DevOps and therefore aren't supported by the product team. For questions, suggestions, or issues you have when using these extensions, visit their corresponding extension page on the Visual Studio Marketplace. Functional work item search or Functional code search or Functional artifact or package search Code search blog posts Work item search blog posts
- 371. Functional code search 6/9/2022 • 7 minutes to read • Edit Online Prerequisites Code search best practices NOTE Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Functional code search extends your ability to refine your search across repositories beyond what's documented in Get started with search. To do code searches, the Code Search Marketplace extension must be installed for your organization or collection. Install Code Search For more information, see Install and configure search. To use Code Search, you must have at least Basic access. Users with Stakeholder access don't have access to code, so they can't search for code. Users with Stakeholder access for a public project have full access to code, so they can search for code. To access code in a private project, you must have at least Basic access. When you're searching across the organization or collection, only results for which a project member has access are listed. Get the results you want even faster by starting with a higher-level search. You can narrow your search by using project, repository, path, file name, and other filter operators. When you're not sure of the exact term you're looking for, Use wildcards to widen your search and Boolean operators to fine-tune it. Find more information about an item of interest faster and with minimal efforts. When you find an item of interest, place the cursor on it and use the shortcut menu to quickly search for that text across all your projects and files. Easily trace how your code works by using the shortcut menu to search for related items such as definitions and references – directly from inside a file or from the search results. Go quickly to the implementation of, for example, an API your code might be taking dependency on by narrowing down your results to exact code type matches. Use code type filters to search for specific kinds of code such as: definitions references functions comments strings namespaces, and more. You can't search code in forked repositories.
- 372. Functions to find specific types of code TO FIND CODE WHERE FINDTHIS APPEARS AS A ... ... SEARCH FOR ARGUMENT ARG:FINDTHIS Argument arg:findThis Deprecated in July 2019 Base type basetype:findThis Calling function caller:findThis Deprecated in July 2019 Class definition or declaration class:findThis Class declaration classdecl:findThis Merged with class: Class definition classdef:findThis Merged with class: Comment comment:findThis Constructor ctor:findThis Merged with method: Declaration decl:findThis Definition def:findThis Destructor dtor:findThis Merged with method: Enumerator enum:findThis Extern extern:findThis Deprecated in July 2019 Field field:findThis Friend function friend:findThis Deprecated in July 2019 Function func:findThis Merged with method: Function declaration funcdecl:findThis Merged with method: Function definition funcdef:findThis Merged with method: Global global:findThis Deprecated in July 2019 As you enter your search, select functions and keywords from the drop-down list to quickly create your query. Use the Show more link to display all the available functions and keywords. Mix and match the functions as required. You can also select one or a combination of filters from the list in the left column. Again, the Show more link displays all the available functions and keywords. Instead, you can enter the functions and parameters directly into the search. The following table shows a list of functions for selecting specific types or members in your C#, C, C++, Java, and Visual Basic.NET code.
- 373. Header header:findThis Deprecated in July 2019 Interface interface:findThis Macro macro:findThis Macro definition macrodef:findThis Merged with macro: Macro reference macroref:findThis Merged with macro: Method method:findThis Method declaration methoddecl:findThis Merged with method: Method definition methoddef:findThis Merged with method: Namespace namespace:findThis Property prop:findThis Reference ref:findThis String literal strlit:findThis Struct struct:findThis Merged with type: Struct declaration structdecl:findThis Merged with type: Struct definition structdef:findThis Merged with type: Template argument tmplarg:findThis Deprecated in July 2019 Template specification tmplspec:findThis Deprecated in July 2019 Type type:findThis Typedef typedef:findThis Merged with type: Union union:findThis Deprecated in July 2019 TO FIND CODE WHERE FINDTHIS APPEARS AS A ... ... SEARCH FOR ARGUMENT ARG:FINDTHIS Functions to select projects, repositories, paths, and files Functions make it easy to narrow the search to specified locations, specific types of files within these locations, or specified filenames. Narrow the search to a specific location using the proj , repo , or path filters. Mix and match the functions as required.
- 374. USAGE EXAMPLE Find all occurrences of the word QueueJobsNow in the Fabrikam project. QueueJobsNow proj:Fabrikam Find all occurrences of the word QueueJobsNow in the Contoso repository. QueueJobsNow repo:Contoso Find all occurrences of the word QueueJobsNow in the path VisualStudio/Services/Framework and its subpaths. QueueJobsNow path:VisualStudio/Services/Framework Enclose the argument to the filter in double-quotes if it contains a space. QueueJobsNow path:"VisualStudio/Windows Phones and Devices/Services" Find all occurrences of the word QueueJobsNow in all files where the filename starts with queueRegister. QueueJobsNow file:queueRegister* Find all files with the name QueueRegister without an extension. Use quotes to find files without extensions. file:"queueRegister" Find all occurrences of the word QueueJobsNow in only C# source files. A plain text search string that doesn't include file type functions also finds files where the string matches part of the filename. QueueJobsNow ext:cs Find related items or other terms More code search operations USAGE EXAMPLE Find all instances of "ToDo" comments in your code Select comment: and enter todo One of the powerful features of Code Search is the capability to expand your search interactively, based on the results of previous searches. For example, you can easily broaden your search to related files when tracing or debugging code. Place the insertion point on a term in the file and open the shortcut menu (mouse: right-click) to start a new search for other files containing the selected term. You can search for it as text, for the definition if you select an object name, or for references to a selected object. For more information about the following search functions, see Get started with search. Keyword Exact match Wildcard Boolean operators Proximity See the following examples of even more code search functions. You can use the code type search functions with files written in C#, C, C++, Java, and Visual Basic.NET. Open the search results in a new browser tab from the main search box, and select Ctrl + Enter. In Google Chrome, select Ctrl + Shift + Enter to switch the focus to the new browser tab.
- 375. Search in specific locations, such as within a particular path Use a search string such as Driver path:MyShuttle/Server Search for files by name or just by file extension Driver file:GreenCabs.cs . The search string error ext:resx could be useful if you want to review all error strings in your code. Even if your plain text search string matches part of a filename, the file appears in the list of found files. This search works without matching specific file type functions. USAGE EXAMPLE Search Git projects and repositories Search TFVC projects In a Git project, you see a list of the repositories that it contains. Use the project and repository checkboxes to widen your search. You can search more or all projects, or narrow your search to fewer projects and repositories. If there are more than a few projects or repositories, use the Show more link to see them all. Code Search can index multiple branches in a Git repository. By default it indexes files in only the default branch of your Git repositories. Your default branch is usually the main branch. Specify the branches for each repository, indexing in the Options tab of the Repositories section, project settings page. In a TFVC project, you see a list of folder paths in that project for which you have read access - you won't see any projects and folders for which you don't have read permission. Select paths in the folder tree to narrow your search if necessary.
- 376. TIP Search code with REST API Next steps Related articles Code Search remembers your last settings, such as the project and repository or path that you searched in. Clear the checkboxes to search across all projects easily with the Clear all links when you want to search in a different scope. In the results pane, Code Search highlights up to the first 100 hits or matches found in the target files. You can use APIs to extend or supplement the capabilities listed in this article. For information about Code Search with REST API, see Fetch Code Search Results. Search work items Get started with Search Search artifacts and packages Search work items Search FAQs
- 377. Functional work item search 6/9/2022 • 8 minutes to read • Edit Online SEARCH TASK DESCRIPTION Search over all your projects Search in your own and your partner teams' backlog. Use cross-project searches over all the work items to search across your enterprise's entire work items. Narrow your search by using project and area path filters. Search across all work item fields Quickly and easily find relevant work items by searching across all work item fields, including custom fields. Use a full text search across all fields to efficiently locate relevant work items. The snippet view indicates where matches were found. Search in specific fields Use the quick in-line search filters to narrow down to a list of work items in seconds. Use the filters on any work item field. The list of suggestions helps complete your search faster. For example, a search such as AssignedTo:Chris WorkItemType:Bug State:Active finds all active bugs assigned to a user named Chris. Search across test Search across Test Plans, Test Suites, and other test work item types. Take advantage of integration with work item tracking The Work Item Search interface integrates with familiar controls for managing your work items; letting you view, edit, comment, share, and more. Prerequisites Search by work item ID Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Functional work item search command filters extend your ability to refine your search of work items based on assignment, work item type, specific fields, and more. This is in addition to the filter functions documented in Get started with search. Work item search is a built-in feature available to all Azure DevOps users. You can use Work Item Search by default without any installation when the Boards service is installed and enabled in Azure DevOps Services. By using Work Item Search, you can do the following tasks and more. All users can use work item search. Enter the work item ID in the Azure DevOps title bar to quickly go to it. Searching for a work item ID opens the work item in a modal dialog, providing quick access to read and edit work items.
- 378. Full text search across all fields You can easily search across all work item fields, including custom fields, which enables more natural searches. The snippet view indicates where matches were found.
- 379. Work item search best practices Search vs. managed work item queries Use simple search strings for words or phrases. Work item search matches derived forms of your search terms; for example, a search for "updating" also finds instances of the word "updated" and "update". Searches aren't case-sensitive. When you search from inside a project, the default is to search only within that project. While searching from inside a team, the default is to search only within the default area path of that team. The selected projects are always at the top of the list. Notice that hit counts are also shown for projects that aren't selected. Open the search results in a new browser tab from either the main search function or by selecting Ctrl + Shift + Enter. When you have one project selected, you see a list of area paths in that project for which you have read access - you won't see any projects and area paths for which you don't have read permission Select area paths in the tree to narrow your search if necessary. Use a text search across all fields to efficiently locate relevant work items. Text search is useful when you're trying to, for example, search for all work items that had similar exception trace. Use the quick in-line search filters on any work item field to narrow down to a list of work items in seconds. The list of suggestions helps complete your search faster. You have two ways to find and list work items: managed queries and the main search function. If you're looking for a single work item, use the main search. If you want to generate a list of work items to triage, update, chart, or share with others, use a managed query. With the main search function, you can search against a more fully indexed set of fields than that of managed queries. Use a managed query Search List items to perform bulk updates to fields. Review work that's in progress or recently closed. Triage work: set priority, review, update.
- 380. Apply supported functions to work item search Create a chart and add it to a dashboard. Create a chart to get a count of items or sum a field. Create a chart that shows a burndown or burnup over time. View a tree of parent-child related work items. List work items with link relationships. List work items for a single project, multiple projects, or across all projects. Find a specific work item using its ID or a keyword. Find one or more work items across all projects in a fast, flexible manner. Perform full text search across all work item fields. Review work items assigned to a specific team member. Search against specific work item fields to quickly narrow down a list of work items. Determine what key words will support a managed search. List work items for a single project, multiple projects, or across all projects. To get started, see the following articles: View and run a query Use search Define a query For specific managed query examples, see Query quick reference, Example queries. 1. Fine-tune your search by specifying the fields to search. Enter a: and a user name to search for all items assigned to that user. See the following quick filters that you can use: a: for Assigned to: c: for Created by: s: for State t: for Work item type 2. Start entering the name of a field in your work items; for example, enter ta .
- 381. The dropdown list shows work item field name suggestions that match user input. These suggestions help you complete the search faster. For example, a search such as tags:Critical finds all work items tagged 'Critical'. 3. Add more filters to further narrow your search, and use Boolean operators to combine terms if necessary. For example, a: Chris t: Bug s: Active finds all active bugs assigned to a user named Chris. 4. Narrow your search to specific types and states, by using the selector lists at the top of the results page. 5. Widen your search across all projects, or narrow it to specific types and states. Use the filter to show the selector lists. 6. Select the criteria you want in the drop-down selector lists, or search across the entire organization. 7. Sort the results as you need using the drop-down list of field names, work item types, or by relevance.
- 382. 1. Fine-tune your search by specifying the fields to search. Enter a: and a user name to search for all items assigned to that user. See the following quick filters that you can use: a: for Assigned to: c: for Created by: s: for State t: for Work item type 2. Start entering the name of a field in your work items; for example, enter ta .
- 383. The dropdown list shows work item field name suggestions that match user input. These suggestions help you complete the search faster. For example, a search such as tags:Critical finds all work items tagged 'Critical'. 3. Add more filters to further narrow your search, and use Boolean operators to combine terms if necessary. For example, a: Chris t: Bug s: Active finds all active bugs assigned to a user named Chris. 4. Narrow your search to specific types and states, by using the drop-down selector lists at the top of the results page. 5. Widen your search across all projects, or narrow it to specific types and states. Use the filter to show the selector lists. 6. Select the criteria you want in the drop-down selector lists, or search across the entire organization. 7. Sort the results as you need using the drop-down list of field names, work item types, or by relevance.
- 384. Quick filters for matching in specific fields USAGE EXAMPLE Scope your search terms to match in any work item field including custom fields. Enter the field name followed by the search terms. tags:Critical finds work items having a field 'tags' containing the term 'Critical'. Use multiple inline search filters to scope your search by any work item field, including custom fields. t: Bug path:"projectsearch" finds all bugs in the area path "projectsearch". Use the operators > , >= , < , <= , = , and != for date, integer, and float fields. t: Bug CreatedDate> @Today-7 finds all bugs created in the last week. For the search query that contains multiple terms and users looking for exact match, embed the search term inside " " BuildPath: "tools.demoproject.com" finds all work items that necessarily contain the path "tools.demoproject.com". Quick inline search filters let you refine work items in seconds. The dropdown list of suggestions helps complete your search faster. Mix and match the functions to create quick powerful searches.
- 385. Scope projects and area and iteration paths using filters USAGE EXAMPLE Finds all occurrences of the word Wiki in the Fabrikam project. Wiki proj:Fabrikam Finds all occurrences of the word Wiki in the area path Contoso/Mobile and its subpaths. Wiki area:Contoso/Mobile Finds all occurrences of the word Wiki in the iteration path Contoso/Sprint101 and its subpaths. Wiki iteration:Contoso/Sprint101 Enclose the argument to the filter in double-quotes if it contains a space. Wiki path:"Contoso/Windows Phones and Devices/Services" Finds backlog comments comment:todo See more of the work item TIP Search Work Items with REST API Next steps Related articles Filters make it easy to narrow the search to specified projects and area paths. Narrow the search to a specific location using the proj , area , iteration , path , and comment filters: You can quickly get a full screen view of the selected work item using expand and shrink in the toolbar. However, another way to see more of the work item, while you can still select work items from the list of matching results, is to hide the left column filter pane by choosing < at the top left of the column. Use > to restore the filter pane. If you're using a portrait orientation screen, use the Preview pane: Right link at the top right of the window to display the code below the search results list. Search remembers the state of the filter pane, configuration of the work item view pane, and its position between sessions as part of your user preferences. You can use APIs to extend or supplement the capabilities listed in this article. For information about Work Item Search with REST API, see Fetch Work Item Search Results. Supported filter functions and more for work items Get started with Search Search code Search artifacts and packages Search FAQs
- 386. Migrate data from Azure DevOps Server to Azure DevOps Services 6/9/2022 • 3 minutes to read • Edit Online Supported Azure DevOps Server versions for import IMPORTANT NOTE Preview features Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 The data migration tool for Azure DevOps provides a high fidelity way to migrate collection databases from Azure DevOps Server to Azure DevOps Services. It's recommended that you download the migration guide and tool if you're looking to use this service to import your collection(s). The guide serves as a walk through of the different steps involved in an import. Providing best practices, checklists, and helpful tips to make your import as easy as possible. The guide should be used in conjunction with the more technical documentation referenced below to successfully import to Azure DevOps Services. It can take up to 2-3 weeks after a new RTW version of Azure DevOps Server is released for import support to come online for that version. It's important to take this into consideration when choosing to upgrade shortly after a new RTW Azure DevOps Server release. The data migration tool for Azure DevOps supports the two latest releases of Azure DevOps Server at a given time. Releases include updates and major releases. Currently the following versions of Azure DevOps Server are supported for import: Azure DevOps Server 2020.1.1 Azure DevOps Server 2020.1 The data migration tool doesn't support imports from Azure DevOps Server release candidates (RC). If you're planning on importing your collection database to Azure DevOps Services using this service, it's important that you don't upgrade your production database to an RC release. If you do upgrade, then you will need to wait and upgrade to the release to web (RTW) version when it's available or restore a backup copy of your database from a previous Azure DevOps Server version to import. Normal release cadence for new Azure DevOps Server versions is once every three-to-four months. Meaning that support for a given version of Azure DevOps Server for migration to Azure DevOps Services should last for anywhere between six-to-eight months. It's important to ensure that your planning accounts for this support window to avoid having to suddenly upgrade to migrate.
- 387. NOTE Data migration tool for Azure DevOps resources Import process Troubleshooting Q & A Q: Will my Personal Access Tokens also migrate when I migrate from on-premises to Azure DevOps Services? Q: If I have feedback or additional questions is there somewhere I can reach out? Related articles If you're not including preview features when running the migration tool, then you will need to re-run the migration tool prepare to generate a new import.json to queue an import. You DO NOT need to include preview features when you re- generate your import.json. If you had previously been including preview features then you DO NOT need to take any additional actions after Monday, April 23, 2020. The following features can be included with your import, but are currently in a preview state. Analytics - Note this is only supported for Azure DevOps Server 2019 and later. When queueing an import you can elect to include preview features with your import. If you do, data related to these features will be copied into your new organization along with all your other data. Should you choose to not include these features then their data will not be copied. For a list of items not included with an import, see the migration guide and tool. In general you should use the Migration guide and tool when going through an import. When it's required, the guide links back to the following articles. These articles offer deeper technical knowledge on various import topics. Validate a collection for import Prepare a collection for import Prepare for import Run an import Post import steps Prepare large collections for import Troubleshooting validation errors Troubleshooting process errors Troubleshooting import errors A: No. Your tokens will not migrate and you will need to regenerate your Personal Access Tokens on Azure DevOps Services. A: Yes. You can contact AzureDevOpsImport@microsoft.com. Please note that this alias is for general questions. If you need assistance with a failed import please contact Azure DevOps customer support. Migration and process model FAQs
- 388. Migration options 6/9/2022 • 3 minutes to read • Edit Online Option 1: Copy the most important assets manually Option 2: High fidelity database migration. Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 When you decide to make the move from Azure DevOps Server to Azure DevOps Services, you might start fresh with an empty organization. Often, however, you will have existing code, work items, and other assets that you want to move. There are many approaches to doing this which vary in both the fidelity of the data transfer and the complexity of the process. Prior to migrating data, review the differences that exist between Azure DevOps Server and Azure DevOps Services. By far the easiest option for moving data into Azure DevOps Services is to manually copy your most important assets and start relatively fresh. This can be difficult when you are in the middle of a large project, but you can make it easier if you do some advance planning and schedule your move when it makes sense for your team. For example, when the Azure DevOps team chose to move from Azure DevOps Server to Azure DevOps Services, we also decided to move from Team Foundation Version Control (TFVC) to Git. This required a fair bit of planning, but when we actually performed our migration, we created a new Git repo using the "tip" version of our TF VC sources, and left our history behind in Azure DevOps Server. We also moved our active work items, and left behind all our old bugs, completed user stories and tasks, and so on. Here's the general process: 1. Identify the most important assets that you need to migrate - typically source code, work items, or both. Other assets in Azure DevOps Server - build pipelines, test plans, and so forth - are harder to manually migrate. 2. Identify a good time to make the transition. 3. Prepare your target organizations. Create the organizations and team projects that you need, provision users, and so on. 4. Migrate your data. 5. Consider making the source Azure DevOps Server deployments read-only. The Azure DevOps Server & Azure DevOps Services product team provides a high fidelity data migration tool. A downloadable Migration Guide is available at https://aka.ms/AzureDevOpsImport.
- 389. Option 3: Using public API-based tools for higher fidelity migration Related articles Because the data migration tool operates at a database level, it can provide a very high fidelity migration. If you want to move your existing Azure DevOps Server data into Azure DevOps Services, we strongly recommend using this option. If for some reason you cannot use the data migration tool but still want a higher fidelity migration than Option 1, you can choose from a variety of tools that use public APIs to move data. Generally these tools can provide a higher fidelity migration than a manual copy of "tip" data, but they are still relatively low fidelity. For example: None of them will preserve the dates of TF VC changesets. Many of them will not preserve the changed dates of work item revisions. None of them will migrate all Azure DevOps Server artifacts. In general, we only recommend this approach if the extra fidelity beyond a manual copy is critical. If you decide to take this approach, you might consider hiring a consultant who has experience with one or more of the tools. You should definitely consider doing a test migration before doing your final migration. Many organizations need a very high fidelity migration for only a subset of their work. New work could potentially start directly in Azure DevOps Services. Other work, with less stringent fidelity requirements, could be migrated using one of the other approaches. You will have to weigh the pros and cons of the various approaches against your motivations for moving into Azure DevOps Services and decide for yourself what is the right strategy. About Azure DevOps Services and Azure DevOps Server Pricing, Azure DevOps Services Pricing, Azure DevOps Server
- 390. Validation and import processes 6/9/2022 • 33 minutes to read • Edit Online NOTE Validate a collection Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 This article walks you through the preparation that's required to get an import to Azure DevOps Services ready to run. If you encounter errors during the process, see Troubleshoot import and migration errors. Visual Studio Team Services (VSTS) is now Azure DevOps Services. With the release of Azure DevOps Server 2019, the TFS Database Import Service has been rebranded as the data migration tool for Azure DevOps. This change includes TfsMigrator (Migrator) becoming the data migration tool. This service works exactly the same as the former import service. If you're running an older version of on-premises Azure DevOps Server with the TFS branding, you can still use this feature to migrate to Azure DevOps as long as you've upgraded to one of the supported server versions. Before you begin the import tasks, check to ensure that you're running a supported version of Azure DevOps Server. We recommend that you use the Step-by-step migration guide to progress through your import. The guide links to technical documentation, tools, and best practices. After you've confirmed that you're running the latest version of Azure DevOps Server, your next step is to validate each collection that you want to migrate to Azure DevOps Services. The validation step examines various aspects of your collection, including, but not limited to, size, collation, identity, and processes. You run the validation by using the data migration tool. To start, download the tool, copy the zip file to one of your Azure DevOps Server application tiers, and then unzip it. You can also run the tool from a different machine without Azure DevOps Server installed as long as the machine can connect to the configuration database of the Azure DevOps Server instance. An example is shown here. Migrator /help Migrator validate /help 1. Open a Command Prompt window on the server, and enter a cd command to change to the directory where the data migration tool is stored. Take a few moments to review the help content that's provided with the tool. a. To view the top-level help and guidance, run the following command: b. View the help text for the command: 2. Because this is your first time validating a collection, let's keep it simple. Your command should have the following structure:
- 391. Import log files Migrator validate /collection:{collection URL} Migrator validate /collection:http://localhost:8080/DefaultCollection Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True" IMPORTANT For example, to run against the default collection the command would look like: 3. To run the tool from a machine other than the Azure DevOps Server, you need the /connectionString parameter. The connection string parameter points to your Azure DevOps Server configuration database. As an example, if the validate command is being run by the Fabrikam corporation, the command would look like: The data migration tool does not edit any data or structures in the collection. It reads the collection only to identify issues. 4. After the validation is complete, you can view the log files and results. During validation, you'll receive a warning if some of your pipelines contain per-pipeline retention rules. Azure DevOps Services uses a project-based retention model and doesn't support per-pipeline retention policies. If you proceed with the migration, the policies won't be carried over to the hosted version. Instead, the default project-level retention policies will apply. Retain builds important to you, to avoid their loss. After all the validations pass, you can move to the next step of the import process. If the data migration tool flags any errors, you need to correct them before you proceed. For guidance on correcting validation errors, see Troubleshoot import and migration errors. When you open the log directory, you'll notice several logging files. The main log file is named DataMigrationTool.log. It contains details about everything that was run. To make it easier for you to focus on specific areas, a log is generated for each major validation operation.
- 392. Generate import files The prepare command Migrator prepare /help Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region} Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True" For example, if TfsMigrator reports an error in the "Validating Project Processes" step, you can open the ProjectProcessMap.log file to view everything that was run for that step instead of having to scroll through the entire log. You should review the TryMatchOobProcesses.log file only if you're trying to import your project processes to use the inherited model. If you don't want to use the inherited model, you can ignore these errors, because they won't prevent you from importing to Azure DevOps Services. By now, you've run the data migration tool validation against the collection, and it's returning a result of "All collection validations passed." Before you take a collection offline to migrate it, you need to generate the import files. When you run the prepare command, you generate two import files: IdentityMapLog.csv: Outlines your identity map between Active Directory and Azure Active Directory (Azure AD). import.json: Requires you to fill out the import specification you want to use to kick off your migration. The prepare command assists with generating the required import files. Essentially, this command scans the collection to find a list of all users to populate the identity map log, IdentityMapLog.csv, and then tries to connect to Azure AD to find each identity's match. To do this, your company needs to use the Azure Active Directory Connect tool (formerly known as the Directory Synchronization tool, Directory Sync tool, or DirSync.exe tool). If directory synchronization is set up, the data migration tool should be able to find the matching identities and mark them as Active. If it doesn't find a match, the identity is marked as Historical in the identity map log, and you'll need to investigate why the user isn't included in your directory sync. The import specification file, import.json, should be filled out prior to the import. Unlike the validate command, prepare does require an internet connection, because it needs to connect to Azure AD to populate the identity map log file. If your Azure DevOps Server instance doesn't have internet access, you need to run the tool from a machine that does. As long as you can find a machine with an intranet connection to your Azure DevOps Server instance and an internet connection, you can run this command. For help with the prepare command, run the following command: Included in the help documentation are instructions and examples for running Migrator from the Azure DevOps Server instance itself and a remote machine. If you're running the command from one of the Azure DevOps Server instance's application tiers, your command should have the following structure: The connectionString parameter is a pointer to the configuration database of your Azure DevOps Server instance. As an example, if the prepare command is being run by the Fabrikam corporation, the command would look like:
- 393. Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True" IMPORTANT When the data migration tool runs the prepare command, it runs a complete validation to ensure that nothing has changed with your collection since the last full validation. If any new issues are detected, no import files are generated. Shortly after the command has started running, an Azure AD sign-in window is displayed. You need to sign in with an identity that belongs to the tenant domain that's specified in the command. Make sure that the specified Azure AD tenant is the one you want your future organization to be backed with. In our Fabrikam example, a user would enter credentials that are similar to what's shown in the following screenshot. Do not use a test Azure AD tenant for a test import and your production Azure AD tenant for the production run. Using a test Azure AD tenant can result in identity import issues when you begin your production run with your organization's production Azure AD tenant. When you run the prepare command successfully in the data migration tool, the results window displays a set of logs and two import files. In the log directory, you'll find a logs folder and two files: import.json is the import specification file. We recommend that you take time to fill it out. IdentityMapLog.csv contains the generated mapping of Active Directory to Azure AD identities. Review it for completeness before you kick off an import. The two files are described in greater detail in the next sections.
- 394. The import specification file FIELD DESCRIPTION REQUIRED ACTION Source Information about the location and names of the source data files that are used for import. No action required. Review information for the subfield actions to follow. Location The shared access signature key to the Azure storage account that hosts the data-tier application package (DACPAC). No action required. This field will be covered in a later step. Files The names of the files containing import data. No action required. Review information for the subfield actions to follow. The import specification, import.json, is a JSON file that provides import settings. It includes the desired organization name, storage account information, and other information. Most of the fields are autopopulated, and some fields require your input before you attempt an import. The import.json file's displayed fields and required actions are described in the following table:
- 395. DACPAC A DACPAC file that packages the collection database to be used to bring in the data during the import. No action required. In a later step, you'll generate this file by using your collection and then upload it to an Azure storage account. You'll need to update the file based on the name you use when you generate it later in this process. Target Properties of the new organization to import into. No action required. Review information for the subfield actions to follow. Name The name of the organization to be created during the import. Provide a name. The name can be quickly changed later after the import has completed. Note: Do not create an organization with this name before you run the import. The organization will be created as part of the import process. ImportType The type of import that you want to run. No action required. In a later step, you'll select the type of import to run. Validation Data Information that's needed to help drive your import experience. The "ValidationData" section is generated by the data migration tool. It contains information that's needed to help drive your import experience. Do not edit the values in this section, or your import could fail to start. FIELD DESCRIPTION REQUIRED ACTION After you complete the preceding process, you should have a file that looks like the following:
- 396. NOTE Supported Azure regions for import GEOGRAPHIC REGION AZURE REGION IMPORT SPECIFICATION VALUE United States Central United States CUS In the preceding image, note that the planner of the Fabrikam import added the organization name fabrikam- import and selected CUS (Central United States) as the region for import. Other values were left as is to be modified just before the planner took the collection offline for the migration. Dry-run imports have a '-dryrun' automatically appended to the end of the organization name. This can be changed after the import. Azure DevOps Services is available in several Azure regions. However, not all regions where Azure DevOps Services is available are supported for import. The following table lists the Azure regions that you can select for import. Also included is the value that you need to place in the import specification file to target that region for import.
- 397. Europe Western Europe WEU United Kingdom United Kingdom South UKS Australia Australia East EAU South America Brazil South SBR Asia Pacific South India MA Asia Pacific Southeast Asia (Singapore) SEA Canada Central Canada CC GEOGRAPHIC REGION AZURE REGION IMPORT SPECIFICATION VALUE The identity map log Active identities Historical identities NOTE Understand the identity map log file The identity map log is of equal importance to the actual data that you'll be migrating to Azure DevOps Services. As you're reviewing the file, it's important to understand how identity import operates and what the potential results could entail. When you import an identity, it can become either active or historical. Active identities can sign in to Azure DevOps Services, but historical identities cannot. Active identities refer to identities that will be users in Azure DevOps Services post-import. In Azure DevOps Services, these identities are licensed and are displayed as users in the organization. The identities are marked as active in the Expected Import Status column in the identity map log file. Historical identities are mapped as such in the Expected Import Status column in the identity map log file. Identities without a line entry in the file also become historical. An example of an identity without a line entry might be an employee who no longer works at a company. Unlike active identities, historical identities: Don't have access to an organization after migration. Don't have licenses. Don't show up as users in the organization. All that persists is the notion of that identity's name in the organization, so that its history can be searched later. We recommend that you use historical identities for users who no longer work at the company or who won't need further access to the organization. After an identity is imported as historical, it can't become active. The identity map log file is similar to the example shown here: The columns in the identity map log file are described in the following table:
- 398. NOTE COLUMN DESCRIPTION Active Directory: User (Azure DevOps Server) The friendly display name used by the identity in Azure DevOps Server. This name makes it easier to identify which user the line in the map is referencing. Active Directory: Security Identifier The unique identifier for the on-premises Active Directory identity in Azure DevOps Server. This column is used to identify users in the collection. Azure Active Directory: Expected Import User (Azure DevOps Services) Either the expected sign-in address of the matched soon-to- be-active user or No Match Found (Check Azure AD Sync), indicating that the identity wasn't found during the Azure Active Directory sync and it will be imported as historical. Expected Import Status The expected user import status: either Active if there's a match between your Active Directory and Azure Active Directory, or Historical if there isn't a match. Validation Date The last time the identity map log was validated. IMPORTANT You and your Azure AD admin will need to investigate users that are marked as No Match Found (Check Azure AD Sync) to understand why they aren't part of your Azure AD Connect sync. As you read through the file, notice whether the value in the Expected Import Status column is Active or Historical. Active indicates that it's expected that the identity on this row will map correctly on import and will become active. Historical means that the identities will become historical on import. It's important to review the generated mapping file for completeness and correctness. Your import will fail if major changes occur to your Azure AD Connect security ID sync between import attempts. You can add new users between dry runs, and you can make corrections to ensure that previously imported historical identities become active. However, changing an existing user that was previously imported as active isn't supported at this time. Doing so will cause your import to fail. An example of a change might be completing a dry-run import, deleting an identity from your Azure AD that was imported actively, re-creating a new user in Azure AD for that same identity, and then attempting another import. In this case, an active identity import will be attempted between the Active Directory and newly created Azure AD identity, but it will cause an import failure. 1. Start by reviewing the correctly matched identities. Are all the expected identities present? Are the users mapped to the correct Azure AD identity? If any values are incorrectly mapped or need to be changed, contact your Azure AD administrator to verify that the on-premises Active Directory identity is part of the sync to Azure AD and has been set up correctly. For more information, see Integrate your on-premises identities with Azure Active Directory. 2. Next, review the identities that are labeled as historical. This labeling implies that a matching Azure AD identity couldn't be found, for any of the following reasons: The identity hasn't been set up for sync between on-premises Active Directory and Azure AD. The identity hasn't been populated in your Azure AD yet (for example, there's a new employee).
- 399. Historical identities (small teams) NOTE Visual Studio subscriptions Prepare for import The identity doesn't exist in your Azure AD instance. The user who owns that identity no longer works at the company. To address the first three reasons, you need to set up the intended on-premises Active Directory identity to sync with Azure AD. For more information, see Integrate your on-premises identities with Azure Active Directory. You must set up and run Azure AD Connect for identities to be imported as active in Azure DevOps Services. You can ignore the fourth reason, because employees who are no longer at the company should be imported as historical. The identity import strategy proposed in this section should be considered by small teams only. If Azure AD Connect hasn't been configured, you'll notice that all users in the identity map log file are marked as historical. Running an import this way results in all users being imported as historical. We strongly recommended that you configure Azure AD Connect to ensure that your users are imported as active. Running an import with all historical identities has consequences that need to be considered carefully. It should be considered only by teams with a small number of users and for which the cost of setting up Azure AD Connect is deemed too high. To import all identities as historical, follow the steps outlined in later sections. When you queue an import, the identity that's used to queue the import is bootstrapped into the organization as the organization owner. All other users are imported as historical. Organization owners can then add the users back in by using their Azure AD identity. The added users are treated as new users. They do not own any of their history, and there's no way to re-parent this history to the Azure AD identity. However, users can still look up their pre-import history by searching for their <domain><Active Directory username>. The data migration tool displays a warning if it detects the complete historical identities scenario. If you decide to go down this migration path, you'll need to consent in the tool to the limitations. The data migration tool can't detect Visual Studio subscriptions (formerly known as MSDN benefits) when it generates the identity map log file. Instead, we recommend that you apply the auto license upgrade feature after the import. As long as users' work accounts are linked correctly, Azure DevOps Services automatically applies their Visual Studio subscription benefits at their first sign-in after the import. You're never charged for licenses that are assigned during the import, so this can be safely handled afterward. You don't need to repeat a dry-run import if users' Visual Studio subscriptions aren't automatically upgraded in Azure DevOps Services. Visual Studio subscription linking happens outside the scope of an import. As long as their work account is linked correctly before or after the import, users' licenses are automatically upgraded on their next sign-in. After their licenses have been upgraded successfully, the next time you run an import, the users are upgraded automatically on their first sign-in to the organization. By now, you have everything ready to execute on your import. You need to schedule downtime with your team to take the collection offline for the migration. When you've agreed upon a time to run the import, you need to upload to Azure both the required assets you've generated and a copy of the database. This process has five steps: Step 1: Take the collection offline and detach it.
- 400. NOTE NOTE Step 1: Detach your collection Step 2: Generate a DACPAC file NOTE If the data migration tool displays a warning that you can't use the DACPAC method, you have to perform the import by using the SQL Azure virtual machine (VM) method. Skip steps 2 to 5 in that case and follow instructions provided in Import large collections and then continue to section determine the import type. Step 2: Generate a DACPAC file from the collection you're going to import. Step 3: Upload the DACPAC file and import files to an Azure storage account. Step 4: Generate an SAS key to the storage account. Step 5: Complete the import specification. Before you perform a production import, we strongly recommend that you complete a dry-run import. With a dry run, you can validate that the import process works for your collection and that there are no unique data shapes present that might cause a production import failure. Detaching the collection is a crucial step in the import process. Identity data for the collection resides in the Azure DevOps Server instance's configuration database while the collection is attached and online. When a collection is detached from the Azure DevOps Server instance, it takes a copy of that identity data and packages it with the collection for transport. Without this data, the identity portion of the import can't be executed. We recommend that you keep the collection detached until the import has been completed, because there isn't a way to import the changes that occurred during the import. If you're doing a dry run (test) import, we recommend that you reattach your collection after you back it up for import, because you won't be concerned about having the latest data for this type of import. To avoid offline time altogether, you can also choose to employ an offline detach for dry runs. It's important to weigh the cost of choosing to incur zero downtime for a dry run. It requires taking backups of the collection and configuration database, restoring them on a SQL instance, and then creating a detached backup. A cost analysis could prove that taking just a few hours of downtime to directly take the detached backup is better in the long run. DACPACs offer a fast and relatively easy method for moving collections into Azure DevOps Services. However, after a collection database size exceeds a certain threshold, the benefits of using a DACPAC start to diminish. If the data migration tool displays a warning that you can't use the DACPAC method, you have to perform the import by using the SQL Azure virtual machine (VM) method provided in Import large collections. If the data migration tool doesn't display a warning, use the DACPAC method described in this step. DACPAC is a feature of SQL server that allows database changes to be packaged into a single file and deployed to other instances of SQL. A DACPAC file can also be restored directly to Azure DevOps Services, so you can use it as the packaging method for getting your collection's data in the cloud. You use the SqlPackage.exe tool to generate the DACPAC file. The tool is included as part of SQL Server Data Tools (SSDT). Multiple versions of the SqlPackage.exe tool are installed with SSDT. The versions are stored in folders with names such as 120, 130, and 140. When you use SqlPackage.exe, it's important to use the right version to prepare the DACPAC.
- 401. IMPORTANT [Info @08:23:59.539] Table name Size in MB [Info @08:23:59.539] dbo.tbl_Content 38984 [Info @08:23:59.539] dbo.tbl_LocalVersion 1935 [Info @08:23:59.539] dbo.tbl_Version 238 [Info @08:23:59.539] dbo.tbl_FileReference 85 [Info @08:23:59.539] dbo.Rules 68 [Info @08:23:59.539] dbo.tbl_FileMetadata 61 SET TEMP={location on disk} TFS 2018 imports need to use the SqlPackage.exe version from the 140 folder or higher. If you installed SSDT for Visual Studio, you'll find your SqlPackage.exe version in one of the following folder paths: If you installed SSDT and integrated it with an existing installation of Visual Studio, your SqlPackage.exe folder path is similar to C:Program Files (x86)Microsoft Visual Studio 14.0Common7IDEExtensionsMicrosoftSQLDBDAC130 . If you installed SSDT as a standalone installation, your SqlPackage.exe folder path is similar to C:Program Files (x86)Microsoft Visual. Studio2017SQLCommon7IDEExtensionsMicrosoftSQLDBDAC130 . If you already have an installation of SQL Server, SqlPackage.exe might already be present, and your folder path is similar to %PROGRAMFILES%Microsoft SQL Server130DACbin . Both versions of SSDT that you can download from SQL Server Data Tools include both the 130 and 140 folders and their SqlPackage.exe versions. When you generate a DACPAC, keep two considerations in mind: the disk that the DACPAC will be saved on and the disk space on the machine that's generating the DACPAC. You want to ensure that you have enough disk space to complete the operation. As it creates the package, SqlPackage.exe temporarily stores data from your collection in the temp directory on drive C of the machine you're initiating the packaging request from. You might find that your drive C is too small to support creating a DACPAC. You can estimate the amount of space you'll need by looking for the largest table in your collection database. DACPACs are created one table at a time. The maximum space requirement to run the generation is roughly equivalent to the size of the largest table in the collection's database. If you're saving the generated DACPAC to drive C, you also need to take into account the size of the collection database as reported in the DataMigrationTool.log file from a validation run. The DataMigrationTool.log file provides a list of the largest tables in the collection each time the validate command is run. For an example of table sizes for a collection, see the following output. Compare the size of the largest table with the free space on the drive that hosts your temporary directory. Before you proceed with generating a DACPAC file, ensure that your collection is detached. Ensure that the drive that hosts your temporary directory has at least as much free space. If it doesn't, you need to redirect the temp directory by setting an environment variable. Another consideration is where the DACPAC data is saved. Pointing the save location to a far-off remote drive could result in much longer generation times. If a fast drive such as a solid-state drive (SSD) is available locally, we recommend that you target the drive as the DACPAC save location. Otherwise, it's always faster to use a disk that's on the machine where the collection database resides rather than a remote drive.
- 402. SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:DACPACFoo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory Configure your collection for import ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE; USE [<database name>] CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>' CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo] EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>' ALTER DATABASE [Foo] SET RECOVERY SIMPLE; USE [Foo] CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!' CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo] EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam' Now that you've identified the target location for the DACPAC and ensured that you have enough space, it's time to generate the DACPAC file. Open a Command Prompt window and go to the SqlPackage.exe location. To generate the DACPAC, replace the placeholder values with the required values, and then run the following command: Data Source: The SQL Server instance that hosts your Azure DevOps Server collection database. Initial Catalog: The name of the collection database. targetFile: The location on the disk and the DACPAC file name. A DACPAC generation command that's running on the Azure DevOps Server data tier itself is shown in the following example: The output of the command is a DACPAC file that's generated from the collection database Foo called Foo.dacpac. After your collection database has been restored on your Azure VM, configure a SQL login to allow Azure DevOps Services to connect to the database to import the data. This login allows only read access to a single database. To start, open SQL Server Management Studio on the VM, and then open a new query window against the database to be imported. Set the database's recovery to simple: Create a SQL login for the database, and assign that login the 'TFSEXECROLE': Following our Fabrikam example, the two SQL commands would look like the following:
- 403. NOTE Configure the import specification file to target the VM Be sure to enable SQL Server and Windows authentication mode in SQL Server Management Studio on the VM. If you don't enable authentication mode, the import will fail. Update the import specification file to include information about how to connect to the SQL Server instance. Open your import specification file and make the following updates: "Properties": { "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" } 1. Remove the DACPAC parameter from the source files object. The import specification before the change is shown in the following code: The import specification after the change is shown in the following code: 2. Fill out the required parameters and add the following properties object within your source object in the specification file. Following the Fabrikam example, after you apply the changes, the import specification would look like the following:
- 404. Step 3: Upload the DACPAC file NOTE Your import specification is now configured to use a SQL Azure VM for import. Proceed with the rest of preparation steps to import to Azure DevOps Services. After the import has finished, be sure to delete the SQL login or rotate the password. Microsoft does not retain the login information after the import has finished. If you're using the SQL Azure VM method, you need to provide only the connection string. You don't have to upload any files, and you can skip this step. Your DACPAC must be placed in an Azure storage container. This can be an existing container or one created specifically for your migration effort. It's important to ensure that your container is created in the right region. Azure DevOps Services is available in multiple regions. When you're importing to these regions, it's critical to place your data in the correct region to ensure that the import can start successfully. Your data must be placed in the same region that you'll be importing to. Placing the data anywhere else will result in the import being unable to start. The following table lists the acceptable regions for creating your storage account and uploading your data.
- 405. DESIRED IMPORT REGION STORAGE ACCOUNT REGION Central United States Central United States Western Europe Western Europe Australia East Australia East Brazil South Brazil South India South India South Canada Central Canada Central Asia Pacific (Singapore) Asia Pacific (Singapore) NOTE Step 4: Generate an SAS key NOTE Although Azure DevOps Services is available in multiple regions in the US, only the Central United States region accepts new Azure DevOps Services. You can't import your data into other US Azure regions at this time. You can create a blob container from the Azure portal. After you've created the container, you need to upload the Collection DACPAC file. After the import has finished, you can delete the blob container and accompanying storage account. To do so, you can use tools such as AzCopy or any other Azure storage explorer tool, such as Azure Storage Explorer. If your DACPAC file is larger than 10 GB, we recommend that you use AzCopy. AzCopy has multithreaded upload support for faster uploads. A shared access signature (SAS) key provides delegated access to resources in a storage account. The key allows you to give Microsoft the lowest level of privilege that's required to access your data for executing the import. The recommended way to generate an SAS key is to use Azure Storage Explorer. With Storage Explorer, you can easily create container-level SAS keys. This is essential, because the data migration tool does not support account-level SAS keys. Do not generate an SAS key from the Azure portal. Azure portal-generated SAS keys are account scoped and don't work with the data migration tool. After you install Storage Explorer, you can generate an SAS key by doing the following: 1. Open Storage Explorer. 2. Add an account. 3. Select Use a storage account name and key, and then select Connect.
- 406. 4. On the Attach External Storage pane, enter your storage account name, provide one of your two primary access keys, and then select Connect. 5. On the left pane, expand Blob Containers, right-click the container that stores your import files, and then select Get Shared Access Signature.
- 407. 6. For Expiry time, set the expiration date for seven days in the future. 7. Under Permissions for your SAS key, select the Read and List check boxes. Write and delete permissions aren't required.
- 408. Step 5: Complete the import specification Restrict access to Azure DevOps Services IPs only NOTE Copy and store this SAS key to place in your import specification file in the next step. Treat this SAS key as a secret. It provides access to your files in the storage container. Earlier in the process you partially filled out the import specification file generally known as import.json. At this point, you have enough information to complete all the remaining fields except for the import type. The import type will be covered later, in the import section. In the import.json specification file, under Source, complete the following fields: Location: Paste the SAS key you generated from the script and then copied in the preceding step. Dacpac: Ensure that the file, including the .dacpac file extension, has the same name as the DACPAC file you uploaded to the storage account. Using the Fabrikam example, the final import specification file should look like the following: We highly recommend that you restrict access to your Azure Storage account to only IPs from Azure DevOps
- 409. Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region} NOTE Determine the import type TIP Services. You do this by allowing connections only from the set of Azure DevOps Services IPs that are involved in the collection database import process. The IPs that need to be granted access to your storage account depend on the region you're importing into. Use the IpList option to get the list of IPs that need to be granted access. Included in the help documentation are instructions and examples for running Migrator from the Azure DevOps Server instance itself and a remote machine. If you're running the command from one of the Azure DevOps Server instance's application tiers, your command should have the following structure: Alternatively, you can also use Service Tags in place of explicit IP ranges. Azure Service Tags are a convenient way for customers to manage their networking configuration to allow traffic from specific Azure services. Customers can easily allow access by adding the tag name azuredevops to their network security groups or firewalls either through the portal or programmatically. Imports can be queued as either a dry run or a production run. The ImportType parameter determines the import type: DryRun: Use a dry run for test purposes. The system deletes dry runs after 21 days. ProductionRun: Use a production run when you want to keep the resulting import and use the organization full time in Azure DevOps Services after the import finishes. We always recommend that you complete a dry-run import first.
- 410. Dry-run organizations Run an import Dry-run imports help teams test the migration of their collections. Organizations are expected not to remain around forever but to exist for a short time. In fact, before a production migration can be run, any completed dry-run organizations will need to be deleted. All dry-run organizations have a limited existence and are automatically deleted after a set period of time. Information about when the organization will be deleted is included in the success email you should receive after the import finishes. Be sure to take note of this date and plan accordingly. Most dry-run organizations have 15 days before they're deleted. Dry-run organizations can also have a 21-day expiration if more than 100 users have a basic or greater license at import time. After the specified time period, the dry-run organization is deleted. You can repeat dry-run imports as many times as you need before you do a production migration. You need to delete any previous dry runs before you attempt a new one. When your team is ready to perform a production migration, you'll need to manually delete the dry-run organization. For more information about post-import activities, see the post import article. If you encounter any import problems, see Troubleshoot import and migration errors. Your team is now ready to begin the process of running an import. We recommend that you start with a
- 411. NOTE NOTE NOTE Considerations for rollback plans Queue an import IMPORTANT Migrator import /help successful dry-run import before you attempt a production-run import. With dry-run imports, you can see in advance how an import will look, identify potential issues, and gain experience before you head into your production run. If you need to repeat a completed production-run import for a collection, as in the event of a rollback, contact Azure DevOps Services Customer Support before you queue up another import. Azure administrators can prevent users from creating new Azure DevOps organizations. If the Azure AD tenant policy is turned on, your import will fail to finish. Before you begin, verify that the policy isn't set or that there is an exception for the user that is performing the migration. For more information, see Restrict organization creation via Azure AD tenant policy. Azure DevOps Services does not support per-pipeline retention policies, and they will not be carried over to the hosted version. A common concern for teams that are doing a final production run is what their rollback plan will be if anything goes wrong with import. This is why we highly recommend doing a dry run to make sure that you're able to test the import settings you provide to the data migration tool for Azure DevOps. Rollback for the final production run is fairly simple. Before you queue the import, you detach the team project collection from Azure DevOps Server or Team Foundation Server, which will make it unavailable to your team members. If for any reason you need to roll back the production run and bring the on-premises server back online for your team members, you can do so. You simply attach the team project collection on-premises again and inform your team that they'll continue to work normally while your team regroups to understand any potential failures. Before you proceed, ensure that your collection was detached prior to generating a DACPAC file or uploading the collection database to a SQL Azure VM. If you don't complete this step, the import will fail. In the event that your import fails, see Troubleshoot import and migration errors. You start an import by using the data migration tool's import command. The import command takes an import specification file as input. It parses the file to ensure that the provided values are valid and, if successful, it queues an import to Azure DevOps Services. The import command requires an internet connection, but does not require a connection to your Azure DevOps Server instance. To get started, open a Command Prompt window, and change directories to the path to the data migration tool. We recommended that you take a moment to review the help text provided with the tool. Run the following command to see the guidance and help for the import command:
- 412. Migrator import /importFile:{location of import specification file} Migrator import /importFile:C:DataMigrationToolFilesimport.json NOTE Related articles The command to queue an import will have the following structure: Here is an example of a completed import command: After the validation passes, you'll be asked to sign in to Azure AD. It's important to sign in with an identity that's a member of the same Azure AD tenant as the identity map log file was built against. The user that signs in becomes the owner of the imported organization. Each Azure AD tenant is limited to five imports per 24-hour period. Only imports that are queued count against this cap. When your team initiates an import, an email notification is sent to the user that queued the import. About 5 to 10 minutes after it queues the import, your team can go to the organization to check on the status. After the import finishes, your team is directed to sign in, and an email notification is sent to the organization owner. Migrate options Post-import
- 413. Import large collections 6/9/2022 • 12 minutes to read • Edit Online Determine if you can reduce the collection size IMPORTANT Set up a SQL Azure VM to import to Azure DevOps Services Set up a SQL Azure VM Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 For databases that the data migration tool warns are too big, a different data packaging approach is required to migrate to Azure DevOps Services. If you're unsure whether your collection exceeds the size threshold, you should run a data migration tool validation on the collection. The validation lets you know whether you need to use the SQL Azure VM method for import. Before you proceed, we recommend checking to see whether your old data can be cleaned up. Over time, collections can build up very large volumes of data. This is a natural part of the DevOps process, but you might find that you don't need to retain all of the data. Some common examples of no longer relevant data are older workspaces and build results. Cleaning older, no-longer-relevant artifacts could remove a lot more space than you might expect, and it could determine whether you use the DACPAC import method or a SQL Azure VM. After you've deleted older data, it can't be recovered unless you restore an older backup of the collection. If you're under the DACPAC threshold, follow the instructions to generate a DACPAC for import. If you still can't get the database under the DACPAC threshold, you need to set up a SQL Azure VM to import to Azure DevOps Services. Let's walk through how to accomplish this. At a high level, you'll: Set up a SQL Azure VM. (Optional) Restrict access to Azure DevOps Services IPs only. Configure IP firewall exceptions. Restore your database on the VM. Configure your collection for import. Configure the import specification file to target the VM You can set up a SQL Azure VM from the Azure portal with just a few clicks. To learn how, see Use the Azure portal to provision a Windows virtual machine with SQL Server. Azure DevOps Services is available in several Azure regions across the globe.
- 414. IMPORTANT DESIRED IMPORT REGION SQL AZURE VM REGION Central United States Central US Western Europe West Europe Australia East Australia East Brazil South Brazil South South India South India Central Canada Canada Central Asia Pacific Southeast Asia (Singapore) UK South UK South NOTE (Optional) Restrict access to Azure DevOps Services IPs only To ensure that the import starts successfully, it's critical to place your data in the correct region. If you set up your SQL Azure VM in a location other than the regions listed in the following table, the import will fail to start. If you're using this import method, determine where to create your SQL Azure VM by referring to the following table. Creating your VM in a region other than those in this list is not supported for running an import. Although Azure DevOps Services is available in multiple regions in the US, only the Central United States region accepts new organizations. Companies can't import their data into other US Azure regions at this time. DACPAC customers should consult the region table in the "Step 3: Upload the DACPAC file" section. The preceding guidelines are for SQL Azure VMs only. Here are a few more SQL Azure VM configurations that we recommend: Use D Series VMs, because they're optimized for database operations. Ensure that the D Series VMs have at least 28 gigabytes (GB) of RAM. For imports, we recommend Azure D12 V2 VM sizes. Configure the SQL temporary database to use a drive other than drive C. Ideally the drive should have ample free space; at least equivalent to your database's largest table. If your source database is still over 1 terabyte (TB) after you've reduced its size, you need to attach additional 1-TB disks and combine them into a single partition to restore your database on the VM. If your collection databases are over 1 TB in size, consider using an SSD for both the temporary database and collection database. Also, consider using larger VMs with 16 virtual CPUs (vCPUs) and 128 GB of RAM. You need to have a public facing IP address for the service to reach this machine. We highly recommend that you restrict access to your VM to only IPs from Azure DevOps Services. You do this
- 415. NOTE SERVICE IP ADDRESS Azure DevOps Services Identity Service 168.62.105.45, 40.81.42.115 SERVICE IP ADDRESS Regional Identity Service - Central United States 13.89.236.72, 52.165.41.252, 52.173.25.16, 13.86.38.60, 20.45.1.175, 13.86.36.181, 52.154.53.1, 52.158.209.56, 20.37.138.122, 20.37.158.0/23, 20.37.139.247, 20.37.158.5 Regional Identity Service - West Europe 20.67.123.240, 52.166.54.85, 13.95.233.212, 52.236.145.119, 52.142.235.223, 52.236.147.103, 23.97.221.25, 52.233.181.148, 52.149.110.153, 51.144.61.32, 52.236.147.236, 40.74.28.0/23 Regional Identity Service - Australia East 13.75.145.145, 40.82.217.103, 20.188.213.113, 104.210.88.194, 40.81.62.114, 20.37.194.0/24 Regional Identity Service - Brazil South 20.40.114.3, 191.235.90.183, 191.232.38.181, 191.233.25.175, 191.235.226.0/24 Regional Identity Service - India South 104.211.227.29, 40.81.75.130, 52.172.54.122, 52.172.49.252, 20.41.194.0/24 Regional Identity Service - Canada Central 52.237.19.6, 40.82.190.38, 52.228.82.0/243 Regional Identity Service - Asia Pacific (Singapore) 20.195.68.0/24 Regional Identity Service - UK South 40.81.159.67, 51.104.26.0/24 Next, grant access to the data migration tool for Azure DevOps itself. You need to grant an exception for the data migration tool instance only in the region that you're importing into. by allowing connections only from the set of Azure DevOps Services IPs that are involved in the collection database import process. The IPs that need to be granted access to your collection database depend on the region you're importing into. The following tables can help you identify the correct IPs. The only port that's required to be opened to connections is the standard SQL connection port 1433. First, no matter what Azure DevOps Services region you import into, you must grant the following IP addresses access to your collection database. In the following table, the two IP addresses listed with x.x.x.0/23 indicate a range. Allow the entire /23 range. For example, if you're importing into the Central United States region, allow the /23 range for 20.37.158.0. For IP addresses with x.x.x.0/24, allow the /24 range. Next, grant access to the Regional Identity Service. You need to grant an exception for the data migration tool instance only in the region that you're importing into.
- 416. SERVICE IP ADDRESS Data migration tool - Central United States 52.173.74.9, 52.165.184.188, 20.45.1.234, 13.86.39.123 Data migration tool - West Europe 40.115.43.138, 13.95.15.128, 52.236.146.105, 40.67.219.89, 40.119.145.63, 52.142.236.228, 52.142.238.75 Data migration tool - Australia East 13.75.134.204, 40.82.219.41, 20.40.124.19 Data migration tool - Brazil South 104.41.24.164, 20.40.115.123 Data migration tool - India South 13.71.120.31, 40.81.76.137 Data migration tool - Canada Central 52.237.18.100, 52.237.24.61, 40.82.191.163 Data migration tool - Asia Pacific (Singapore) 20.195.68.0/24 Data migration tool - UK South 40.81.153.223, 51.105.8.98, 51.104.26.2 Next, grant Azure DevOps Services access. Again, you need to grant an exception for the Azure DevOps Services instance only in the region that you're importing into. SERVICE IP ADDRESS Azure DevOps Services - Central United States 13.89.236.72, 52.165.41.252, 52.173.25.16, 13.86.38.60, 20.45.1.175, 13.86.36.181, 52.158.209.56 Azure DevOps Services - West Europe 52.166.54.85, 13.95.233.212, 52.236.145.119, 52.142.235.223, 52.236.147.103, 23.97.221.25, 52.233.181.148, 52.149.110.153, 51.144.61.32, 52.236.147.236 Azure DevOps Services - Australia East 13.75.145.145, 40.82.217.103, 20.188.213.113, 104.210.88.194, 40.81.62.114 Azure DevOps Services - Brazil South 20.40.114.3, 191.235.90.183, 191.232.38.181, 191.233.25.175 Azure DevOps Services - India South 104.211.227.29, 40.81.75.130, 52.172.54.122, 52.172.49.252 Azure DevOps Services - Canada Central 52.237.19.6, 40.82.190.38 Azure DevOps Services - Asia Pacific (Singapore) 20.195.68.0/24 Azure DevOps Services - UK South 40.81.159.67, 51.105.8.98, 51.104.26.2, 51.104.26.5 Next, grant Azure Pipelines Releases service access. You need to grant an exception for the Azure DevOps Services instance only in the region that you're importing into. Release Management IPs
- 417. SERVICE IP ADDRESS Releases service - United States 23.102.153.83, 23.101.127.247, 23.100.85.250, 13.86.39.233, 40.80.217.53, 52.232.229.122 Releases service - West Europe 13.95.223.69, 104.45.64.13 Releases service - Australia East 13.73.204.151, 20.40.176.135 Releases service - Brazil South 191.235.94.154, 20.40.116.69 Releases service - India South 52.172.15.233, 40.81.79.60 Releases service - Canada Central 52.237.28.171, 40.82.189.127 Releases service - Asia Pacific (Singapore) 20.195.68.0/24 Releases service - UK South 40.81.156.207 SERVICE IP ADDRESS Azure Artifacts - United States 52.173.148.93, 104.43.253.181, 23.99.179.148, 40.80.222.154, 40.119.0.130, 40.119.0.139, 13.86.125.169, 20.41.44.47, 40.90.219.165 Azure Artifacts - West Europe 104.46.45.12, 52.236.148.212 Azure Artifacts - Australia East 13.73.100.166, 20.40.176.15, 40.81.59.69 Azure Artifacts - Brazil South 191.234.179.224, 20.40.115.214 Azure Artifacts - India South 52.172.11.191, 40.81.74.79 Azure Artifacts - Canada Central 52.237.24.224, 40.85.224.121, 13.71.189.199, 40.82.188.122 Azure Artifacts - Asia Pacific (Singapore) 20.195.68.0/24 Azure Artifacts - UK South 51.145.120.132 SERVICE IP ADDRESS Azure Artifacts Feed - United States 52.173.251.89, 20.45.1.3, 40.67.190.224, 20.41.58.125, 40.119.1.14, 20.45.1.249 Next, grant Azure Artifacts access. Again, you need to grant an exception for the Azure DevOps Services instance only in the region that you're importing into. Azure Artifacts IPs Add exceptions for all three services that make up Azure Artifacts.
- 418. Azure Artifacts Feed - West Europe 40.118.19.43, 52.236.146.118 Azure Artifacts Feed - Australia East 13.70.143.138, 20.40.176.80 Azure Artifacts Feed - Brazil South 191.235.93.87, 20.40.116.17 Azure Artifacts Feed - India South 52.172.8.41,40.81.79.49 Azure Artifacts Feed - Canada Central 52.237.19.70, 40.82.188.254 Azure Artifacts Feed - Asia Pacific (Singapore) 20.195.68.0/24 Azure Artifacts Feed - UK South 51.145.120.49 SERVICE IP ADDRESS SERVICE IP ADDRESS Azure Artifacts Blob - United States 70.37.94.103, 40.78.129.25, 40.67.155.236, 52.230.216.163, 20.45.3.51 Azure Artifacts Blob - West Europe 23.97.221.25 Azure Artifacts Blob - Australia East 40.127.86.30, 20.188.213.113, 40.82.221.14 Azure Artifacts Blob - Brazil South 191.235.90.183 Azure Artifacts Blob - India South 52.172.54.122 Azure Artifacts Blob - Canada Central 52.237.16.145, 52.237.16.145, 52.233.38.115, 40.82.187.186 Azure Artifacts Blob - Asia Pacific (Singapore) 20.195.68.0/24 Azure Artifacts Blob - UK South 51.143.174.59, 40.81.152.41 SERVICE IP ADDRESS Test Plans - United States 52.253.227.131, 40.91.89.233, 20.41.47.199, 40.91.117.40, 40.91.126.113, 20.37.141.154 Test Plans - West Europe 40.119.145.57 Test Plans - Australia East 20.40.177.101 Test Plans - Brazil South 20.40.118.62 Test Plans IPs Add exceptions for Test Plans IP addresses only in the region you're migrating into.
- 419. Test Plans - India South 40.81.72.10 Test Plans - Canada Central 40.82.184.28 Test Plans - Asia Pacific (Singapore) 20.195.68.0/24 Test Plans - UK South 40.81.159.9 SERVICE IP ADDRESS SERVICE IP ADDRESS Analytics service - United States 20.41.43.22, 20.36.236.83, 20.41.40.50, 52.143.251.221, 52.242.212.199, 13.86.33.148, 13.86.39.80 Analytics service - West Europe 52.236.146.143, 52.236.146.9, 52.149.108.23 Analytics service - Australia East 20.40.179.159 Analytics service - Brazil South 20.40.113.248 Analytics service - India South 40.81.73.58 Analytics service - Canada Central 40.82.185.214 Analytics service - Asia Pacific (Singapore) 20.195.68.0/24 Analytics service - UK South 40.81.159.247 NOTE Configure IP firewall exceptions Analytics IPs (Azure DevOps Server 2019 or later only) If you included preview features with your import, add an exception for the analytics IPs only in your target import region. Alternatively, you can also use Service Tags in place of explicit IP ranges. Azure Service Tags are a convenient way for customers to manage their networking configuration to allow traffic from specific Azure services. Customers can easily allow access by adding the tag name azuredevops to their network security groups or firewalls either through the portal or programmatically. Granting exceptions for the necessary IPs is handled at the Azure networking layer for your SQL Azure VM. To get started, go to your SQL Azure VM in the Azure portal. In Settings, select Networking. This will take you to the network interface page for your SQL Azure VM. The data migration tool requires the Azure DevOps Services IPs to be configured for inbound connections only on port 1433. You can grant exceptions for the IPs by selecting Add inbound port rule in the networking settings.
- 420. On the Add inbound security rule pane, select Advanced to configure an inbound port rule for a specific IP. In the Source drop-down list, select IP Addresses, enter an IP address that needs to be granted an exception, set the Destination port range to 1433 and, in the Name box, enter a name that best describes the exception you're configuring. Depending on other inbound port rules that have been configured, you might need to change the default priority for the Azure DevOps Services exceptions so they don't get ignored. For example, if you have a "deny on all inbound connections to 1433" rule with a higher priority than your Azure DevOps Services exceptions, the data migration tool might be unable to make a successful connection to your database.
- 421. Restore your database on the VM Configure your collection for import Repeat adding inbound port rules until all necessary Azure DevOps Services IPs have been granted an exception. Missing one IP could result in your import failing to start. After you set up and configure an Azure VM, you need to take your detached backup from your Azure DevOps Server instance to your Azure VM. Azure has several documented methods for how to accomplish this task. The collection database needs to be restored on your SQL instance and doesn't require Azure DevOps Server to be installed on the VM. After your collection database has been restored on your Azure VM, configure a SQL login to allow Azure DevOps Services to connect to the database to import the data. This login allows only read access to a single
- 422. ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE; USE [<database name>] CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>' CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo] EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>' ALTER DATABASE [Foo] SET RECOVERY SIMPLE; USE [Foo] CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!' CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo] EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam' NOTE Configure the import specification file to target the VM database. To start, open SQL Server Management Studio on the VM, and then open a new query window against the database to be imported. Set the database's recovery to simple: Create a SQL login for the database, and assign that login the 'TFSEXECROLE': Following our Fabrikam example, the two SQL commands would look like the following: Be sure to enable SQL Server and Windows authentication mode in SQL Server Management Studio on the VM. If you don't enable authentication mode, the import will fail. Update the import specification file to include information about how to connect to the SQL Server instance. Open your import specification file and make the following updates: 1. Remove the DACPAC parameter from the source files object. The import specification before the change is shown in the following code: The import specification after the change is shown in the following code: 2. Fill out the required parameters and add the following properties object within your source object in the specification file.
- 423. Related articles "Properties": { "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" } Following the Fabrikam example, after you apply the changes, the import specification would look like the following: Your import specification is now configured to use a SQL Azure VM for import. Proceed with the rest of preparation steps to import to Azure DevOps Services. After the import has finished, be sure to delete the SQL login or rotate the password. Microsoft does not retain the login information after the import has finished. Validation and import processes
- 424. Validate and resolve errors related to process templates 6/9/2022 • 9 minutes to read • Edit Online NOTE Process validation types Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 As part of the migration import process, the data migration tool checks the process used by the projects in the collection. Fix any errors that get flagged. After resolving the errors, rerun the data migration tool's validate command to verify that all errors have been fixed. It's recommended that you use the Migration Guide to progress through your import. The guide links to the technical documentation as needed. With the release of Azure DevOps Server 2019 the TFS Database Import Service was rebranded to Migrate to Azure DevOps. This includes TfsMigrator becoming the data migration tool or migrator for short. This service still works exactly the same as the old Import Service. If you're on an older version of on-premises with TFS as the branding you can still use this feature to migrate to Azure DevOps as long as you upgrade to one of the supported versions. During validation, the data migration tool determines the target process model for each project. It automatically assigns one of the following two process models to each project in the collection: Inherited process model: If the project was created with the Agile, Scrum, or CMMI process template, and was never customized. Hosted XML process model: If the project process appears to have been customized. A customized process contains custom fields, work item types, or other types of customizations. When the Hosted XML process is the targeted process model, the data migration tool validates if the customizations can be migrated. The data migration tool generates two files during the validation: DataMigrationTool.log: Contains the set of process validation errors found in the collection. Fix all process errors found to proceed with your migration. TryMatchOobProcesses.log: Lists for each project the target process model - Inheritance or Hosted XML. For projects that are set to target the Hosted XML process model, it explains why they are considered to be customized. You don't have to fix these errors, but they give you guidance what to do in case you want to migrate to the Inheritance process model. Note that once a collection is imported, you can migrate a project to an Inheritance process model. Most customers have a mix of projects within a collection. Some projects use a default process template and others use custom process templates. The data migration tool checks and validates each project accordingly. It is very possible that you'll have a mix of projects, some mapped to an Inherited process and others to a Hosted XML process. We recommend that for any project that has not been customized, that you review the TryMatchOobProcesses.log to determine if there are any errors. If so, make the adjustments accordingly so
- 425. Update to a system process Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402571: Required element PortfolioBacklog is missing from Process Configuration. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402571: Required element BugWorkItems is missing from Process Configuration. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402571: Required element FeedbackRequestWorkItems is missing from Process Configuration. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402571: Required element FeedbackResponseWorkItems is missing from Process Configuration. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Team. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField RemainingWork. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Order. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Effort. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Activity. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationStartInformation. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationLaunchInstructions. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationType. Invalid process template: WorkItem TrackingProcessProcessConfiguration.xml:: TF400572: The Project Process Settings must be configured for this feature to be used. .ConformProject.ps1 "<collection url>" "<project name>" "c:process-customization-scriptsimportagile" Resolve process errors that the project can be mapped to an Inherited process upon data import. If you started with an older version of Azure DevOps Server, odds are your projects are still using an older process template. If those projects have not been updated using the Configure Features Wizard then the data migration tool will find process errors. In some rare cases, if your process is very old, even the Configure Features Wizard won't be able to resolve the errors. Here are some examples of error messages you may receive: If you have never customized your project (added fields, work item types, etc.), then fixing these errors is actually pretty simple. If you have customized your process, then this approach won't work. You'll need to manually change the process templates so that your customizations don't get overwritten. First, make sure you know what process your project started as. Is it Scrum, Agile or CMMI? In this example, let us assume Agile. Next, go to the Process Customization Scripts provided on GitHub and download the repo. In this instance, we are going to focus on contents in the Import folder. Use the ConformProject.ps1 script to conform a project of your choosing to the Agile system process. This will update the entire project to be Agile. Make sure you do this for each and every project. Are your process templates customized? Are you using an older outdated process template? If so, you'll most likely have process validation errors. The data migration tool does an exhaustive check against your process templates. It checks to make sure that it is valid for Azure DevOps Services. Odds are that you'll need to make
- 426. NOTE Step 1 - Review errors Step 2 - Fix errors NOTE some adjustments and apply them to your collection. If you are using an OOB Agile, Scrum, or CMMI process, you probably won't see any errors in the DataMigrationTool.log. Instead, check the TryMatchOobProcesses.log for errors. If you are error free, then your project will map to an OOB process. There are several customizations that won't work in Azure DevOps Services. Make sure you review the list of customizations that are supported. If you have projects that are using an older process template, the data migration tool will find several errors. This is because your process templates hasn't been updated to match the most recent process templates. To start, try running the Configure Features Wizard for each project. This will attempt to update your process templates with the most recent features. Doing so should drastically reduce the error count. Finally, make sure you have witadmin on the machine that you intend to use to fix the process errors. This can be your local desktop. The witadmin command line tool is used in the automated scripts and is required whenever making changes to the process templates. DataMigrationTool.log file will be generated and contains the list of errors that the validation process found. To view the logs, open DataMigrationTool.log file. Search for the string "Validation - Starting validation of project 1". Each project is validated. Scan through all the projects and search for any lines that contain a prefix of [Error .... For a list of validation errors, see Resolve validation errors for process import. For each validation error, we have provided the error number, description, and the method to resolve. Once you've determined which projects have errors and the error details, fix the errors. Fixing the errors requires that you change the XML syntax and apply the changes back to the project. We recommend you don't use TFS Power Tools to do this work. Instead, we highly recommended that you modify the XML manually.
- 427. Migrator validate /collection:{collection URL} /SaveProcesses .conformproject.ps1 "<collection url>" "<project name>" "<process template folder>" To get the process template from the project add the /SaveProcesses parameter when running the data migration tool command. This command will extract the XML from the project and place it into the same folder as the logs. Extract the zip files to your local machine so that you can edit the files. Now, fix the XML. Use the logs from the DataMigrationTool.log file to determine the errors for each project. Some errors will require you to do use a witadmin changefield command. Changing a field name is the most common example. To save yourself some time, we recommend you run the witadmin changefield command and then re-run the data migration tool. Doing this will re-export the XML with the corrected names. Otherwise, you'll need to manually fix the fields in the XML syntax as well. Once you make a fix, apply the changes back to the Azure DevOps Server. To do this, depending on the changes you made, you'll need to run one or more witadmin commands. To make this easier for you, we created a PowerShell script to automate the process. The script contains all of the witadmin commands needed to conform the entire process. You can get the scripts at Process Customization Scripts. Use the import/ConformProject.ps1 script. When the script has completed, re-run the data migration tool to validate the collection. Follow steps 1 through 3 until the data migration tool generates no more validation errors.
- 428. TIP Common validation errors VS402841: Field X in work item type Bug has syncnamechanges=false but has rules making it an identity field. Identity fields must have syncnamechanges=true. Please update your process template to include this change. witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /syncnamechanges:true TF402556: For field System.IterationId to be well defined, you must name it Iteration ID and set its type to Integer. witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /name:newname TF402571: Required element BugWorkItems is missing from Process Configuration. TF402564: You've defined XX global lists. Only 64 are allowed. Related articles If you are new to XML and witadmin , we suggest you make one fix at a time and then conform. Continue this loop until all errors are resolved. In Azure DevOps Services we added a rule so that every identity field must have the syncnamechanges=true attribute. In Azure DevOps Server that rule does not apply. Therefore, the data migration tool will identify this as an issue. Don't worry, making this change on Azure DevOps Server on-prem will not cause any harm. Run the witadmin changefield command. Syntax for the command looks similar to the following: For more information on the witadmin changefield command see Manage work item fields. This error is typical for old process templates. Try running the Configure Features Wizard on each project. Alternatively you can run the follow witadmin command: This error typically occurs when a process hasn't been updated in a while. Try running the configure features wizard on each project to resolve. By default, Azure DevOps Services will support 64 global lists. You'll typically run across this error if you have a large amount of build pipelines. The global list named Builds - TeamProjectName gets created for each new build pipeline. You'll need to remove the outdated global lists. Migration and process model FAQs witadmin : Customize and manage objects for tracking work Differences between Azure DevOps Services and Azure DevOps Server process template customizations Configure features after Azure DevOps Server upgrade Resolve validation errors Define global lists in Azure DevOps Server Process customization PowerShell scripts
- 429. Post import 6/9/2022 • 5 minutes to read • Edit Online NOTE Immediately after import Set up billing Manage users and access Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 An organization is ready for use once an import has completed successfully. However, there are common tasks that you should perform before opening the organization up to all of your users. Below is a list of the most common after import tasks that should be completed. Tasks are listed in recommended order of completion. It's recommended that you use the Migration Guide to progress through your import. The guide links to the technical documentation as needed. With the release of Azure DevOps Server 2019 the TFS Database Import Service has been rebranded to become data migration tool for Azure DevOps. This includes TfsMigrator becoming the data migration tool or migrator for short. This service still works exactly the same as the old Import Service. If you're on an older version of on-premises with TFS as the branding you can still use this feature to migrate to Azure DevOps as long as you upgrade to one of the supported versions. Immediately after the organization becomes available you will want to take a small team and perform spot checks on the organization. It's recommended that this team consists of the project collection administrators. This shouldn't be an in-depth check, but rather making sure that major pieces from your collection were brought over. Did your source code get imported? Are you seeing your build history? Are all of our area paths still present? It's best to confirm these artifacts are present before opening the organization to the entirety of your user base. After spot checking the organization you will want to consider if you want to rename it. Renaming an organization is a simple operation, but it has large impacts on users currently using the organization. Some examples being Team Explore connections breaking or bookmarks no longer working. Getting a rename out of the way while it's just a small group of users using the organization allows the rest of the users to come in and configure their connections once. To pay for users or services in Azure DevOps Services, like hosted build and deployment agents, you need to set up billing for your organization. If you import more than one collection, you should ensure all your organizations are set up for billing with the same Azure subscription, and that your subscription is enabled for multi-organization billing. You can then assign as many Basic users as you need free of charge during the calendar month in which you run the import. Your organization includes 5 free users with Basic access. Basic includes features like Git and Team Foundation version control, tools for Agile planning and Java teams, and more. Also, you can add Visual Studio subscribers for free—they get basic features plus additional features—based on their subscription level. Also, you can add Stakeholder for free, which allows them to have partial access to Agile tools, create work items, and view backlogs and boards.
- 430. Builds Release management Azure Artifacts Azure Boards As Visual Studio subscribers log in to the organization, they are automatically detected. For all other users, you need to assign paid access. Keep in mind, if you automate access using group rules, the rules only apply to existing users if you remove direct assignments, which were applied to users during import. Behavior change—Starting between Monday, November 11th and Wednesday, November 13th, the default access behavior for imports will change. Previously, all imports tried to give users an equivalent access level post import. This means that users that had Basic received Basic access, and other users started with Stakeholder access. Once this change happens, all users will start out with free Stakeholder access. You will continue to be able to assign Basic access to any users who need it at no cost, until the end of the calendar month during which your import is run. If you have any questions or concerns about this change, feel free to contact us. Next, you will want to configure your build agents. As part of the migration, all of your build pipelines have been brought over, but agents and pools need to be reconfigured against the new organization. Azure DevOps Services offers the ability to use a Microsoft-hosted pool of build agents that you can use, or you can connect your self-hosted build agent(s). It's important to note that only one self-hosted build agent is included for free. After that there is a fee for having additional self-hosted build agents. To pay for Microsoft-hosted and self- hosted build agents you will need to link a subscription to your organization. See the following resources for details on performing this task: Build Agents If you plan on using your existing on-premises private build agents, there is one more recommended step that needs to be taken after registering them to your new organization. Clearing their cache will ensure that you don't encounter any build issues related to older TFVC or Git pointers to your on-premises collection. See refreshing caches on client computers for details on how to accomplish this task. If you used Release Management in Azure DevOps Server then your release pipelines and history data will be included with your import. However, like builds, you'll need to reconfigure your agents and pools against the new organization. Azure Artifacts is included with Azure DevOps Services for all users granted a Basic license. There is no need to install an extension. Your Azure Artifacts data should be available post import. If you have an existing GitHub Enterprise Server connection associated with your Azure DevOps Server, it will not work as expected. Work item mentions within GitHub may be delayed or never show up in Azure DevOps Services. This problem occurs because the callback URL associated with GitHub is no longer valid. To resolve the problem, consider the following: Remove and re-create the connection: Remove and re-create the connection to the GitHub Enterprise Server repository. Follow the sequence of steps provided in Connect from Azure Boards documentation. Fix the webhook url: Go to GitHub's repository settings page and edit the webhook url to point out to the migrated Azure DevOps Services organization url: https://dev.azure.com/{OrganizationName}/_apis/work/events?api-version=5.2-preview
- 431. Notify your teams After getting your builds running and license subscription configured, it's recommended that the organization be opened up to all users for validation. This is when individual users can ensure that all of the content is in place, they have the right access level, and that they can pull code. Be sure to point users to our documentation on connecting to Azure DevOps Services from all of our supported IDEs and Team Explorer. Users of TFVC with local workspaces will need to remap their workspaces against the new organization and Git users will have to reconfigure their remotes to be able to pull code. If anything is reported as missing from the migrated organization, please reach out to AzureDevOpsImport@microsoft.com. For other functional issues, please reach out to customer support.
- 432. Troubleshoot import and migration errors 6/9/2022 • 19 minutes to read • Edit Online NOTE Resolve size warnings Database size above recommended size The database is currently {Database Size}GBs. This is above the recommended size of {DACPAC Size Limit}GBs to use the DACPAC import method. Please see the following page to learn how to import using a SQL Azure VM: https://aka.ms/AzureDevOpsImportLargeCollection Table size above recommended size The largest table size is currently {Table size}GBs. This is above the recommended size of {Size limit}GBs to use the DACPAC import method. Please see the following page to learn how to import using a SQL Azure VM: https://aka.ms/AzureDevOpsImportLargeCollection Database metadata size above recommended size Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 The data migration tool flags errors that you need to correct prior to performing a migration to Azure DevOps Services. This article describes the most common warnings and errors that you may receive when preparing to migrate. After correcting each error, run the migrator validate command again to verify resolution of all errors. We recommended that you use the Migration guide to progress through your import. The guide links to the technical documentation as needed. With the release of Azure DevOps Server 2019, the Team Foundation Server (TFS) Database Import Service was re- branded to become the data migration tool for Azure DevOps. The data migration tool, TfsMigrator has been renamed migrator for short. The service still works exactly the same as the previous import service. If you're on an older version of on-premises with TFS as the branding, you can still use migrator to migrate to Azure DevOps as long as you upgrade to one of the supported versions. For details, see Migrate data from Azure DevOps Server to Azure DevOps Services. Extra-large collections may generate one of the following messages after running the data migration tool. If you receive any of these warnings or errors, we recommend that you try to reduce your database's size. The following warning means you need to use the SQL Azure VM method to complete your import. Once a database reaches a certain size, it becomes faster to setup a SQL Azure VM to complete the import to Azure DevOps Services. To setup the VM and complete your import, follow the instructions linked from the warning message. This warning DOES NOT mean that your collection is too large for import. Similar to the previous warning, the following warning means you must use the SQL Azure Virtual Machine (VM) method to complete the import. Follow the instructions linked from the warning message to setup the VM and complete your import. This warning DOES NOT mean that your collection is too large for import.
- 433. The database metadata size is currently {Metadata Size}GBs. This is above the recommended size of {Warning Size}GBs. It's recommended that you consider cleaning up older data as described in [Cleaning up old data] (/azure/devops/server/upgrade/clean-up-data). Database metadata size above maximum supported size The database metadata size is currently {Metadata Size}GBs. This is above the maximum supported size of {Metadata Limit}GBs. Resolve collation warnings No native support The collection database's collation '{collation}' is not natively supported in Azure DevOps Services. Importing your collection will result in your collation being converted to one of the supported Azure DevOps Services collations. See more details at https://aka.ms/AzureDevOpsImportCollations No native support, no internet connection The following warning means that your database is approaching the limit for total metadata size. Metadata size refers to the size of your database without including files, code, and other binary data. We recommend that you reduce the size of your database before import. Reducing the size provides the additional benefit of speeding up your import. The warning DOES NOT mean that your collection is too large for import, rather its metadata size is larger than the vast majority of other databases. Unlike the previous warnings, the following error WILL block you from moving forward with your migration. It indicates that the volume of metadata in your collection is too large. To proceed with the import, you need to reduce the size below the indicated limit. Collation warnings refer to your collection database's collation. Collations control the way string values are sorted and compared. Collections that aren't using either SQL_Latin1_General_CP1_CI_AS or Latin1_General_CI_AS will generally receive one of the warning messages. Receiving the following warning means that you need to consider collation implications before performing the import. This warning DOES NOT mean that you can't import your collection. This warning requires you to acknowledge acceptance of the warning. Accepting the warning allows the data migration tool to continue import preparations. When you import a non-supported collation into Azure DevOps Services, the collation is transformed to a supported collation. While this transform generally works without issue, unexpected results post import or import failures could occur. For instance, customers may notice different ordering for strings containing non-English characters. Non- English characters like 'é' may become equivalent to the English 'e' after import. It's important that you complete and verify a dry run import when importing a collection with a non-supported collation. If the data migration tool can't connect to the internet, it can't validate conversion of your collation. It's only a warning, so you can continue with your migration process. However, when you run the prepare command, an internet connection is required and collation conversion is validated at that time.
- 434. The collections database's collation '{collation}' is not natively supported in Azure DevOps Services. It could not be validated that the collation can be converted during import to a supported Azure DevOps Services collation, as there was no internet connection. Please run the command again from a machine with an internet connection. See more details at https://aka.ms/AzureDevOpsImportCollations Unsupported database collation The collection database's collation '{collation}' is not supported for import to Azure DevOps Services. It will need to be changed to a supported collation before it can be imported. See more details at https://aka.ms/AzureDevOpsImportCollations Resolve identity errors ISVError: 100014 Project Collection Valid Users error message TFSSecurity.exe /a+ Identity "{scope}" Read sid:{Group SID} ALLOW /collection:{collectionUrl} ISVError:100014 Missing permission for group:Microsoft.TeamFoundation.Identity;S-1-9-XXXXXXXXXX-XXXXXXXXXX- XXXXXXXXXX-XXXXXXXXXX-0-0-0-0-3 for scope:397c326b-b97c-4510-8271-75aac13de7a9. Expected:1 and Actual:0 Generally you can convert a non-supported collation to a supported collation at import time. However, some collations can't be converted. If your collection uses one of these collations, you'll receive the following error message. In order to continue, you need to change your collection's collation to one of the supported collations on Azure DevOps Services. Identity errors aren't common when validating a collection, but when they do occur you need to fix them prior to migration to avoid undesired results. Generally, identity problems stem from valid operations on previous versions of TFS that are no longer valid on your current Azure DevOps Server version. For example, while it was once allowed for some users to be members of a built-in valid users group, it isn't in the more recent versions. The following sections provide guidance for resolving the most common identity errors. This error indicates that a permission is missing from a system security group. For example, every collection that you create has Project Collection Valid Users and Project Collection Administrators groups. The system creates them by default. These groups don't support editing of their permissions. This error indicates that one or more groups is missing a permission that it's expected to have. To resolve this error, use the TFSSecurity.exe command to apply the expected permissions onto the flagged system groups. Your first step is to identify which TFSSecurity command(s) you need to run. Examine the error message(s) the data migration tool highlighted. If the flagged group ends with "0-0-0-0-3", such as in the following example, you need to fix a missing permission for the Project Collection Valid Users group. Run the following command, replace the scope with the one from the error message and specify your collection URL. You determine the scope and group security ID (SID) from the error message. The final command appears similar to the following entry:
- 435. TFSSecurity.exe /a+ Identity "397c326b-b97c-4510-8271-75aac13de7a9" Read sid:S-1-9-XXXXXXXXXX-XXXXXXXXXX- XXXXXXXXXX-XXXXXXXXXX-0-0-0-0-3 ALLOW /collection:https://localhost:8080/defaultcollection Project Collection Administrators error message TFSSecurity.exe /a+ Identity "{scope}" Read sid:{Group SID} ALLOW /collection:{collectionUrl} TFSSecurity.exe /a+ Identity "{scope}" Write sid:{Group SID} ALLOW /collection:{collectionUrl} TFSSecurity.exe /a+ Identity "{scope}" Delete sid:{Group SID} ALLOW /collection:{collectionUrl} TFSSecurity.exe /a+ Identity "{scope}" ManageMembership sid:{Group SID} ALLOW /collection:{collectionUrl} ISVError:100014 Missing permission for group:Microsoft.TeamFoundation.Identity;S-1-9-XXXXXXXXXX-XXXXXXXXXX- XXXXXXXXXX-XXXXXXXXXX-0-0-0-0-1 for scope:0c7c2216-fa4b-4107-a203-82b324a147ef. Expected:15 and Actual:0 TFSSecurity.exe /a+ Identity "0c7c2216-fa4b-4107-a203-82b324a147ef" Read sid:S-1-9-XXXXXXXXXX-XXXXXXXXXX- XXXXXXXXXX-XXXXXXXXXX-0-0-0-0-1 ALLOW /collection:https://localhost:8080/defaultcollection TFSSecurity.exe /a+ Identity "0c7c2216-fa4b-4107-a203-82b324a147ef" Write sid:S-1-9-XXXXXXXXXX-XXXXXXXXXX- XXXXXXXXXX-XXXXXXXXXX-0-0-0-0-1 ALLOW /collection:https://localhost:8080/defaultcollection TFSSecurity.exe /a+ Identity "0c7c2216-fa4b-4107-a203-82b324a147ef" Delete sid:S-1-9-XXXXXXXXXX- XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-0-0-0-0-1 ALLOW /collection:https://localhost:8080/defaultcollection TFSSecurity.exe /a+ Identity "0c7c2216-fa4b-4107-a203-82b324a147ef" ManageMembership sid:S-1-9-XXXXXXXXXX- XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-0-0-0-0-1 ALLOW /collection:https://localhost:8080/defaultcollection ISVError: 300005 IMPORTANT Carefully examine the error message(s) the data migration tool highlighted. If the flagged group that ends with "0-0-0-0-1", such as in the following example, then you will need to fix a missing permission for the Project Collection Administrators group. Run the following commands against TFSSecurity.exe, replace the scope with the one from the error message and specify your collection. In the following example, take the scope and group SID from the error message and add them to the preceding command. The final command appears similar to the following entry: When you need to correct multiple errors, we recommend that you create a batch file to automate execution of the commands. Once you've executed the commands, you need to rerun the data migration validate tool to verify resolution. If some errors still persist, contact Azure DevOps Services customer support. ISVError: 300005 indicates that a non-group identity is a member of an everyone group, more commonly known as the Valid Users groups. Valid Users groups are default groups defined for all projects and collections. These groups are not editable. They are designed to only contain other Azure DevOps permission or security groups as members. This error indicates that an Active Directory (AD) group or user identity has a direct membership in a Valid Users group. Ensure that you have a backup of your collection and configuration databases before running the following commands to resolve the error. Since you can't directly edit Valid Users groups, you need to run a SQL statement against the configuration
- 436. DECLARE @p6 dbo.typ_GroupMembershipTable INSERT into @p6 values('{GroupSid}','Microsoft.TeamFoundation.Identity','{MemberId}',0) EXEC prc_UpdateGroupMembership @partitionId=1,@scopeId='{ScopeId}',@idempotent=1,@incremental=1,@insertInactiveUpdates=0,@updates=@p6,@even tAuthor='9EE20697-5343-43FC-8FC5-3D5D455D21C5',@updateGroupAudit=0 ISVError:300005 Unexpected non group identity was found to have direct membership to everyone group. GroupSid:S-1-9-1551374245-3746625149-2333054533-2458719197-2313548623-0-0-0-0-3, MemberId:76050ddf-4fd8- 48c4-a1ff-859e44364519, ScopeId:7df650df-0f8b-4596-928d-13dd89e5f34f ISVError:300005 Unexpected non group identity was found to have direct membership to everyone group. GroupSid:S-1-9-1551374245-3746625149-2333054533-2458719197-2313548623-0-0-0-0-3, MemberSid:System.Security.Principal.WindowsIdentity;S-1-5-21-124525095-708259637-1543119021-1737349, ScopeId:7df650df-0f8b-4596-928d-13dd89e5f34f DECLARE @MemberId uniqueidentifier SET @MemberId = (Select Id from dbo.tbl_Identity where Sid ='S-1-5-21-124525095-708259637-1543119021- 1737349'); SELECT @MemberId DECLARE @p6 dbo.typ_GroupMembershipTable INSERT into @p6 values('S-1-9-1551374245-3746625149-2333054533-2458719197-2313548623-0-0-0-0- 3','Microsoft.TeamFoundation.Identity','76050ddf-4fd8-48c4-a1ff-859e44364519',0) EXEC prc_UpdateGroupMembership @partitionId=1,@scopeId='7df650df-0f8b-4596-928d- 13dd89e5f34f',@idempotent=1,@incremental=1,@insertInactiveUpdates=0,@updates=@p6,@eventAuthor='9EE20697- 5343-43FC-8FC5-3D5D455D21C5' database to remove the offending identity and correct the invalid membership. Carefully examine the error messages highlighted by the data migration tool. Copy the GroupSid , MemberId , and ScopeId as you'll need to place these values into the following command. The following example lists an example of an ISVError: 300005 message from the data migration tool. If the error message lists a MemberSid , you need to get the MemberID from the dbo.tbl_Identity table in the configuration database. With the MemberID , you can then look up the GUID for the MemberSid . Copy the GroupSid , MemberId , and ScopeId into the SQL command. Run the completed command against the Azure DevOps Server configuration database. You'll need to repeat this command for each ISVError: 300005 instance reported. You can batch errors with the same scope ID into a single command. Once you've executed the commands, rerun the data migration tool validate again to ensure that the errors have been corrected. If the errors still persist, contact Azure DevOps Services customer support.
- 437. IMPORTANT Azure Active Directory timeout exception Exception Message: Request failed (type AadGraphTimeoutException) //Install the AzureAD PowerShell module - ensuring to select Yes to All Install-Module AzureAD // Install the MSOnline PowerShell module - ensuring to select Yes to All Install-Module MSOnline // Connect to Azure AD and use your Azure AD credentials (someone@somecompany.com) to login when the pop-up appears Connect-MsolService // Try to retrieve information on a user from your Azure AD Get-MsolUser -UserPrincipalName someone@somecompany.com Number of active users is {Number of Users}. Resolve process errors To address these errors, the collection must be attached. If you receive a -1 result when you run the command, ensure that your collection database that produced the error is attached to your Azure DevOps Server instance and that you're running the command on the configuration database. On rare occasions, you may receive an Azure Active Directory (Azure AD) timeout error when running the data migration tool prepare command. This error means that the requests to Azure AD to find the matching Azure AD identities for users in your collection timed out. Generally, you can resolve this error by waiting to run the prepare command at a less busy time of the day, such as after regular business hours. In the event that the error continues, you should undertake a few troubleshooting steps. First, you will want to test your connection to Azure AD from the machine running the prepare command. Execute the following steps to retrieve information on a user in your Azure AD. Open PowerShell in elevated mode and replace 'someone@somecompany.com' in the following command with your Azure AD user identity. If any of the above steps fail or you're unable to look up a user's identity, a connection issue may exist between the machine running the prepare command and Azure AD. Run a network trace while executing the prepare command to ensure that nothing within your network is interfering with calls reaching Azure AD. If you've confirmed that the problem isn't with your network, contact Azure support for assistance with troubleshooting. If you're able to retrieve user information, open your log file from the prepare attempt and look for a line similar to the following entry. If the number of active users is over 50,000, the volume of identities being mapped may require more time than provided by the timeout limit. Inspect your collection for inclusions of large AD groups such as an 'everyone' group. If possible, remove these groups and try again. If you still can't resolve this error, contact Azure DevOps Services customer support. See the separate Process Templates page for details on resolving common process errors.
- 438. Resolve field validation errors VS403310 VS403442 witadmin changefield /collection:http://AdventureWorksServer:8080/DefaultCollection /n:TFSfieldReferenceName /name:newFieldName VS403443 witadmin changefield /collection:http://AdventureWorksServer:8080/DefaultCollection /n:TFSfieldReferenceName /name:VSTSfieldName VS403444 witadmin changefield /collection:http://AdventureWorksServer:8080/DefaultCollection /n:TFSfieldReferenceName /type:PlainText | HTML NOTE witadmin deletefield /collection:http://AdventureWorksServer:8080/DefaultCollection /n:TFSfieldReferenceName The following error message can occur when an inconsistency in collection files is detected. Contact customer support if you encounter this error. VS403310: An inconsistency was detected in some of the files in the collection. Field name conflicts sometimes occur between your local collection and an Azure DevOps Services system field. In order to migrate successfully, you must rename field *{TFSfieldReferenceName}*. Given name * {TFSfieldName}* is reserved for field *{VSTSfieldReferenceName}*. To resolve this error, change the name of your collection field. Use the witadmin changefield command from witadmin. The following error indicates a field name conflict exists between your local collection and a specific Azure DevOps Services field. In order to migrate successfully, you must rename field *{TFSfieldReferenceName}* to *{VSTSfieldName}*. Given name for *{TFSfieldReferenceName}* is *{TFSfieldName}* To resolve this error, use the witadmin changefield command. For details, see witadmin. The following error indicates a field type conflict exists between your local collection and Azure DevOps Services. Using witadmin, you can change the data type only for HTML or PlainText fields. In order to migrate successfully, you must set type of field *{TFSfieldReferenceName}* to *{Type}*. Given type for *{TFSfieldReferenceName}* is *{collectionType}*. If your field type is HTML or PlainText, then you can change its type to the required type. If your field type is something different than HTML or PlainText and field data isn't important or the field isn't used in any project, then we recommend you delete the field.
- 439. IMPORTANT Resolve import errors Verification failures Deleting a field results in a loss of field data across the collection. Failures that occur during import fall into one of two categories, verification failure and import failure. Verification failures occur when the import fails to start. The data migration tool attempted to queue an import, but returned an error instead. Verification failure issues indicate that your import request isn't valid. Address the error messages you receive according to the following guidance and then try to import again. VS403254 The region that you entered for your Azure DevOps Services import isn't supported. VS403254: Region {0} may not be used for the Import, it is not a supported region. Open your import specification file and update the region that you've provided with the correct short name for the region. VS403249 The organization name your team has selected is already in use by an existing organization. All Azure DevOps Services imports go into a new organization that is created at import time. VS403249: The organization {0} already exists. Please select a different name and try the import again. Select a different organization name and update the import specification file before retrying the import. VS403250 & VS403286 The DACPAC isn't built off a detached collection. VS403250: The dacpac is not a detached Azure DevOps Server Collection database. VS403286: The dacpac is from a Azure DevOps Server Configuration database. You must use a detached Azure DevOps Server Collection database. Detach your collection database and generate the DACPAC again. VS403243 Unable to make a connection to the database using the provided SQL Connection String. VS403243: Unable to connect to the database using the provided SQL Connection String {0}. Review the parameters that were provided to ensure they're correct and try again. VS403260 & VS403351 The collection database isn't detached. VS403260: The database is not detached. VS403351: The DACPAC or source database is missing an expected table. It's possible that the database was not correctly detached from Azure DevOps Server. Detach your collection database and retry the import queue. VS403261
- 440. NOTE SELECT COUNT (*) as remaining_files_to_migrate FROM tbl_FileReference WHERE PartitionId > 0 AND MigrateFileId IS NOT NULL The connection string must be encrypted otherwise the password is sent in the clear. VS403261: The SQL connection string must use encryption. Add Encrypt=true to your SQL connection string. VS403262 The connection string must use SQL Authentication. VS403262: The SQL connection string must use SQL Authentication, Integrated Authentication is not supported. Add Integrated Security=False to your SQL connection string. VS403263 Your SQL sign in user account doesn't have the required database role. VS403263: The User ID {0} must be member of the database role {1}. Make sure the user account for sign in is assigned the 'TFSEXECROLE' role. There is a known issue with using sp_addrolemember to add TFSEXECROLE to an existing SQL login. The role membership isn't applied until all open connections using that identity are closed. If you receive the VS403263 error and have confirmed your identity has the role, we recommend that you create a new identity for your import. Details on how to create a new SQL login that's ready to be used for import can be found at Import large collections. VS403264 The connection string doesn't point to an Azure DevOps Server collection database. VS403264: The database is not a Azure DevOps Server Collection database, it cannot be used for import. Verify or correct the connection string points to your collection database. VS40325 The Azure DevOps Server Update has queued the file migration job. Imports can't be performed until this job has completed. The completion time for this job is dependent on the size of the collection. VS403255: The collection cannot be imported due to an ongoing post upgrade job. Please wait and try again later You can track job progress by running the following query on the collection database: Once the number of files remaining to migrate is zero, you can run the data migration tool. VS403282 A new line character exists in the source location value. This character could have remained after copying the SAS key from your windows console. VS403282: The source location parameter contains a new line character. Please ensure the SAS key is defined on a single line in the import specification file.
- 441. AzCopy.exe /Source:https://accountSCUS.blob.core.windows.net/mycontainer /SourceKey:"primary access key" /Dest:https://accountCUS.blob.core.windows.net/mycontainer /DestKey:"primary access key" /S VS403366: A problem occurred while attempting to connect to your database. Please verify that your connection string is correct and that all required IP addresses for Azure DevOps Services have been provided exceptions for your machines firewall. List of Azure DevOps Services IPs: Remove the line break and try again. VS403271 Your import files and DACPAC aren't located in the required Azure region to complete the import to your target Azure DevOps Services region. VS403271: It appears that your DACPAC was uploaded to East US. It's required that customers targeting Central US for import put their DACPACs in Central US. Please move your DACPAC to Central US and requeue the import. Create a new Windows Azure storage account in the required region and copy your files. The following example shows how to copy your data using AzCopy. VS403316 Inconsistencies were detected in some Team Foundation version control (TFVC) files within your collection. VS403316: An inconsistency was detected in some TFVC files for this collection. The inconsistency needs to be corrected prior to running an import to Azure DevOps Services. Please reach out to https://aka.ms/AzureDevOpsImportSupport for assistance with addressing this issue. Work with Azure DevOps Services customer support. Open a support ticket and they'll work with you to resolve the error. VS403366 The data migration tool was unable to connect to the SQL Azure VM. Verify that you've entered the information correctly in your connection string and that you can connect to the VM. The IPs that the error message lists are for Azure DevOps Services. Azure DevOps Services IPs can change temporarily during deployments. Add them to your firewall exceptions and try queuing the import again. For a list of IP addresses, see Import large collections, Restrict access to Azure DevOps Services IPs only VS403373 The data migration tool doesn't support importing multiple copies of the SAME collection. However, it DOES support importing split copies of a collection. Change the GUID for the DataImportCollectionID. From SQL Server Management Studio (SSMS), open the extended properties for the split copies that you haven't imported yet. Add a newly generated GUID to the "TFS_DATAIMPORT_COLLECTIONID" property. Then rerun the prepare command and use the new import.json file to queue the import. VS403379 Data import will fail as one or more projects found in this collection are in the soft-deleted stage. Please restore the soft-deleted project(s) or delete them permanently before running the data import. For details, see Delete a project. VS403379: Data import will fail as one or more projects found in this collection are in the soft-deleted stage. Please restore the soft-deleted project(s) or delete them permanently before running the data import.
- 442. Import failures Related articles Verify the collection against which you are running the data migration tool has projects in the soft-deleted stage. Once a project is deleted, it remains in a soft-delete state for 28 days during which the deleted project can be restored. You can read about how to restore a deleted project in Restore a project. If you have projects in the soft-deleted stage, remove them completely or restore them back before running data import. Import failures happen when the data migration tool successfully queues an import, but fails to complete the import. The individual that queued the import receives a failure email notification. Most of the time this email includes a reason for the failure. If it does, use the troubleshooting steps provided in the email and this page to resolve the errors and retry your import. If the error is more complex, then the email you receive provides instructions on how to file a customer support case. After submitting a customer support case, your team will need to roll back by bringing your Azure DevOps Server instance back online and reattach your collection. Your team members can then continue working. We recommended you not attempt the import again until the failure causing issue is resolved. Validate and import Post-import Delete a project Restore a project
- 444. Default permissions quick reference for Azure DevOps 6/9/2022 • 15 minutes to read • Edit Online Assign users to a security group Azure Boards Work tracking Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 To use Azure DevOps features, users must be added to a security group with the appropriate permissions and granted access to the web portal. Limitations to select features are based on the access level and security group to which a user is assigned. The Basic access level and higher supports full access to most Azure DevOps Services, except for Azure Test Plans. Stakeholder access level provides partial support to Azure Boards and Azure Pipelines. To learn more about access levels, see About access levels and Stakeholder access quick reference. The most common built-in security groups—Readers, Contributors, and Project Administrators— and team administrator role grant permissions to specific features. In general, use the following guidance when assigning users to a security group: Add to the Contributors security group full-time workers who contribute to the code base or manage projects. Add to the Project Administrators security group users tasked with managing project resources. I Add to the Project Collection Administrators security group users tasked with managing organization or collection resources. To learn more about administrative tasks see About user, team, project, and organization-level settings. For a complete reference of all built-in groups and permissions, see Permissions and groups. For information about access levels, see About access levels. In the tables provided in this article, a ✔ ️ (checkmark) indicates that the corresponding access level or security group has access to a feature by default. To assign or change an access level, see Add users and assign licenses. If you need to grant specific users select permissions, you can do so. You can plan and track work from the web portal Boards hub, and using Visual Studio, Excel, and other clients. For an overview of work tracking features, see About Agile tools. To change permissions, see Set permissions and access for work tracking. In addition to the permissions set at the project level via the built-in groups, you can set permissions for the following objects: area and iteration paths and individual queries and query folders. You can plan and track work from the web portal Work hub, and using Eclipse, Visual Studio, Excel, Project, and other clients.
- 445. NOTE General work item permissions NOTE Team administrators can configure settings for their team's tools. Organization owners and members of the Project Administrators group can configure settings for all teams. To be added as an administrator, see Add team administrators or Change project-level permissions. Access to the following tasks are controlled by each user's access level or by permission assignments. Members of the Readers, Contributors, or Project Administrators group are assumed to have Basic access or greater. You can use work items to track anything you need to track. To learn more, see Understand how work items are used to track issues, tasks, and epics. You can change the work item type or move work items to another project within a project collection. These features require that the data warehouse is disabled. With the data warehouse disabled, you can use the Analytics Service to support your reporting needs. To learn more about disabling the data warehouse, see Disable the data warehouse and cube. Task or permission Readers Contributors Project admins View work items in this node (Area Path permission) ✔ ️ ✔ ️ ✔ ️ Edit work items in this node (Area Path permission) ✔ ️ ✔ ️ Create tag definition ✔ ️ ✔ ️ Change work item type (Project-level permission) ✔ ️ ✔ ️ Move work items out of this project (Project-level permission) ✔ ️ ✔ ️ Email work items
- 446. NOTE Boards ✔ ️ ✔ ️ ✔ ️ Apply a work item template ✔ ️ ✔ ️ Delete and restore work items (Project-level permission) (able to restore from the Recycle bin) ✔ ️ ✔ ️ Permanently delete work items (Project-level permission) ✔ ️ Provide feedback (through the Microsoft Feedback client) ✔ ️ ✔ ️ Request feedback ✔ ️ ✔ ️ Work items are subject to rules applied to them. Conditional rules based on user or group membership are cached for your web browser. If you find yourself restricted to update a work item, you may have encountered one of these rules. If you believe you've encountered an issue that doesn't apply to you, see Work item form IndexDB caching issues. To learn more about conditional rules, see Rules and rule evaluation. You use Boards to implement Kanban methods. Boards present work items as cards and support quick status updates through drag-and-drop. Task Readers Contributors Team admins Project admins View boards and open work items ✔ ️ ✔ ️ ✔ ️ Add work items to a board; update status through drag-and-drop
- 447. Backlogs features access ✔ ️ ✔ ️ Reorder work items or reparent child items through drag-and-drop; update a field on a card ✔ ️ ✔ ️ Add work items to a board; update status, reorder, or reparent child items through drag-and-drop; update a field on a card ✔ ️ ✔ ️ Add child items to a checklist ✔ ️ ✔ ️ Assign to a sprint (from card field) ✔ ️ ✔ ️ Configure board settings ✔ ️ Backlogs display work items as lists. A product backlog represents your project plan and a repository of all the information you need to track and share with your team. Portfolio backlogs allow you to group and organize your backlog into a hierarchy. Task Readers Contributors Team admins Project admins View backlogs and open work items ✔ ️ ✔ ️ ✔ ️ Add work items to a backlog ✔ ️ ✔ ️ Use bulk edit features ✔ ️
- 448. Sprints ✔ ️ Add child items to a backlog item; prioritize or reorder a backlog; parent items using the Mapping pane; Assign items to a sprint using the Planning pane ✔ ️ ✔ ️ Add child items to a backlog item; prioritize or reorder a backlog; parent items using the Mapping pane; Assign items to a sprint using drag-and-drop ✔ ️ ✔ ️ Configure team settings, backlog levels, show bugs, work days off ✔ ️ You use sprint tools to implement Scrum methods. The Sprints set of tools provide filtered views of work items that a team has assigned to specific iteration paths or sprints. Task Readers Contributors Team admins Project admins View sprint backlogs, taskboards, and open work items ✔ ️ ✔ ️ ✔ ️ Add work items to a sprint backlog or taskboard ✔ ️ ✔ ️ Prioritize/reorder a sprint backlog or taskboard; add child items to a backlog item; reassign items to a sprint using the Planning pane ✔ ️ ✔ ️ View team capacity and work details ✔ ️ ✔ ️ Set team capacity ✔ ️ ✔ ️
- 449. Queries Delivery plans Use bulk edit features ✔ ️ ✔ ️ Define team sprints ✔ ️ Queries are filtered lists of work items based on criteria that you define by using a query editor. Adhoc searches are powered by a semantic search engine. Task Readers Contributors Project admins View and run managed queries, view query charts ✔ ️ ✔ ️ ✔ ️ Create and save managed My queries, query charts ✔ ️ ✔ ️ ✔ ️ Create, delete, and save Shared queries, charts, folders ✔ ️ Delivery plans display work items as cards against a calendar view. This format can be an effective communication tool with managers, partners, and stakeholders for a team. Task Readers Contributors Team admins Project admins View delivery plans ✔ ️ ✔ ️ ✔ ️ Create, edit, or delete a delivery plan, Contributors can only edit or delete plans that they create
- 450. Azure Repos Code: Source control Git ✔ ️ ✔ ️ Manage permissions for a delivery plan, Contributors can only manage permissions for plans that they create ✔ ️ ✔ ️ You can manage your source code from the web portal Repos hub, or using Xcode, Eclipse, IntelliJ, Android Studio, Visual Studio, or Visual Studio Code. Stakeholders for private projects have no access to Repos. Stakeholders for public projects have the same access to Repos as Contributors. You can connect to your code from the web portal Code hub, or using Xcode, Eclipse, IntelliJ, Android Studio, Visual Studio, or Visual Studio Code. Stakeholders for private projects have no access to Code. You can use Git repositories to host and collaborate on your source code. For an overview of code features and functions. Permission Readers Contributors Build Admins Project Admins Read (clone, fetch, and explore the contents of a repository); also, can create, comment on, vote, and Contribute to pull requests ✔ ️ ✔ ️ ✔ ️ ✔ ️ Contribute, Create branches, Create tags, and Manage notes ✔ ️ ✔ ️ ✔ ️ Create repository, Delete repository, and Rename repository ✔ ️ Edit policies, Manage permissions, Remove others' locks
- 451. TFVC NOTE Azure Pipelines TASK READERS CONTRIBUTORS BUILD ADMINS PROJECT ADMINS RELEASE ADMINS View release pipelines ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ Force push (rewrite history, delete branches and tags) ✔ ️ Bypass policies when completing pull requests (not set for any security group) Bypass policies when completing pull requests, Bypass policies when pushing, Force push (rewrite history, delete branches and tags) (not set for any security group) Team Foundation Version Control (TFVC) provides a centralized version control system to manage your source control. Tasks such as create, delete, or rename a TFVC repository are not supported. Once a TFVC repository is created you can't delete it. Also, you can only have one TFVC repository per project. This is different from Git repositories which allow for adding, renaming, and deleting multiple repositories. Permission Readers Contributors Build Admins Project Admins Check in, Label, Lock, Merge, Pend a change in a server workspace, Read Read only ✔ ️ ✔ ️ ✔ ️ Administer labels, Manage branches, Manage permissions, Revise other users' changes, Undo other users' changes, Unlock other users' changes ✔ ️ You can define and manage your builds and releases from the web portal Pipelines hub. For an overview of pipelines features and functions, see Continuous integration on any platform.
- 452. Define builds with continuous integration ✔ ️ ✔ ️ ✔ ️ Define releases and manage deployments ✔ ️ ✔ ️ ✔ ️ Approve releases ✔ ️ ✔ ️ ✔ ️ ✔ ️ Azure Artifacts (5 users free) ✔ ️ ✔ ️ ✔ ️ Queue builds, edit build quality ✔ ️ ✔ ️ ✔ ️ Manage build queues and build qualities ✔ ️ ✔ ️ Manage build retention policies, delete and destroy builds ✔ ️ ✔ ️ ✔ ️ Administer build permissions ✔ ️ ✔ ️ Manage release permissions ✔ ️ ✔ ️ Create and edit task groups ✔ ️ ✔ ️ ✔ ️ ✔ ️ Manage task group permissions ✔ ️ ✔ ️ ✔ ️ Can view library items such as variable groups ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️ Use and manage library items such as variable groups ✔ ️ ✔ ️ ✔ ️ TASK READERS CONTRIBUTORS BUILD ADMINS PROJECT ADMINS RELEASE ADMINS Build Task Readers Contributors
- 453. Build admins Project admins View builds ✔ ️ ✔ ️ ✔ ️ ✔ ️ View build pipeline ✔ ️ ✔ ️ ✔ ️ ✔ ️ Administer build permissions ✔ ️ ✔ ️ Delete or Edit build pipeline ✔ ️ ✔ ️ ✔ ️ Delete or Destroy builds ✔ ️ ✔ ️ Edit build quality ✔ ️ ✔ ️ ✔ ️ Manage build qualities ✔ ️ ✔ ️ Manage build queue ✔ ️ ✔ ️ Override check-in validation by build
- 454. Release ✔ ️ Queue builds ✔ ️ ✔ ️ ✔ ️ Retain indefinitely ✔ ️ ✔ ️ ✔ ️ ✔ ️ Stop builds ✔ ️ ✔ ️ Update build information ✔ ️ Task Stakeholders Readers Contributors Project Admins Release Admins Approve releases ✔ ️ ✔ ️ ✔ ️ ✔ ️ View releases ✔ ️ ✔ ️ ✔ ️ ✔ ️ ✔ ️
- 455. View release pipeline ✔ ️ ✔ ️ ✔ ️ ✔ ️ Administer release permissions ✔ ️ ✔ ️ Delete release pipeline or release stage ✔ ️ ✔ ️ ✔ ️ Delete releases ✔ ️ ✔ ️ ✔ ️ Edit release pipeline ✔ ️ ✔ ️ Edit release stage ✔ ️ ✔ ️ ✔ ️ Manage deployments ✔ ️ ✔ ️ Manage release approvers ✔ ️ ✔ ️ ✔ ️ Manage releases ✔ ️ ✔ ️
- 456. Task groups TASK READERS CONTRIBUTORS BUILD ADMINS PROJECT ADMINS RELEASE ADMINS Administer task group permissions ✔ ️ ✔ ️ ✔ ️ Delete task group ✔ ️ ✔ ️ ✔ ️ Edit task group ✔ ️ ✔ ️ ✔ ️ Build and Release Build You use task groups to encapsulate a sequence of tasks already defined in a build or a release pipeline into a single reusable task. Task group permissions follow a hierarchical model. You can set defaults for all permissions at the project-level and over-write on an individual task group pipeline. You define and manage task groups in the Task groups tab in Azure Pipelines. You can define and manage your builds and releases from the web portal, Build and Release. For an overview of pipelines features and functions, see Continuous integration on any platform. From the web portal, you can set permissions for all or individual builds and releases. See Set build and release permissions. Task Readers Contributors Build Admins Project Admins View builds ✔ ️ ✔ ️ ✔ ️ ✔ ️ View build definition ✔ ️ ✔ ️ ✔ ️ ✔ ️ Administer build permissions ✔ ️
- 457. Release ✔ ️ Delete or Edit build definitions ✔ ️ ✔ ️ ✔ ️ Delete or Destroy builds ✔ ️ ✔ ️ Edit build quality ✔ ️ ✔ ️ ✔ ️ Manage build qualities ✔ ️ ✔ ️ Manage build queue ✔ ️ ✔ ️ Override check-in validation by build ✔ ️ Queue builds ✔ ️ ✔ ️ ✔ ️ Retain indefinitely ✔ ️ ✔ ️ Stop builds ✔ ️ ✔ ️ Update build information ✔ ️ Task
- 458. Readers Contributors Project Admins Release Admins Approve releases ✔ ️ ✔ ️ ✔ ️ View releases ✔ ️ ✔ ️ ✔ ️ ✔ ️ View release definition ✔ ️ ✔ ️ ✔ ️ ✔ ️ Administer release permissions ✔ ️ ✔ ️ Delete release definition or release stage ✔ ️ ✔ ️ ✔ ️ Delete releases ✔ ️ ✔ ️ ✔ ️ Edit release definition ✔ ️ ✔ ️ Edit release stage
- 459. Azure Test Plans Test ✔ ️ ✔ ️ ✔ ️ Manage deployments ✔ ️ ✔ ️ Manage release approvers ✔ ️ ✔ ️ ✔ ️ Manage releases ✔ ️ ✔ ️ Users granted Basic + Test Plans or Visual Studio Enterprise access level can define and manage manual tests from the web portal. For an overview of manual test features and functions, see Testing overview. You set several test permissions at the project level from Project Settings>Permissions. Users granted Visual Studio Enterprise or Advanced access level can define and manage manual tests from the web portal. For an overview of manual test features and functions, see Testing overview. You set several test permissions at the project level from Project Settings>Permissions. Permission Level Readers Contributors Project Admins View test runs Project-level ✔ ️ ✔ ️ ✔ ️ Create test runs Delete test runs Project-level
- 460. NOTE Azure Artifacts ✔ ️ ✔ ️ Manage test configurations Manage test environments Project-level ✔ ️ ✔ ️ Create tag definition Delete and restore work items Project-level ✔ ️ ✔ ️ Permanently delete work items Project-level ✔ ️ View work items in this node Area Path ✔ ️ ✔ ️ ✔ ️ Edit work items in this node Manage test plans Manage test suites Area Path ✔ ️ ✔ ️ The Change work item type permission doesn't apply to test-specific work items. Even if you choose this feature from the work item form, changing the work item type is disallowed. You can manage feeds from the web portal, Artifacts. Users granted Stakeholder or Basic access, or higher can access Azure Artifacts features. To set permissions, see Secure feeds using permissions. You can manage feeds from the web portal, Artifacts. Users granted Basic access or higher can access Azure Artifacts features. Users granted Stakeholder access have no access to Azure Artifacts. To set permissions, see Secure feeds using permissions.
- 461. Package management PERMISSION READER COLLABORATOR CONTRIBUTOR OWNER List, install, and restore packages ✔ ️ ✔ ️ ✔ ️ ✔ ️ Push packages ✔ ️ ✔ ️ Unlist/deprecate packages ✔ ️ ✔ ️ Delete/unpublish package ✔ ️ Promote a package to a view ✔ ️ ✔ ️ Add/remove upstream sources ✔ ️ Save packages from upstream sources ✔ ️ ✔ ️ ✔ ️ Edit feed permissions ✔ ️ NOTE PERMISSION READER CONTRIBUTOR OWNER List and restore/install packages ✔ ️ ✔ ️ ✔ ️ Push packages ✔ ️ ✔ ️ Unlist/deprecate packages ✔ ️ ✔ ️ Delete/unpublish package ✔ ️ Edit feed permissions ✔ ️ You can manage feeds from the web portal, Build and release > Packages. Users granted Basic access or higher can access Package management features. Users granted Stakeholder access have no access. To set permissions, see Secure feeds using permissions. Feeds have four permission roles: Readers, Collaborators, Contributors, and Owners. Owners can add user accounts or security groups to any role. By default, the Project Collection Build Service is a Contributor and your project team is a Reader. To access a feed in a different organization, a user must be given access to the project hosting that feed. Feeds have three permission roles: Readers, Contributors, and Owners. Owners can add user accounts or security groups -to any role.
- 462. Rename and delete feed ✔ ️ PERMISSION READER CONTRIBUTOR OWNER NOTE Notifications, alerts, and team collaboration tools NOTE By default, the Project Collection Build Service is a Contributor and your project team is a Reader. To access a feed in a different organization, a user must be given access to the project hosting that feed. To manage notifications, see Manage personal notifications and Manage team notifications. There are no UI permissions associated with managing notifications. Instead, you can manage them using the TFSSecurity command line tool. Task Readers Contributors Team admins Project admins Project Collection admins View the project page, navigate using the project page ✔ ️ ✔ ️ ✔ ️ ✔ ️ Edit the project page ✔ ️ Set personal notifications or alerts ✔ ️ ✔ ️ ✔ ️ Set team notifications or alerts ✔ ️ ✔ ️ Set project-level notifications or alerts ✔ ️
- 463. Dashboards, charts, reports, and widgets View Project READMEs ✔ ️ ✔ ️ ✔ ️ ✔ ️ View Project wikis or code wikis ✔ ️ ✔ ️ ✔ ️ ✔ ️ Provision or create a project wiki ✔ ️ ✔ ️ ✔ ️ Publish code as a wiki ✔ ️ ✔ ️ ✔ ️ Request feedback ✔ ️ ✔ ️ ✔ ️ Provide feedback ✔ ️ ✔ ️ ✔ ️ ✔ ️ Search across projects, organizations, collections ✔ ️ ✔ ️ ✔ ️ ✔ ️
- 464. Power BI Integration and Analytics views You can define and manage team and project dashboards from the web portal, Dashboards. For an overview of dashboard and chart features, see Dashboards. You can set individual dashboard permissions to grant or restrict the ability to edit or delete dashboards. Users granted Stakeholder access to private projects can't view or create query charts. Stakeholder access to public projects can view and create query charts. You can define and manage team dashboards from the web portal, Dashboards. For an overview of dashboard and chart features, see Dashboards. You set dashboard permissions at the team level from the team dashboard page. Task Readers Contributors Team admins Project admins View team and project dashboards ✔ ️ ✔ ️ ✔ ️ ✔ ️ View team dashboards ✔ ️ ✔ ️ ✔ ️ Add and configure project dashboards ✔ ️ ✔ ️ Add and configure team dashboards ✔ ️ ✔ ️ ✔ ️ From the web portal Analytics views, you can create and manage Analytics views. An Analytics view provides a simplified way to specify the filter criteria for a Power BI report based on the Analytics Service data store. The Analytics Service is the reporting platform for Azure DevOps. To learn more, see What is the Analytics Service?. You set permissions for the service at the project level, and for shared Analytics views at the object level. Users with Stakeholder access have no access to view or edit Analytics views.
- 465. Related articles Task Readers Contributors Project admins View Analytics ✔ ️ ✔ ️ ✔ ️ View a shared Analytics view ✔ ️ ✔ ️ Add a private or shared Analytics view ✔ ️ ✔ ️ Edit and delete shared Analytics views ✔ ️ Add users to a project or team Security and permission management tools Permissions and groups reference About access levels Web portal navigation Troubleshoot permissions
- 466. About access levels 6/9/2022 • 9 minutes to read • Edit Online IMPORTANT Supported access levels Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 Access levels grant or restrict access to select web portal features. This is in addition to permissions granted through security groups, which provide or restrict specific tasks. Access levels enable administrators to provide their user base access to the features they need and only pay for those features. To view the content available for your platform, make sure that you select the correct version of this article from the version selector which is located above the table of contents. Feature support differs depending on whether you are working from Azure DevOps Services or an on-premises version of Azure DevOps Server. To learn which on-premises version you are using, see What platform/version am I using? When you add a user or group to a team or project, they're automatically granted access to those features supported by the default access level and those supported by the security group to which they are added. Most users can access most features by being assigned to the Basic access level and Contributors security group. For a simplified overview of the permissions assigned to the most common groups Readers, Contributors, and Project Administrators, see Default permissions. To add user accounts or groups to specific access levels, see Manage users and access. Make sure to set each user's access level based on what you've purchased for that user. To add user accounts or groups to specific access levels, see Change access levels. Make sure to set each user's access level based on what you've purchased for that user. Assign users or groups of users to one of the following access levels: Basic: Provides access to most features. Assign to users with a Visual Studio Professional subscription, an Azure DevOps Server CAL, and to users for whom you're paying for Basic access in an organization. Basic + Test Plans: Provides access to all features included in Basic, as well as Azure Test Plans. Assign to users with a Visual Studio Test Professional or MSDN Platforms subscription, and to users for whom you're paying for Basic + Test Plans access in an organization. Stakeholder: Can be assigned to unlimited users for free. Provides partial access to private projects and mostly full access to public projects. Assign to users with no license or subscriptions who need access to a limited set of features. For feature access details, see Stakeholder access quick reference. Visual Studio Subscriber: Assign to users who already have a Visual Studio subscription. The system automatically recognizes the user's subscription—Visual Studio Enterprise, Visual Studio Professional, Visual
- 467. TIP Studio Test Professional, or MSDN Platform—and enables any other features that are included in their subscription level. If you assign Basic or Stakeholder, they also receive their Visual Studio subscription benefits upon sign-in. As a best practice when adding new users, we recommend assigning the Visual Studio Subscriber level when appropriate (as opposed to Basic) to prevent being charged the Basic rate before the user signs in for the first time. Stakeholder: Provides partial access, can be assigned to unlimited users for free. Assign to users with no license or subscriptions who need access to a limited set of features. Basic: Provides access to most features. Assign to users with an Azure DevOps Server CAL, with a Visual Studio Professional subscription, and to users for whom you're paying for Basic access in an organization. Basic + Test Plans: Provides access for users who have a monthly Test Manager subscription, Visual Studio Test Professional, or MSDN Platforms subscription. VS Enterprise: Provides access to premium features. Assign to users with a subscription to Visual Studio Enterprise. Stakeholder: Provides partial access, can be assigned to unlimited users for free. Assign to users with no license or subscriptions who need access to a limited set of features. Basic: Provides access to most features. Assign to users with a CAL or with a Visual Studio Professional subscription. Advanced (legacy access level, deprecated in Azure DevOps Server 2019): Provides access to premium features. Only assign to users with a subscription to MSDN Platforms or Visual Studio Test Professional. VS Enterprise: Provides access to premium features. Assign to users with a subscription to Visual Studio Enterprise. The following table indicates those features available for each supported access level. Visual Studio Test Professional and MSDN Platform subscriptions grant access to the same features as Visual Studio Enterprise. Feature Stakeholder Basic & Visual Studio Professional Basic + Test Plans & Visual Studio Enterprise Feature Stakeholder Basic & Visual Studio Professional Basic + Test Plans & Visual Studio Enterprise Feature Stakeholder Basic &
- 468. Visual Studio Professional Advanced & Visual Studio Enterprise Administer organization Can configure resources when also added to a security group or role: team administrator, Project Administrator, or Project Collection Administrator. ✔ ️ ✔ ️ ✔ ️ Advanced backlog and sprint planning tools Includes full access to all backlog and sprint planning tools. ✔ ️ ✔ ️ Advanced home page Includes access to projects, work items, and pull requests defined across projects you work in. ✔ ️ ✔ ️ Advanced portfolio management Includes full access to define features and epics from a portfolio backlog or Kanban board. ✔ ️ ✔ ️ Agile boards Stakeholders have limited access to Kanban boards and Taskboards. Stakeholders can add work items and update status through drag-and-drop, but can't update fields displayed on cards (except for the work item State) and can't view or set capacity. ✔ ️ ✔ ️ ✔ ️ Agile boards Stakeholders have limited access to Kanban boards and Taskboards. Stakeholders can't add work items, drag- and-drop cards to update status, update fields displayed on cards, nor view or set capacity. ✔ ️ ✔ ️ ✔ ️ Agile Portfolio Management Includes limited access to portfolio backlogs and Kanban boards. Stakeholders can't change the backlog priority order, can't assign items to an iteration, use the mapping pane, or exercise forecasting.
- 469. ✔ ️ ✔ ️ ✔ ️ Artifacts Includes full access to all Azure Artifacts features, up to 2 GiB free storage. ✔ ️ ✔ ️ ✔ ️ Author Release Pipelines and Manage Releases Includes defining release pipelines, multi-stage continuous deployment (CD) pipelines, and using approvals and gates to control deployments; when the Free access to Pipelines Preview feature is enabled, Stakeholders gain access to all Azure Pipelines features. ✔ ️ ✔ ️ Basic backlog and sprint planning tools Includes limited access to add and modify items on backlogs and sprint backlogs and taskboards. Stakeholders can't assign items to an iteration, use the mapping pane, or forecasting. ✔ ️ ✔ ️ Build Includes full access to all features to manage continuous integration and continuous delivery of software. ✔ ️ ✔ ️ Chart Authoring Can create work tracking query charts. ✔ ️ ✔ ️ Chart Viewing Can only view work tracking query charts. Stakeholders can't view query charts from the Queries page, however can view them when added to a dashboard. ✔ ️ ✔ ️ Code Includes full access to all features to manage code using Git repositories or using Team Foundation Version Control (TFVC) Team Foundation Version Control (TFVC). ✔ ️ ✔ ️
- 470. Delivery Plans Includes full access to add and view Delivery plans. ✔ ️ ✔ ️ Delivery Plans Includes full access to add and view Delivery plans. ✔ ️ ✔ ️ Request and Manage Feedback Includes full access to request and manage feedback on working software. ✔ ️ ✔ ️ Standard Features Includes working across projects, View dashboards, View wikis, and Manage personal notifications. Stakeholders can't view Markdown README files defined for repositories and can only read wiki pages. ✔ ️ ✔ ️ ✔ ️ Test services in build and release Includes running unit tests with your builds, reviewing, and analyzing test results. ✔ ️ ✔ ️ Test Case Management Includes adding test plans and test suites, creating manual test cases, deleting test artifacts, and testing different configurations. ✔ ️ Test Execution and Test Analysis Includes running manual, tracking test status, and automated tests. ✔ ️ ✔ ️ Test summary access to Stakeholder license Includes requesting Stakeholder feedback using the Test & Feedback extension. ✔ ️ ✔ ️ ✔ ️ View My Work Items
- 471. Visual Studio subscription access VS Enterprise access Advanced access Programmatic mapping of access levels Access to add and modify work items, follow work items, view and create queries, and submit, view, and change feedback responses. Stakeholders can only assign existing tags to work items (can't add new tags) and can only save queries under My Queries (can't save under Shared Queries). ✔ ️ ✔ ️ ✔ ️ View Releases and Manage Approvals Includes viewing releases and approving releases; when the Free access to Pipelines Preview feature is enabled feature is enabled, Stakeholders gain access to all Azure Pipelines features. ✔ ️ ✔ ️ ✔ ️ Visual Studio subscribers are entitled to Visual Studio subscription features as a subscriber benefit. When you add those users, be sure to assign them the Visual Studio subscription access level. The system automatically recognizes their subscription and enables any other features that are included, based on their subscription level. Visual Studio Enterprise subscribers are entitled to VS Enterprise access as a subscriber benefit. When you add those users, be sure to assign them the VS Enterprise access level. With VS Enterprise access, users have access to any fee-based, Marketplace extension published by Microsoft Marketplace extension published by Microsoft that is included for active Visual Studio Enterprise subscribers. Users assigned Advanced access can manage test cases when you have purchased the Test Manager extension for Azure Test Plans and assigned to the user accounts to gain full access to Web-based test case management tools. Users assigned Advanced access have all the Basic features, plus web-based test case management tools. You can buy monthly access or add users who already have a Visual Studio Test Professional with MSDN or MSDN Platforms subscription. You can manage access levels programmatically using the az devops user add (Azure DevOps Services only) or the User Entitlement - Add REST API. The following table provides a mapping of the access level selected through the user interface and the AccountLicenseType , licensingSource , and msdnLicenseType parameters.
- 472. ACCESS LEVEL (USER INTERFACE) LICENSEDISPLAYNAME ACCOUNTLICENSETYPE LICENSINGSOURCE MSDNLICENSETYPE Basic express account none Basic + Test Plans advanced account none Visual Studio Subscriber none msdn eligible Stakeholder stakeholder account none Visual Studio Enterprise subscription none msdn enterprise NOTE ACCESS LEVEL (USER INTERFACE) LICENSEDISPLAYNAME ACCOUNTLICENSETYPE LICENSINGSOURCE MSDNLICENSETYPE Basic express account none Basic + Test Plans advanced account none Visual Studio Subscriber none msdn eligible Stakeholder stakeholder account none VS Enterprise none msdn enterprise ACCESS LEVEL (USER INTERFACE) LICENSEDISPLAYNAME ACCOUNTLICENSETYPE LICENSINGSOURCE MSDNLICENSETYPE Basic express account none Advanced advanced account none Stakeholder stakeholder account none VS Enterprise none msdn enterprise The earlyAdopter accountLicenseType is an internal value used solely by Microsoft. You can manage access levels programmatically using the User Entitlement - Add REST API. The following table provides a mapping of the access level selected through the user interface and the AccountLicenseType , licensingSource , and msdnLicenseType parameters. You can manage access levels programmatically using the User Entitlement - Add REST API. The following table provides a mapping of the access level selected through the user interface and the AccountLicenseType , licensingSource , and msdnLicenseType parameters.
- 473. What features are available to users who are added to two different access levels? Service account access Related articles If a user belongs to a group that has Basic access and another group that has VS Enterprise access, the user has access to all features available through VS Enterprise, which is a superset of Basic. Azure DevOps Server service accounts are added to the default access level. If you make Stakeholder the default access level, you must add the service accounts to Basic or Advanced/VS Enterprise access. Service accounts don't require a CAL or other purchase. Stakeholder access quick reference Free access to Pipelines Preview Manage users and access Get started as a Stakeholder Export a list of users and their access levels Default permissions and access Stakeholder access quick reference Change access levels Get started as a Stakeholder Export a list of users and their access levels Default permissions and access Compare features between plans
- 474. Azure DevOps Services status 6/9/2022 • 3 minutes to read • Edit Online Services within the product suite Service health matrix Service health indicators Azure DevOps Services We have a team of engineers around the world who look after the health of Azure DevOps 24 hours a day. Their primary goal is to ensure that our customers are always productive and successful with our service. From time to time, like any online service, our service experiences performance slowdowns and stability issues. In these cases, we aim to respond quickly to restore the service. It's our top priority to communicate the incident status and our next steps to mitigate the issue. We do so through the Azure DevOps Services status portal. If you're experiencing a problem with any of our Azure DevOps Services, you can check the service health to determine if we're already working on the issue. Many of the events we post are based on our Customer Impact Assessment (CIA). The CIA is modeled after our availability model that measures real customer experiences representing both reliability and performance. Azure DevOps is a product suite of service offerings. The geographic region indicates where an organization is hosted in the cloud. The data residency, sovereignty, compliance, and resilience requirements are honored within the geographical boundaries. In addition to the specific Azure DevOps Services, the matrix also displays two other categories: Core and Other. The Core category encompasses the set of features that are fundamental to all five services, such as authentication or the web portal. The Other category corresponds to features that complement the suite, such as extensions. For more information about pricing and acquisition, see the pricing and acquisition page. The service status portal provides a two-dimensional matrix view of active events mapped to a given service and geography. To help clarify which specific aspects of the service are affected, we communicate impact of each of these services by geographic region in the service matrix. The Azure DevOps Services status portal indicates the status of Azure DevOps Services according to the following indicators. These indicators reflect the severity of a service health event based on the number of customers affected by the issue. Typically, the highest severity events impact a large percentage of our customers and render some parts of the product unusable. Healthy: Indicates the service is broadly available. Degraded: Indicates a lower-severity event that affects the performance of a service feature, but doesn't impact broad service availability. Unhealthy: Indicates a high-severity event that affects the performance of a service and its broad availability. Advisory: Indicates that a service is under investigation to determine the performance and availability
- 475. Service status and event logs When and how to report availability issues RSS feed Use REST APIs to build automated solutions NOTE Related articles impact. You can access more information on active events from the Status history page. This page provides a view into current active events and past events. Eave event under investigation or previously investigate is logged in the form of an event log. Each log has other associated information such as the impacted service, geography, and event duration. Choose the provided hyperlink to view the event log, which provides detailed information on the event under investigation. You can also filter the logs to adjust the scope of your search into past events. In addition, you can use the REST API build automated alerting solutions to help you stay on top of events. If you're experiencing an issue with Azure DevOps and see a corresponding event that's communicated on the service health portal, we're already working to restore normal operations of the service. You don't need to do anything else to notify us. However, if you don't see your issue reported on the Azure DevOps Services health page, you can ask a question through the Azure DevOps Services virtual support agent. For issues not related to availability, refer to our Developer Community portal. You can use the RSS feed to subscribe and receive information in your feed reader. The Azure Resource health REST API can retrieve the current health status of each of the Azure DevOps Services. You can use it to build an automated solution to monitor the infrastructure incidents. Looking for Azure DevOps REST APIs? See the latest Azure DevOps REST API reference. For information about .NET client libraries, see .NET client libraries for Azure DevOps. Azure Service Health overview Blog post: How do you measure quality of a service?
- 476. Data protection overview 6/9/2022 • 21 minutes to read • Edit Online Our commitment Built on Azure Azure DevOps Services Azure DevOps Services is a cloud-hosted application for your development projects, from planning through deployment. Based on the on-premises capabilities, with additional cloud services, we manage your source code, work items, builds, and tests. Azure DevOps uses platform as a service (PaaS) infrastructure and many Azure services, including Azure SQL, to deliver a reliable, globally available service for your development projects. This article discusses the steps that Microsoft takes to help keep your projects safe, available, secure, and private. Also, it describes the role you play in keeping your projects safe and secure. This article is intended for organization administrators and IT professionals who manage their project assets daily. It will be most useful to individuals who are already familiar with Azure DevOps and want to know more about how Microsoft protects stored assets in Azure DevOps. Microsoft helps to ensure that your projects remain safe and secure, without exception. When stored in Azure DevOps, your projects benefit from multiple layers of security and governance technologies, operational practices, and compliance policies. We enforce data privacy and integrity both at rest and in transit. The threats you face boil down to four basic categories: data availability, service availability, service security, and data privacy. This article explores specific threats within each category, and explains what Azure DevOps does to address them. First, the article describes how data is stored and how Azure DevOps manages access to your data. Data protection requires active engagement of administrators and users, who must know what steps to take to protect your assets from unauthorized disclosure and tampering. Be explicit when you grant permissions to user access points, so only the right people are accessing data within Azure DevOps. Whatever your approach, you should consider all data potentially "at risk," no matter where it is or how it's being used. This is true for both data in the cloud and data stored in a private data center. It's important to classify your data, its sensitivity and risk, and the damage it might do if it becomes compromised. Also, categorize your data relative to an overall information security management policy. We host Azure DevOps entirely in Azure data centers. Azure DevOps uses many core Azure services, including
- 477. Data availability Data redundancy compute, storage, networking, Azure SQL, identity and access management, and Azure Service Bus. Azure DevOps uses Azure Storage as the primary repository for service metadata and customer data. Depending on the type of data and the storage and retrieval needs, Azure DevOps uses Azure Blob Storage (for binary large objects) and Azure SQL data storage. To understand the Azure DevOps Services approach to data protection, some background on these elements is important. Azure Blob Storage stores large chunks of unstructured data. All projects use the Azure Blob Storage service. Data includes potentially sensitive or private information, like the contents of source files and attachments for work items. For most projects, the majority of storage in use is this type of unstructured blob storage. For more information, see Azure Blob Storage. Azure SQL Database storage stores the structured and transactional aspects of your organization, including project metadata, the versioned source control history, and work item details. Database storage gives you fast access to the important elements of your project, and provides indexes into the blob storage to look up files and attachments. For more information, see Azure SQL Database. Administrators can manage access to resources by granting or restricting permissions on user identities or groups. Azure DevOps uses federated authentication of user identities via Azure Active Directory (Azure AD) and Microsoft accounts. During authentication, the user is routed to the authentication provider, where they provide their credentials. After the authentication provider has verified the user's credentials, Azure DevOps issues an authentication cookie to the user, which allows the user to remain authenticated against Azure DevOps. In this way, the user's credential information is never shared directly with Azure DevOps. For each Azure DevOps resource that the user attempts to access, permissions are validated based on the user's explicit permissions, as well as permissions inherited through group membership. Administrators can use access controls to protect access to the organization, project collections, team projects, and team-scoped data and functionality. Administrators can also protect more specific assets like version control folders and work item area paths. Azure DevOps uses many Azure Storage features to ensure data availability if there's a hardware failure, service disruption, or region disaster. Also, the Azure DevOps team follows procedures to protect data from accidental or malicious deletion. To protect data during hardware or service failures, Azure Storage geo-replicates customer data between two regions in the same geography. For example, Azure can geo-replicate data between North and West Europe or between North and South United States. For Azure Blob Storage, customer data gets replicated three times within a single region, and is replicated asynchronously to a second region in the same geography. As such, Azure always maintains the equivalent of six copies of your data. This enables you to fail over to a separate region if there's a major outage or disaster, while also having local redundancy for hardware failures within a region. For Azure SQL Database storage, daily backups are maintained offsite if there's a regional disaster.
- 478. NOTE Mistakes happen Practice is critical Service availability DDoS protections Live site response Regarding data redundancy and failover: There's an inherent delta, measured in minutes, when Microsoft replicates your data between the primary and secondary region. Failover to the secondary region is a decision that Microsoft must make centrally, as it affects all customers on the affected scale unit. Except in extreme circumstances, Microsoft opts to not fail over so that customer data isn't lost. Azure DevOps offers a 99.9 percent uptime SLA guarantee, and refunds a portion of the monthly charges if that SLA is missed in a specific month. Because there is only one region in Brazil, customer data in Brazil is replicated to the South Central US region for disaster recovery purposes. To protect against accidental deletion of data, Microsoft also takes point-in-time backups of both the blobs in Azure Blob Storage, and the databases in Azure SQL Database. There's a separate copy of all blobs, and changes are appended to each storage account. Because this data is immutable, you don't need to rewrite any existing storage as part of the backup procedures. Backups are a standard part of Azure SQL Database, and Azure DevOps makes use of this. We maintain 28 days' worth of your data. In both cases, these backups are also replicated in a paired region, helping to ensure that you recover from a regional outage. A further protection is that Microsoft can recover entire organizations for up to 28 days after deletion. This is because we perform a "soft delete" for organization deletion operations. Having multiple, redundant backups of your data is good but without practice, restoring can be unpredictable. It's been said that "backups never fail, the restores do." While technically incorrect, the sentiment is right. Microsoft regularly practices restoring various datasets from backup. Geo-redundant storage from Azure is tested regularly. Also, from time to time, we restore from backups to recover from human error, such as when a customer has inadvertently deleted a project in Azure DevOps. There are many combinations of disaster and data corruption scenarios, which we continue to plan and run new tests for regularly. Azure DevOps offers distributed denial-of-service (DDoS) protections and live site response to help ensure that you have access to your organization and associated assets. In some cases, a malicious DDoS attack can affect service availability. Azure has a DDoS defense system that helps prevent attacks against our service. It uses standard detection and mitigation techniques such as SYN cookies, rate limiting, and connection limits. The system is designed to withstand attacks not only from the outside but also from within Azure. For application-specific attacks that can penetrate the Azure defense systems, Azure DevOps establishes application and organization level quotas and throttling. This helps prevent any overuse of key service resources during an attack or accidental misuse of resources. In rare circumstances, you might require a live site response to a problem with service availability. We have an operations team available 24x7, to rapidly identify the issue and to engage the necessary development team resources. Those resources then address the problem. They also aim to update the service status page within minutes of detecting an issue that affects the service. After the team has addressed an issue, they identify the
- 479. Service security Secure by design root cause of the issue and track the necessary changes to prevent similar issues in the future. Azure DevOps live site management processes focus on your experience and the health of your service. These processes minimize the time to detect, respond to, and mitigate problems. All engineering disciplines are involved and responsible, so there are continual improvements evolving out of direct experience. This means that monitoring, diagnostics, resiliency, and quality assurance processes improve over time. Live site management in Azure DevOps has three distinct tracks: telemetry, incident management, and live site review. Here's what these tracks entail: The operations team also monitors the availability metrics for individual organizations. These metrics provide insights into specific conditions that might affect only some of our customers. Investigations into this data can often result in targeted improvements to address customer-specific issues. In some cases, Microsoft might even contact you directly to understand your experience and work with you to improve the service. Microsoft publishes a service-level agreement (SLA) and provides a financial guarantee to ensure that we meet this agreement each month. For more information, see SLA for Azure DevOps. Sometimes partner teams or dependencies have incidents that affect Azure DevOps. All partner teams follow similar approaches to identifying, resolving, and learning from these service outages. Service security requires constant vigilance, from proper design and coding techniques to operational factors. Microsoft actively invests in the prevention of security holes and in breach detection. If there's a breach, Microsoft uses security response plans to minimize data leakage, loss, or corruption. For more information, see About security, authentication, and authorization. Azure DevOps is designed to be secure. Azure DevOps uses the Microsoft Security Development Lifecycle at the core of its development process. The Microsoft Operational Security Assurance program guides its cloud operation procedures. The following methodologies specify the following requirements: Threat modeling during service design.
- 480. Credential security Reporting security issues IMPORTANT Bounty program Restricting access Following design and code best practices. Verifying security with standard tooling and testing. Limiting access to operational and customer data. Gating rollout of new features through a rigid approval process. The Azure DevOps team has annual training requirements for all engineers and operations personnel, and sponsors informal "brown bag" meetings hosted by Microsoft engineers. After they've solved an issue raised in a brown bag meeting, they share what they learned with the rest of the team. A cloud service is only as secure as the host platform. Azure DevOps uses PaaS for much of its infrastructure. PaaS automatically provides regular updates for known security vulnerabilities. VMs hosted in Azure use infrastructure as a service (IaaS), such as for a hosted build service. Such images receive regular updates to include the latest security patches available from Windows Update. The same update rigor applies for on- premises machines, including those used for deployment, monitoring, and reporting. The Azure DevOps team conducts regular, security-focused penetration testing of Azure DevOps. Using the same techniques and mechanisms as malicious attackers, penetration testing tries to exploit the live production services and infrastructure of Azure DevOps. The goal is to identify real-world vulnerabilities, configurations, errors, or other security gaps in a controlled process. The team reviews the results to identify other areas of improvement and to increase the quality of the preventative systems and training. You can review the results of recent Azure DevOps penetration tests on the Service Trust Portal. Your credentials in Azure DevOps are stored using industry best practices. Learn more about credential storage. If during your penetration testing you believe you've discovered a potential security flaw related to the Azure DevOps service, report it to Microsoft within 24 hours. For more information, see Report a computer security vulnerability. Although notifying Microsoft of penetration testing activities is no longer required, you must still comply with the Microsoft Cloud Unified Penetration Testing Rules of Engagement. Azure DevOps participates in the Microsoft Online Services Bounty Program. This program rewards security researchers who report issues to us, and encourages more people to help keep Azure DevOps secure. For more information, see the Azure DevOps Bounty Program. Microsoft maintains strict control over who gets access to our production environment and customer data. Access gets granted at the level of least privilege that's required and only after proper justifications get provided and verified. If a team member needs access to resolve an urgent issue or deploy a configuration change, they must apply for "just-in-time" access to the production service. Access is revoked as soon as the situation is resolved. Access requests and approvals get tracked and monitored in a separate system. All access to the system correlates against these approvals and if we detect unapproved access, the operations team gets alerted to investigate. We use two-factor authentication for all remote system access. So, if the username and password for one of our developers or operation staff got stolen, the data remains protected. This means additional authentication checks via smart card or a phone call to a pre-approved number must occur before any remote access to the
- 481. Intrusion protection and response Data privacy General Data Protection Regulation (GDPR) Data residency and sovereignty service is permitted. In addition, Microsoft uses secrets to manage and maintain the service, such as RDP passwords, SSL certificates, and encryption keys. These are all managed, stored, and transmitted securely through the Azure portal. Any access to these secrets requires specific permission, which is logged and recorded in a secure manner. All secrets are rotated on a regular cadence, and can be rotated on-demand if there's a security event. The Azure DevOps operations team uses hardened administrator workstations to manage the service. These machines run a minimal number of applications and operate in a logically segmented environment. Operations team members must provide specific credentials with two-factor authentication to access the workstations. All access is monitored and securely logged. To isolate the service from outside tampering, we don't permit applications such as Outlook and Office, as they're often targets of spear-phishing and other types of attacks. We encrypt data via HTTPS and SSL to ensure it isn't intercepted or modified while in transit between you and Azure DevOps. Also, data we store on your behalf in Azure DevOps gets encrypted as follows: Data stored in Azure SQL databases gets encrypted using Transparent Data Encryption (TDE). TDE protects against the threat of malicious activity by doing real-time encryption of the database, associated backups, and transaction log files at rest. Azure Blob Storage connections get encrypted to protect your data in transit. To protect data at rest stored in Azure Blob Storage, Azure DevOps uses Azure Storage Service Encryption (SSE). The Azure infrastructure helps the Azure DevOps team to log and monitor key aspects of the service. This helps ensure that activities within the service are legitimate, and detects breaches or attempted breaches. In addition, all deployment and administrator activities are securely logged, as is operator access to production storage. Real-time alerts are raised because the log information is automatically analyzed to uncover potentially malicious or unauthorized behavior. Where a possible intrusion or high priority security vulnerability gets identified, the team has a clear response plan. This plan outlines responsible parties, steps required to secure customer data, and how to engage with security experts at Microsoft. The team also notifies any organization owners if data was disclosed or corrupted, so that they can take appropriate steps to remedy the situation. Finally, to help combat emerging threats, Azure DevOps employs an "Assume Breach" strategy. A highly specialized group of security experts within Microsoft, known as the Red Team, assumes the role of sophisticated adversaries. This team tests breach detection and response, to accurately measure readiness and the impacts of real-world attacks. This strategy strengthens threat detection, response, and defense of the service. It also allows the team to validate and improve the effectiveness of the entire security program. You should have confidence that your data is being handled appropriately and for legitimate uses. Part of that assurance involves appropriately restricting usage so that your data is used only for legitimate reasons. The General Data Protection Regulation (GDPR) is the biggest change in data protection laws in Europe since the 1995 introduction of the European Union (EU) Data Protection Directive 95/46/EC. For more information about the GDPR regulation, see the overview page in the Microsoft Trust Center. Azure DevOps is available in the following eight geographies across the world: United States, Canada, Europe, United Kingdom, India, Australia, Asia Pacific, and Brazil. By default, your organization is assigned to your closest
- 482. NOTE Law enforcement access Microsoft access Microsoft promotional use Building confidence geography, but you do have the option to choose a different geography. If you change your mind later, it's possible to migrate your organization to a different geography, with the assistance of Microsoft support. Azure DevOps doesn't move or replicate customer data outside of the chosen geography. Instead, your data is geo-replicated to a second region within the same geography. The only exception is Brazil, which replicates data to the South Central US geography for disaster recovery purposes. For builds and releases running on Microsoft-provided macOS agents, your data will be transferred to a GitHub data center in the US. To learn more, see Azure DevOps data location. In some cases, third parties such as law enforcement entities might approach Microsoft to obtain access to customer data stored within Azure DevOps. We attempt to redirect the requests to the organization owner for resolution. When compelled by court order to disclose customer data to a third party, Microsoft makes a reasonable effort to notify the organization owner in advance, unless we’re legally prohibited from doing so. Some customers require their data storage in a particular geographic location to ensure a specific legal jurisdiction for any law enforcement activities. All customer data, such as source code, work items, test results, and geo-redundant mirrors and offsite backups, get maintained within one of the previously mentioned geographies. From time to time, Microsoft employees need to obtain access to customer data stored within Azure DevOps. As a precaution, all employees who have or might ever have access to customer data must pass a background check, which verifies previous employment and criminal convictions. We permit access to the production systems only when there's a live site incident or other approved maintenance activity, which gets logged and monitored. Because not all data within our system gets treated the same, we classify data to distinguish between the following data types: Customer data - what you upload to Azure DevOps. Organization data - information used when you sign up for or administer your organization. Microsoft data - information required for or collected through the operation of the service. Based on the classification, we control usage scenarios, geo-location requirements, access restrictions, and retention requirements. Microsoft occasionally wants to contact customers to let them know about additional features and services that might be useful. Because not all customers want to be contacted about these offers, you can opt in and opt out of marketing email communications. Microsoft never uses customer data to target specific offers for specific users or organizations. Instead, we use organization data and aggregate usage statistics at the organization level to determine groups that should receive specific offers. You can be confident in other efforts Microsoft makes on behalf of Azure DevOps. These efforts include internal adoption policies at Microsoft, the level of transparency provided into the state of our service, and progress
- 483. Internal adoption Compliance certifications Steps you can take Classify your data Adopt Azure Active Directory towards receiving certification of our information security management systems. Teams across Microsoft are adopting Azure DevOps internally. The Azure DevOps team moved into an organization in 2014 and uses it extensively. More broadly, we have established guidelines to enable the adoption plans for other teams. Obviously, large teams move more gradually than smaller ones, given their investments in existing DevOps systems. For teams able to move quickly, we have established a project classification approach. It assesses risk tolerance, based on project characteristics, to determine if the project is appropriate for Azure DevOps. For larger teams, the adoption typically occurs in phases, with more planning. Additional requirements for internal projects include associating the organization with Azure AD to ensure proper user identity life cycle and password complexity. For more sensitive projects, two-factor authentication is also required. Some of you want to understand third-party evaluation of our data security procedures. Azure DevOps has achieved the following certifications: ISO 27001:2013 ISO 27018:2019 HIPAA (Health Insurance Portability and Accountability Act) BAA (Business Associate Agreement) EU Model Clauses SOC 1 Type 2 SOC 2 Type 2 Germany C5 The SOC audit for Azure DevOps covers controls for data security, availability, processing integrity, and confidentiality. The SOC reports for Azure DevOps are available through the Microsoft Service Trust Portal. Proper data protection requires your active engagement, as well as that of your administrators and users. Your project data stored within Azure DevOps is only as secure as the end-user access points. Match the level of permission strictness and granularity for those organizations with your project's sensitivity level. The first step is to classify your data. Classify data based on sensitivity and risk horizon, and the damage that might occur if it gets compromised. Many enterprises have existing classification methods that can be reused when projects move to Azure DevOps. For more information, you can download the "Data classification for cloud readiness" document from Microsoft Trustworthy Computing. Use Azure Active Directory (Azure AD) to manage your organization's access to Azure DevOps. Azure AD provides another way to improve the security of your users' credentials. Azure AD allows your IT department to manage its end-user access policy, password complexity, password refreshes, and expiration if the user leaves your organization. Through Active Directory federation, you can directly link Azure AD to your organization's central directory, so you have only one location to manage these details for your enterprise. The following table compares Microsoft account and Azure AD characteristics relative to Azure DevOps access:
- 484. PROPERTIES MICROSOFT ACCOUNT AZURE AD Identity creator User Organization Single username / password for all work assets No Yes Password lifetime & complexity control User Organization Azure DevOps membership limits Any Microsoft account (MSA) Organization's directory Traceable identity No Yes Organization & IP ownership Unclear Organization Two-factor authentication enrollment User Organization Device-based conditional access No Organization Require two-factor authentication Use BitLocker Limit use of alternate authentication credentials Secure access to your organization Learn more about configuring this support for your organization. You might want to restrict access to your organization by requiring more than one factor to sign in. You can require multiple factors with Azure AD. For example, you can require phone authentication, in addition to a username and password, for all authentication requests. For sensitive projects, you can use BitLocker on your Windows laptop or desktop computer. BitLocker encrypts the entire drive on which Windows and your data reside. When BitLocker is enabled, it automatically encrypts any file you save on that drive. If your laptop or desktop machine falls into the wrong hands, BitLocker prevents unauthorized access of local copies of data from your projects. The default authentication mechanism for Git-related tooling is alternate authentication (sometimes referred to as basic authentication). This mechanism allows the end user to set up an alternate username and password for use during Git command-line operations. This username and password combination can also be used to access any other data for which that user has permissions. By its nature, alternate authentication credentials are less secure than the default federated authentication. You can still make choices for increased security. All communication gets sent over HTTPS, and there are password complexity requirements. Your organization should continue to evaluate whether additional policies are required to meet your project security requirements. You can disable alternate authentication credentials altogether if you decide that it doesn't meet your organization's security requirements. For more information, see Change application connection & security policies for your organization. Azure AD provides the ability for administrators to control access to Azure resources and applications such as Azure DevOps. With conditional access control in place, Azure AD checks for the specific conditions you set for a user to access an application. After access requirements are met, the user is authenticated and can access the application. Azure DevOps supports enforcing certain types of conditional access policies (for example, IP fencing) for custom Azure DevOps authentication mechanisms. These mechanisms include personal access tokens, alternate authentication, OAuth, and SSH keys. If your users are accessing Azure DevOps through a third-party client, only
- 485. Additional resources IP-based policies (IPv4 based only) are honored. Azure DevOps home page Azure DevOps data location Microsoft privacy statement Azure DevOps support Features and services included with Azure DevOps Azure trust center Microsoft Security Development Lifecycle
- 486. Data locations for Azure DevOps 6/9/2022 • 2 minutes to read • Edit Online Data locations Customer data Profile data Allow list data for tenant policies Azure DevOps Services You can choose the location for your data during initial sign-up and creation of your organization. Azure DevOps operates in the following geographical locations, or “geos”. Azure DevOps data is available in the following eight geographies across the world: Australia Brazil Canada Asia Pacific Europe (EU) India United Kingdom United States (US) We default your organization to your closest geography. However, you can choose a different geography. If you change your mind afterward, you can migrate your organization to a different geography. For more information, see Data residency in Azure. Except as noted, Azure DevOps maintains all customer data within your selected geography. Customer data includes the following data types: source code work items test results geo-redundant mirrors and offsite backups Azure DevOps works with and uses many Microsoft Azure services. For more information and details on customer data retention by location, see Data residency in Azure. Azure DevOps stores information that's global in nature, such as user identities and profile information as follows: EU-based users: profile data is in EU data center US-based users: profile data is in US data center Users from all other countries and regions: profile data is in US data center We recommend using groups with your tenant policy allow list(s). If you use a named user, be aware that a reference to the named user's identity will reside in the United States, Europe (EU), and Southeast Asia
- 487. Transferring your data NOTE NOTE Related articles (Singapore). We don't transfer customer data outside of your selected geography. However, we will transfer your data if we need to do any of the following actions: provide customer support troubleshoot the service comply with legal requirements If needed, you can transfer your data using preview, beta, or other pre-release services. These services typically store your data in the United States, but may store it globally. For builds and releases running on Microsoft-provided macOS agents, your data will be transferred to a GitHub data center in the US. This data center location is owned and managed by GitHub with compliance certifications, such as SOC 1 & 2 Type II reports available here. Microsoft doesn't control or limit the geographies from which you or your users may access your data. Because there's only one region in Brazil, customer data is replicated to south-central United States for disaster recovery and load balancing purposes. For more information, see Data residency in Azure. Get started with Azure DevOps Data protection overview
- 488. How we store your credentials for Azure DevOps Services 6/9/2022 • 2 minutes to read • Edit Online IMPORTANT Credential security Personal access tokens (PATs) Secure shell (SSH) keys OAuth credentials (JWTs) Azure DevOps Services Azure DevOps no longer supports Alternate Credentials authentication since the beginning of March 2, 2020. If you're still using Alternate Credentials, we strongly encourage you to switch to a more secure authentication method (for example, personal access tokens). Learn more. Microsoft is committed to ensuring that your projects remain safe and secure, without exception. In Azure DevOps, your projects benefit from multiple layers of security and governance technologies, operational practices, and compliance policies. We enforce data privacy and integrity both at rest and in transit. In addition, we adhere to the following practices with respect to the credentials or secrets that Azure DevOps stores. To learn more about how to choose the right authentication mechanism, see Guidance for authentication. We store a hash of the PAT Raw PAT is generated in-memory on the server side as 32 bytes randomly generated through RNGCryptoServiceProvider then shared with the caller as a base-32-encoded string. This value is NOT stored PAT hash is generated in-memory on the server side as an HMACSHA256Hash of the raw PAT using a 64- byte symmetric signing key stored in our key vault Hash is stored in our database We store a hash of the enclosing organization ID and the SSH public key Raw public key is provided directly by the caller over SSL SSH hash is generated in-memory on the server side as an HMACSHA256Hash of the organization ID and raw public key using a 64-byte symmetric signing key stored in our key vault Hash is stored in our database These are issued as fully self-describing JSON web tokens (JWTs) and are NOT stored in our service The claims in JWTs issued and presented to our service are validated using a certificate stored in our key vault
- 489. Launch Visual Studio via Azure DevOps Services 6/9/2022 • 2 minutes to read • Edit Online How do I set up Visual Studio 2015 for Azure DevOps Services when I sign in? Azure DevOps Services When you first open Visual Studio 2015, you can sign in and connect to Azure DevOps Services. If you're already signed in to Visual Studio or using Visual Studio 2017, connect to Azure DevOps Services. Once you're connected, you can store or share code in free, unlimited, private, cloud-based Git repositories or Team Foundation Version Control (TFVC). Organize and manage your work with Agile tools for DevOps, continuous integration, and continuous delivery. Your team can build often, test early, and ship faster. To set up Visual Studio without Azure DevOps Services, learn how to get started. To host your own server, learn how to install and set up Azure DevOps Server. Azure DevOps Services is free for up to five users with access to Basic features and for unlimited Visual Studio subscribers and Stakeholders who can access limited features. Learn what else you get with Azure DevOps Services. If you want, you can also use Azure DevOps Services with any IDE or code editor, like the following examples: Eclipse, Android Studio, or IntelliJ Xcode (see Git or TFVC) Visual Studio Code 1. Download and install Visual Studio, if you don't have the version you want already. Which versions can I use with Azure DevOps Services? If you have a Visual Studio subscription that includes the Visual Studio IDE, get the version that's available with your subscription. 2. Start Visual Studio, and then sign in to create your profile. This profile saves your settings and roams with you when you sign in to Visual Studio on any computer. Why else should I sign in? If you're a Visual Studio subscriber, use the sign in address for your subscription.
- 490. Can't sign in? 3. Enter your sign in address, and then enter your password. 4. Add your Visual Studio profile details. You only need to add these details once. 5. Give your organization a name, and confirm its location. How can I create an organization later or change its location? 6. Create your first project to store your code, work items, backlog, builds, tests, and other assets. Name your project, select a process to organize your work, and choose the version control to manage your code.
- 491. Next steps Not sure which to choose? Learn which process and version control (Git or TFVC) work best for you. 7. If you're a new Visual Studio user, you can change your settings here, or change them later in Visual Studio options. These changes are saved with your profile, and your settings roam with you wherever you sign in. 8. To view your new organization, sign in to https://dev.azure.com/{yourorganization} . Add users to your organization
- 492. Related articles Add code to Git or TFVC. Create your backlog to organize your work, manage your process, or customize your process.
- 494. About projects and scaling your organization 6/9/2022 • 12 minutes to read • Edit Online How do you manage work across the enterprise? Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 A project provides a repository for source code and a place for users to plan, track progress, and collaborate on building software solutions. A project represents a fundamental container where data is stored when added to Azure DevOps. When you create your project, a team of the same name is automatically created. This is sufficient for small teams. However, for enterprise-level organizations, it may be necessary to scale up, to create more teams and projects. These additions can be created within the single account or collection. For more information, see Plan your organizational structure. Single project and team defined within an organization or collection Multiple projects and teams defined within an organization or collection The collection-project-team structure provides teams a high level of autonomy to configure their tools in ways that work for them. It also supports administrative tasks to occur at the appropriate level. As your organization grows, your tools can grow to support a culture of team autonomy and organizational alignment. How do you scale your DevOps and Agile tools to support your growing enterprise? When you connect to Azure DevOps, you connect to an organization or project collection. Within that container, one or more projects may be defined. At least one project must be created to use the system. You can scale your organization in the following ways: To support different business units, you can add projects Within a project, you can add teams Add repositories and branches
- 495. How to view projects To support continuous integration and deployment, you can add agents, agent pools, and deployment pools To manage a large number of users, you can manage access through Azure Active Directory You can scale your on-premises Azure DevOps deployment in the following ways: To increase performance, you can add server instances To support different business units, you can add project collections and projects Within a project, you can add teams Add repositories and branches To support continuous integration and deployment, you can add agents, agent pools, and deployment pools To manage a large number of users, you can manage access through Active Directory Azure DevOps Services and Azure DevOps Server are enterprise-ready platforms. These platforms support teams of any size, from tens to thousands. Azure DevOps Services, our cloud service, provides a scalable, reliable, and globally available hosted service. It's backed by a 99.9% SLA, monitored by our 24x7 operations team, and available in local data centers around the world. You can view the projects defined for your organization by opening the Projects page. 1. Select Azure DevOps to open Projects. 2. Choose a project from the list of projects. To create or list projects, see Create a project 1. Select Azure DevOps to open Projects. 2. From there, you can choose a project from the set of projects listed.
- 496. Limit user visibility for projects using the Project-scoped users group IMPORTANT Limit access to Organization settings NOTE By default, users added to an organization can view all organization and project information and settings. The Limit user visibility and collaboration to specific projects preview feature for the organization limits user access in two ways: Restricting views that display list of users, list of projects, billing details, usage data, and more that is accessed through Organization settings. Limiting the set of users or groups that appear through people-picker search selections and the ability to @mention users. The limited visibility features described in this section apply only to interactions through the web portal. With the REST APIs or azure devops CLI commands, project members can access the restricted data. Guest users who are members in the limited group with default access in Azure AD, can't search for users with the people picker. When the preview feature's turned off or when guest users aren't members of the limited group, guest users can search all Azure AD users, as expected. To restrict select users, such as Stakeholders, Azure Active Directory guest users, or members of a particular security group, you can enable the Limit user visibility and collaboration to specific projects preview feature for the organization. Once that is enabled, any user or group added to the Project-scoped users group, are restricted from accessing the Organization settings pages, except for Overview and Projects; and are restricted to accessing only those projects to which they've been added to. To enable this feature, see Manage or enable features. All security groups are organization-level entities, even those groups that only have permissions to a specific project. From the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover the names of all groups in an organization using the azure devops CLI tool or our REST APIs. To learn more, see Add and manage security groups.
- 497. NOTE NOTE Limit visibility within people pickers WARNING Historical data remains visible All security groups are collection-level entities, even those groups that only have permissions to a specific project. From the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover the names of all groups in an organization using the azure devops CLI tool or our REST APIs. To learn more, see Add and manage security groups. All security groups are collection-level entities, even those groups that only have permissions to a specific project. From the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover the names of all groups in an organization using the REST APIs. To learn more, see Add and manage security groups. Organizations that manage users and groups using Azure Active Directory (Azure AD) can use people pickers, which support searching all users and groups added to Azure AD, not just those users and groups added to your project. People pickers support the following Azure DevOps functions: Selection of a user identity from a work tracking identity field such as Assigned To Selection of a user or group using @mention in a work item discussion or rich-text field, a pull request discussion, commit comments, or changeset or shelveset comments Selection of a user or group using @mention from a wiki page As shown in the following image, you start entering a user in the people picker box until you find a match to the user name or security group. When the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization, project-scoped users are unable to search for users who were added to the organization through Azure Active Directory group membership, rather than through an explicit user invitation. This is an unexpected behavior and a resolution is being worked on. To self-resolve this issue, disable the Limit user visibility and collaboration to specific projects preview feature for the organization. Users and groups who are added to the Project-scoped users group can only see and select users and groups in the project they're connected to from a people picker. To scope people pickers for all project members, see Manage your organization, Limit identity search and selection. Identities that have been added to a comment, discussion, or assignment continue to be visible to all project members. For example, work items that were assigned to a user who has since left a project, the user’s name on that work item remains visible to everyone in the project, even to users with the new restriction. The same is
- 498. When to add another project Reasons to add another project Private and public projects Structure your project true for @mentions in PRs, comments, discussions, and more. In general, we recommend that you use a single project to support your organization or enterprise. A single project minimizes the maintenance of administrative tasks and supports the most optimized / full-flexibility cross-link object experience. Even if you have many teams working on hundreds of different applications and software projects, you can most easily manage them within a single project. A project serves to isolate data stored within it. You can't easily move data from one project to another. When you move data from one project to another, you typically lose the history associated with that data. For more information about when to add another project, see How many projects do you need?. You may want to add another project in following instances: To prohibit or manage access to the information contained within a project to select groups To support custom work tracking processes for specific business units within your organization To support entirely separate business units that have their own administrative policies and administrators To support testing customization activities or adding extensions before rolling out changes to the working project To support an Open Source Software (OSS) project You may want to add another project in following instances: To prohibit or manage access to the information contained within a project To support custom work tracking processes for specific business units within your organization To support entirely separate business units that have their own administrative policies and administrators To support testing customization activities or adding extensions before rolling out changes to the working project You can add public and private projects to your organization. You can also change the visibility of a project from private to public. Private projects require that you add and manage user access. Users must sign in to gain access to a project, even if it's read-only access. All users added to a project have access to the project and organization information. For details, see Resources granted to project members. A public project doesn't require users to sign in to gain read-only access to many of the services. Public projects provide support to share code with others and to support continuous integration/continuous deployment (CI/CD) of open-source software. To learn more about public projects, see What is a public project?. When you add a project, look at using the following elements to structure it to support your business needs: Create a Git repository for each subproject or application, or create root folders within a TFVC repository for each subproject. If you're using TFVC and heading toward a combined project model, create root folders for different teams and projects, just as you would create separate repos in Git. Folders can be secured as needed and workspace mappings can control what segments of the repo you're actively using. Define area paths to support different subprojects, products, features, or teams.
- 499. Customizing and configuring projects When to add a team, scaling Agile tools across the enterprise Define iteration paths (also known as sprints) that can be shared across teams. Add a team for each product team that develops a set of features for a product. Each team you create automatically creates a security group for that team, which you can use to manage permissions for a team. See also, Portfolio management. Grant or restrict access to select features and functions using custom security groups. Create query folders to organize queries for teams or product areas into folders. Define or modify notifications set at the project level. You can configure and customize most services and applications to support your business needs or the way your teams work. Within each project, you can do the following tasks. For a comprehensive view of what resources can be configured, see About team, project, and organizational-level settings. Dashboards: Each team can configure their set of dashboards to share information and monitor their progress. Source control: For each Git repository, you can apply branch policies and define branch permissions. For TFVC repositories, you can set check-in policies. Work tracking: You can add fields, change the workflow, add custom rules, and add custom pages to the work item form of most work item types. You can also add custom work item types. For details, see Customize an inheritance process. Azure Pipelines: You can fully customize your build and release pipelines, define build steps, release environments, and deployment schedule. For details, see Build and Release. Azure Test Plans: You can define and configure test plans, test suites, test cases, and test environments. You can also add test steps within your build pipelines. For details, see Exploratory & Manual Testing and continuous testing for your builds. Dashboards: Each team can configure their set of dashboards to share information and monitor their progress. Source control: For each Git repository, you can apply branch policies and define branch permissions. For TFVC repositories, you can set check-in policies. Work tracking: You can add fields, change the workflow, add custom rules, and add custom pages to the work item form of most work item types. You can also add custom work item types. For details, see Customize the On-premises XML process model. Build and Release: You can fully customize your build and release pipelines, define build steps, release environments, and deployment schedule. For details, see Build and Release. Test: You can define and configure test plans, test suites, test cases, and test environments. You can also add test steps within your build pipelines. For details, see Exploratory & Manual Testing and continuous testing for your builds. As your organization grows, add teams to provide them the Agile tools that each team can configure to meet their workflow. To learn more, see the following articles. Scale Agile to large teams About teams and Agile tools Manage a portfolio of backlogs and gain insight into each team's progress and the progress of all programs. Use Delivery plans to review the schedule of stories or features your teams plan to deliver. Delivery plans show the scheduled work items by sprint (iteration path) of selected teams against a calendar view. Incrementally adopt practices that scale to create greater rhythm and flow within your organization, engage
- 500. Clients that support connection to a project Q & A Q: Can I move or transfer a project to another organization or collection? Q: What programmatic tools support projects? Related articles customers, improve project visibility, and develop a productive workforce. Structure projects to gain visibility across teams or to support epics, release trains, and multiple backlogs to support the Scaled Agile Framework. To review stories and short videos on how Microsoft transitioned from waterfall to Agile, see Scaling Agile Across the Enterprise. In addition to connecting through a web browser, you can connect to a project from the following clients: Visual Studio (Professional, Enterprise, Test Professional) Visual Studio Code Visual Studio Community Eclipse: Team Explorer Everywhere Office Excel Azure Test Plans (formerly Test Manager) Microsoft Feedback Client Visual Studio (Professional, Enterprise, Test Professional) Visual Studio Code Visual Studio Community Eclipse: Team Explorer Everywhere Office Excel Azure Test Plans (formerly Test Manager) Microsoft Feedback Client See also, Compatibility with Azure DevOps Server versions. A: Not without losing data. You can't move a project from one collection/organization to another collection/organization without losing data. You can manually copy resources and leave some behind, or use a third-party tool, such as OpsHub Visual Studio Migration Utility, that copies data using the REST APIs. A. See Projects REST API. Also, you can use the az devops project commands. Get started as an administrator Web portal navigation What do I get with a project? Understand differences between Azure DevOps