Azure DevOps and Visual Studio Integration

Azure DevOps becomes significantly more powerful when you integrate it directly into your development environment. Instead of constantly switching between browser tabs and your editor, you can manage work items, create pull requests, monitor pipelines, and collaborate with teammates without ever leaving your IDE. This article walks through every integration point between Azure DevOps and both Visual Studio and VS Code, with practical configuration examples you can apply to your team immediately.

Prerequisites

Before you start, make sure you have the following in place:

• Visual Studio 2022 (Community, Professional, or Enterprise) or Visual Studio Code 1.70+
• An Azure DevOps organization with at least one project configured
• Git installed locally (version 2.30+)
• A Personal Access Token (PAT) from Azure DevOps with appropriate scopes (Code, Work Items, Build)
• Node.js 18+ installed if you plan to work with pipeline tooling locally
• Basic familiarity with Git workflows (branching, committing, pushing)

To generate a PAT, navigate to your Azure DevOps organization, click the user icon in the top right, select Personal access tokens, and create a new token. Give it a descriptive name like "VS Code Integration" and select the scopes you need. Copy it immediately because you will not be able to see it again.

Team Explorer in Visual Studio

Visual Studio has shipped with built-in Azure DevOps integration for years through Team Explorer. Starting with Visual Studio 2019, Microsoft began migrating toward the Git Changes window, but Team Explorer remains the bridge to Azure DevOps services beyond just source control.

Connecting to Your Organization

Open Visual Studio and go to View > Team Explorer. Click Manage Connections (the green plug icon), then select Connect to a Project. Sign in with your Azure DevOps credentials or Microsoft account. Once authenticated, you will see all organizations and projects you have access to.

After connecting, Team Explorer gives you direct access to:

• Work Items — Query, create, and edit work items without opening a browser
• Builds — View build definitions, queue new builds, and check build results
• Pull Requests — See active PRs, review code, and approve or reject changes
• Git Repositories — Clone, branch, commit, and sync with Azure Repos

Work Item Queries from Team Explorer

You can run saved work item queries directly in Team Explorer. Navigate to Work Items > Queries and you will see your personal queries alongside shared team queries. Double-clicking a query runs it and displays results in a grid. You can edit work items inline, change states, assign them, and save changes back to Azure DevOps.

This is particularly useful during standup meetings. Instead of navigating the Azure DevOps web portal, you can pull up your sprint backlog query, update statuses, and get back to coding in the same window.

Associating Commits with Work Items

One of the most valuable Team Explorer features is the ability to link commits to work items at commit time. In the Git Changes pane, you will see a "Related Work Items" section beneath the commit message. Click the + button to search for and attach work items. When you commit, Visual Studio automatically adds the #workItemId reference, creating traceability from code to requirements.

Azure Repos Extension for VS Code

VS Code does not ship with Azure DevOps integration out of the box, but the Azure Repos extension from Microsoft fills that gap. Install it from the Extensions marketplace by searching for "Azure Repos" (publisher: Microsoft).

Once installed, the extension provides:

• TFVC (Team Foundation Version Control) support if your team has not migrated to Git
• The ability to browse and open files directly from Azure Repos
• Authentication via Microsoft account or PAT

For most teams using Git, the Azure Repos extension is complemented by the Azure DevOps extension, which we will cover in detail later. The two work together to provide a complete experience.

Authentication Setup

When you first use the Azure Repos extension, it will prompt you to sign in. You have two options:

1. Microsoft Account — The extension opens a browser for OAuth authentication
2. Personal Access Token — You enter a PAT directly in VS Code

For automated scenarios or if you are behind a corporate proxy, the PAT approach is more reliable. You can store the PAT in your system credential manager so you do not have to re-enter it every time.

Connecting to Azure DevOps from IDEs

Both Visual Studio and VS Code support multiple authentication methods when connecting to Azure DevOps. Understanding these is critical, especially in enterprise environments.

Credential Manager Integration

Git Credential Manager (GCM) handles authentication for Git operations across both editors. When you clone a repository from Azure DevOps, GCM intercepts the authentication challenge and either uses cached credentials or prompts you to sign in.

On Windows, GCM stores tokens in the Windows Credential Manager. You can inspect stored credentials by opening Control Panel > Credential Manager > Windows Credentials and looking for entries starting with git:https://dev.azure.com.

If authentication fails unexpectedly, clearing these cached credentials often resolves the issue:

git credential-manager reject https://dev.azure.com

SSH Key Authentication

For developers who prefer SSH over HTTPS, Azure DevOps supports SSH keys. Generate a key pair if you do not already have one:

ssh-keygen -t ed25519 -C "[email protected]"

Add the public key to Azure DevOps under User Settings > SSH Public Keys. Then clone using the SSH URL format:

git clone [email protected]:v3/your-org/your-project/your-repo

SSH avoids PAT expiration issues and is generally smoother for day-to-day development once configured.

Work Item Management from the IDE

Managing work items from your IDE keeps you in flow. Both Visual Studio and VS Code provide mechanisms to query, create, and update work items.

VS Code Work Item Integration

With the Azure DevOps extension installed, you can open the command palette (Ctrl+Shift+P) and type "Azure DevOps: Open Work Item" to search for work items by ID or title. The extension opens the work item in a webview panel inside VS Code.

You can also create a custom task in VS Code to quickly open work items:

{
  "label": "Open Work Item",
  "type": "shell",
  "command": "start https://dev.azure.com/your-org/your-project/_workitems/edit/${input:workItemId}",
  "problemMatcher": []
}

Linking Commits to Work Items

The standard approach works in both editors. Include #workItemId in your commit message:

git commit -m "Add input validation to registration form #1234"

Azure DevOps parses the commit message and creates a link between the commit and work item 1234. You can use multiple formats:

• #1234 — Links to work item
• Fixes #1234 — Links and transitions the work item to resolved/done state
• AB#1234 — Explicit Azure Boards reference (useful if you also use GitHub)

This is one of those features that costs nothing to adopt but provides enormous value for traceability. Every commit should reference a work item.

Git Operations with Azure Repos

Azure Repos is fully Git-compatible, so any Git client works. The IDE integrations add convenience layers on top of standard Git.

Visual Studio Git Integration

Visual Studio 2022 replaced the old Team Explorer Git interface with the Git Changes window and Git Repository window. These provide:

• A visual branch graph showing commit history
• Drag-and-drop cherry-picking
• Interactive rebase UI
• Fetch, pull, push with remote branch tracking
• Stash management

The Git Repository window (View > Git Repository) is particularly useful for visualizing branch topology when working on feature branches that need to be rebased before merging.

VS Code Source Control

VS Code's built-in Source Control panel handles all standard Git operations. When connected to Azure Repos, you get additional features:

• Branch creation that follows your project's branch naming conventions
• Automatic upstream tracking configuration
• Conflict resolution with a three-way merge editor

For teams working with Azure DevOps, I recommend configuring VS Code to always fetch before showing branch status:

{
  "git.autofetch": true,
  "git.autofetchPeriod": 120,
  "git.confirmSync": false,
  "git.enableSmartCommit": true
}

This keeps your local repository aware of remote changes without manual intervention.

PR Creation and Review from VS Code

Pull request workflows are where IDE integration really shines. The Azure DevOps extension and the GitHub Pull Requests and Issues extension (if your Azure DevOps project mirrors to GitHub) both support in-editor PR management.

Creating a Pull Request

After pushing your feature branch, open the command palette and run "Azure DevOps: Create Pull Request." The extension pre-fills the title from your branch name and the description from your commit messages. You can select reviewers, link work items, and set merge options before submitting.

Alternatively, you can create PRs from the terminal using the Azure DevOps CLI:

az repos pr create --title "Add input validation" \
  --description "Implements validation rules for the registration form. Fixes #1234" \
  --source-branch feature/input-validation \
  --target-branch main \
  --reviewers "[email protected]" "[email protected]" \
  --work-items 1234

Reviewing Pull Requests

The extension adds a Pull Requests view to the Source Control sidebar. You can see all active PRs for your repository, click into one, and review the diff inline. Comments appear as decorations in the editor gutter. You can add new comments, reply to threads, resolve discussions, and approve or reject the PR without leaving VS Code.

This is a genuine productivity improvement. Reviewing code in your editor, where you have IntelliSense, go-to-definition, and all your extensions available, is far more effective than reviewing in a browser.

Code Review with Inline Comments

When reviewing a PR in VS Code, you can click on any line in the diff view to add a comment. The extension supports:

• Single-line comments
• Multi-line selection comments
• Suggestions with code blocks (the author can apply these as commits)
• Comment threads with replies
• Status tags (active, resolved, will not fix)

Pipeline Status in the IDE

Monitoring pipeline runs from your IDE eliminates the need to keep an Azure DevOps browser tab open just to watch builds.

Build Status in VS Code

The Azure Pipelines extension shows build status in the VS Code status bar. You can click it to see recent pipeline runs, their status, and duration. Failed builds show error details with links to the specific logs.

Configure the extension to show notifications for completed builds:

{
  "azure-pipelines.notifications.enabled": true,
  "azure-pipelines.notifications.showOnSuccess": false,
  "azure-pipelines.notifications.showOnFailure": true
}

This way you only get interrupted when something breaks, not on every successful build.

Visual Studio Build Monitoring

In Visual Studio, the Team Explorer Builds section shows all build definitions and recent runs. You can queue a new build, view logs, and download artifacts directly from the IDE. The notification system integrates with the Visual Studio notification hub (the flag icon in the title bar).

Code Lens for Work Item Linking

Code Lens is a powerful feature in both Visual Studio and VS Code that displays contextual information above functions, classes, and other code elements. When integrated with Azure DevOps, Code Lens can show linked work items, recent changes, and authorship information.

Enabling Azure DevOps Code Lens

In Visual Studio, Code Lens is enabled by default. Navigate to Tools > Options > Text Editor > All Languages > Code Lens to configure what appears. Enable "Show Azure DevOps work item linking" to see references to work items in commit messages that touched each method.

In VS Code, Code Lens for Git is provided by extensions like GitLens. While GitLens does not natively integrate with Azure DevOps work items, you can combine it with the Azure DevOps extension to get a complete picture. GitLens shows who last modified each line and when, and the Azure DevOps extension connects those changes to work items.

Practical Application

Code Lens shines when you are investigating a bug. You hover over a method, see it was last changed two weeks ago as part of work item #1087 ("Refactor payment processing"), and immediately understand the context. Without Code Lens, you would need to run git blame, find the commit, look up the commit message, and manually cross-reference the work item. Code Lens collapses all of that into a single line above the code.

Azure DevOps Extension for VS Code Features

The Azure DevOps extension pack for VS Code (sometimes listed as "Azure DevOps Services" in the marketplace) bundles several capabilities:

• Azure Repos — Source control integration with TFVC and Git
• Azure Pipelines — YAML pipeline editing with IntelliSense
• Azure Boards — Work item management
• Azure Test Plans — Test case management and execution

Key Commands

After installing, these command palette commands become available:

Command	Description
Azure DevOps: Open Work Item	Search and open a work item
Azure DevOps: Create Pull Request	Create a PR from current branch
Azure DevOps: View Pull Requests	List active PRs
Azure DevOps: Open Build Summary	View recent build results
Azure DevOps: Sign In	Authenticate with Azure DevOps

Custom Queries in VS Code

You can define custom work item queries in your VS Code settings to surface relevant items in the sidebar:

{
  "azureDevOps.queries": [
    {
      "name": "My Active Items",
      "wiql": "SELECT [System.Id], [System.Title], [System.State] FROM WorkItems WHERE [System.AssignedTo] = @Me AND [System.State] = 'Active' ORDER BY [System.ChangedDate] DESC"
    },
    {
      "name": "Sprint Bugs",
      "wiql": "SELECT [System.Id], [System.Title] FROM WorkItems WHERE [System.WorkItemType] = 'Bug' AND [System.IterationPath] = @CurrentIteration ORDER BY [Microsoft.VSTS.Common.Priority] ASC"
    }
  ]
}

IntelliSense for Pipeline YAML

Writing Azure Pipelines YAML without IntelliSense is painful. The Azure Pipelines extension for VS Code provides schema-aware autocompletion for azure-pipelines.yml files.

What You Get

• Autocompletion for all built-in tasks (e.g., task: NodeTool@0)
• Parameter suggestions with documentation tooltips
• Validation of required fields
• Template parameter resolution
• Variable group references

Configuration

Install the "Azure Pipelines" extension from Microsoft. Then add this to your workspace settings:

{
  "azure-pipelines.configure": true,
  "files.associations": {
    "**/pipelines/*.yml": "azure-pipelines",
    "**/pipelines/*.yaml": "azure-pipelines",
    "azure-pipelines*.yml": "azure-pipelines"
  }
}

This ensures all your pipeline files get proper IntelliSense regardless of their exact filename.

Example with IntelliSense

With the extension active, typing - task: in a pipeline YAML file triggers autocompletion showing all available tasks. Selecting one auto-populates the required inputs:

trigger:
  branches:
    include:
      - main
      - release/*

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '18.x'
    displayName: 'Install Node.js'

  - script: |
      npm ci
      npm run build
      npm test
    displayName: 'Build and Test'

  - task: PublishTestResults@2
    inputs:
      testResultsFormat: 'JUnit'
      testResultsFiles: '**/test-results.xml'
    condition: always()
    displayName: 'Publish Test Results'

Every task name, input, and condition expression is validated in real time. Typos get red underlines before you even commit.

Debugging Pipelines Locally

One of the biggest frustrations with CI/CD pipelines is the feedback loop. You push a change, wait for the pipeline to run, discover an error, fix it, push again, and repeat. Debugging locally shortens this loop dramatically.

Using Node.js to Validate Pipeline Logic

While you cannot run Azure Pipelines locally in their entirety, you can validate the logic of your pipeline scripts. Create a local test runner:

var fs = require('fs');
var yaml = require('js-yaml');
var path = require('path');

function validatePipeline(filePath) {
  var content = fs.readFileSync(filePath, 'utf8');
  var pipeline;

  try {
    pipeline = yaml.load(content);
  } catch (err) {
    console.error('YAML parse error:', err.message);
    return false;
  }

  var errors = [];

  if (!pipeline.trigger) {
    errors.push('Missing trigger configuration');
  }

  if (!pipeline.pool && !pipeline.stages) {
    errors.push('Missing pool or stages configuration');
  }

  var steps = pipeline.steps || [];
  if (pipeline.stages) {
    pipeline.stages.forEach(function(stage) {
      if (stage.jobs) {
        stage.jobs.forEach(function(job) {
          steps = steps.concat(job.steps || []);
        });
      }
    });
  }

  steps.forEach(function(step, index) {
    if (step.task && !step.displayName) {
      errors.push('Step ' + index + ': task "' + step.task + '" missing displayName');
    }
  });

  if (errors.length > 0) {
    console.error('Validation errors:');
    errors.forEach(function(err) {
      console.error('  - ' + err);
    });
    return false;
  }

  console.log('Pipeline validation passed');
  return true;
}

var pipelineFile = process.argv[2] || 'azure-pipelines.yml';
var result = validatePipeline(path.resolve(pipelineFile));
process.exit(result ? 0 : 1);

Run it from your project root:

node validate-pipeline.js azure-pipelines.yml

Running Pipeline Scripts Locally

For script steps in your pipeline, extract them into standalone files that you can run locally:

// scripts/build.js
var exec = require('child_process').execSync;

function runBuild() {
  console.log('Installing dependencies...');
  exec('npm ci', { stdio: 'inherit' });

  console.log('Running linter...');
  exec('npm run lint', { stdio: 'inherit' });

  console.log('Running tests...');
  exec('npm test', { stdio: 'inherit' });

  console.log('Building application...');
  exec('npm run build', { stdio: 'inherit' });

  console.log('Build completed successfully');
}

runBuild();

Then reference it in your pipeline:

steps:
  - script: node scripts/build.js
    displayName: 'Build and Test'

This approach means you can run node scripts/build.js locally and get the exact same behavior as the pipeline. No more guessing.

Branch Policies Enforcement from IDE

Branch policies in Azure DevOps ensure code quality gates are met before merging. These policies are enforced server-side, but your IDE can surface them early so you do not waste time on a PR that will be blocked.

What Branch Policies Look Like in VS Code

When you create a PR from VS Code, the Azure DevOps extension shows the status of branch policies:

• Minimum reviewers — Shows how many approvals you have versus how many are required
• Build validation — Shows whether required builds have passed
• Work item linking — Warns if no work items are linked
• Comment resolution — Indicates whether all comments must be resolved
• Merge strategy — Shows whether squash merge is required

Configuring Branch Policies via CLI

You can also manage branch policies from the command line, which is useful for setting up new repositories:

# Require minimum 2 reviewers
az repos policy approver-count create \
  --branch main \
  --repository-id YOUR_REPO_ID \
  --blocking true \
  --enabled true \
  --minimum-approver-count 2 \
  --reset-on-source-push true

# Require linked work items
az repos policy work-item-linking create \
  --branch main \
  --repository-id YOUR_REPO_ID \
  --blocking true \
  --enabled true

# Require build validation
az repos policy build create \
  --branch main \
  --repository-id YOUR_REPO_ID \
  --build-definition-id YOUR_BUILD_ID \
  --blocking true \
  --enabled true \
  --display-name "CI Build" \
  --queue-on-source-update-only true

Live Share for Collaborative Debugging

Visual Studio Live Share integrates with Azure DevOps to enable real-time collaborative debugging. This is especially valuable for distributed teams who cannot walk over to a colleague's desk.

Setting Up Live Share with Azure DevOps

Install the Live Share extension in VS Code. When you start a session, you can share:

• Your editor (files, terminals, and debugging sessions)
• A link that teammates can join from their own VS Code instance
• Shared servers (localhost ports forwarded to collaborators)

The Azure DevOps integration means you can link Live Share sessions to work items. When you are pair-debugging a bug, create a comment on the work item with the Live Share link. This creates a record of the collaboration session tied to the bug.

Collaborative Debugging Workflow

Here is a practical workflow for debugging a production issue collaboratively:

1. A bug work item is created in Azure DevOps (e.g., #2045)
2. You create a branch: git checkout -b bugfix/2045-payment-timeout
3. You start a Live Share session and paste the link in the work item comments
4. Your colleague joins the session from their machine
5. You both set breakpoints, inspect variables, and step through code together
6. You commit the fix with git commit -m "Fix payment timeout on slow connections #2045"
7. You create a PR from VS Code, and the colleague approves it immediately

The entire workflow happens inside the IDE. No screen sharing tools, no browser tabs, no context switching.

Complete Working Example: Team Onboarding Workspace

Here is a complete VS Code workspace configuration that integrates Azure DevOps for a Node.js team. This is the kind of setup you hand to a new developer on their first day.

Workspace File

Create a file called project.code-workspace:

{
  "folders": [
    {
      "path": "."
    }
  ],
  "settings": {
    "git.autofetch": true,
    "git.autofetchPeriod": 120,
    "git.confirmSync": false,
    "git.enableSmartCommit": true,
    "git.postCommitCommand": "push",
    "azure-pipelines.configure": true,
    "files.associations": {
      "**/pipelines/*.yml": "azure-pipelines",
      "azure-pipelines*.yml": "azure-pipelines"
    },
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
      "source.fixAll.eslint": "explicit"
    }
  },
  "extensions": {
    "recommendations": [
      "ms-azure-devops.azure-pipelines",
      "ms-vsts.team",
      "ms-vsliveshare.vsliveshare",
      "eamodio.gitlens",
      "esbenp.prettier-vscode",
      "dbaeumer.vscode-eslint",
      "ms-azuretools.vscode-azureresourcegroups"
    ]
  },
  "tasks": {
    "version": "2.0.0",
    "tasks": [
      {
        "label": "Validate Pipeline",
        "type": "shell",
        "command": "node scripts/validate-pipeline.js azure-pipelines.yml",
        "group": "build",
        "problemMatcher": []
      },
      {
        "label": "Run Tests",
        "type": "shell",
        "command": "npm test",
        "group": "test",
        "problemMatcher": ["$tsc"]
      },
      {
        "label": "Open Work Item",
        "type": "shell",
        "command": "start https://dev.azure.com/your-org/your-project/_workitems/edit/${input:workItemId}",
        "problemMatcher": []
      },
      {
        "label": "Create Feature Branch",
        "type": "shell",
        "command": "git checkout -b feature/${input:branchName} && git push -u origin feature/${input:branchName}",
        "problemMatcher": []
      },
      {
        "label": "Create Bugfix Branch",
        "type": "shell",
        "command": "git checkout -b bugfix/${input:workItemId}-${input:branchName} && git push -u origin bugfix/${input:workItemId}-${input:branchName}",
        "problemMatcher": []
      }
    ],
    "inputs": [
      {
        "id": "workItemId",
        "description": "Azure DevOps Work Item ID",
        "type": "promptString"
      },
      {
        "id": "branchName",
        "description": "Branch name (lowercase, hyphens)",
        "type": "promptString"
      }
    ]
  }
}

VS Code Snippets for Azure Pipelines

Create .vscode/azure-pipelines.code-snippets:

{
  "Pipeline Node.js Step": {
    "prefix": "azp-node",
    "scope": "azure-pipelines",
    "body": [
      "- task: NodeTool@0",
      "  inputs:",
      "    versionSpec: '${1:18}.x'",
      "  displayName: 'Install Node.js ${1:18}'"
    ],
    "description": "Add Node.js tool installer step"
  },
  "Pipeline npm Step": {
    "prefix": "azp-npm",
    "scope": "azure-pipelines",
    "body": [
      "- script: |",
      "    npm ci",
      "    npm run ${1:build}",
      "  displayName: '${2:Install and Build}'"
    ],
    "description": "Add npm script step"
  },
  "Pipeline Publish Artifacts": {
    "prefix": "azp-publish",
    "scope": "azure-pipelines",
    "body": [
      "- task: PublishBuildArtifacts@1",
      "  inputs:",
      "    pathToPublish: '${1:$(Build.ArtifactStagingDirectory)}'",
      "    artifactName: '${2:drop}'",
      "  displayName: 'Publish Artifacts'"
    ],
    "description": "Publish build artifacts step"
  },
  "Pipeline Stage": {
    "prefix": "azp-stage",
    "scope": "azure-pipelines",
    "body": [
      "- stage: ${1:Build}",
      "  displayName: '${2:Build Stage}'",
      "  jobs:",
      "    - job: ${3:BuildJob}",
      "      displayName: '${4:Build}'",
      "      pool:",
      "        vmImage: 'ubuntu-latest'",
      "      steps:",
      "        - $0"
    ],
    "description": "Add a pipeline stage"
  }
}

Team Setup Script

Create a script that new team members run to verify their environment is ready:

// scripts/verify-setup.js
var exec = require('child_process').execSync;
var fs = require('fs');

function check(name, fn) {
  try {
    fn();
    console.log('[PASS] ' + name);
    return true;
  } catch (err) {
    console.error('[FAIL] ' + name + ': ' + err.message);
    return false;
  }
}

var results = [];

results.push(check('Git installed', function() {
  var version = exec('git --version', { encoding: 'utf8' }).trim();
  if (!version.includes('git version')) {
    throw new Error('Git not found');
  }
  console.log('       ' + version);
}));

results.push(check('Node.js installed', function() {
  var version = exec('node --version', { encoding: 'utf8' }).trim();
  var major = parseInt(version.replace('v', '').split('.')[0], 10);
  if (major < 18) {
    throw new Error('Node.js 18+ required, found ' + version);
  }
  console.log('       Node ' + version);
}));

results.push(check('Azure DevOps CLI installed', function() {
  exec('az devops --help', { encoding: 'utf8' });
}));

results.push(check('Git remote configured', function() {
  var remotes = exec('git remote -v', { encoding: 'utf8' });
  if (!remotes.includes('dev.azure.com') && !remotes.includes('visualstudio.com')) {
    throw new Error('No Azure DevOps remote found');
  }
}));

results.push(check('VS Code extensions installed', function() {
  var extensions = exec('code --list-extensions', { encoding: 'utf8' });
  var required = [
    'ms-azure-devops.azure-pipelines',
    'ms-vsts.team',
    'eamodio.gitlens'
  ];
  var missing = required.filter(function(ext) {
    return extensions.indexOf(ext) === -1;
  });
  if (missing.length > 0) {
    throw new Error('Missing extensions: ' + missing.join(', '));
  }
}));

results.push(check('Pipeline YAML exists', function() {
  if (!fs.existsSync('azure-pipelines.yml')) {
    throw new Error('azure-pipelines.yml not found in project root');
  }
}));

var passed = results.filter(function(r) { return r; }).length;
var total = results.length;

console.log('\n' + passed + '/' + total + ' checks passed');

if (passed < total) {
  console.error('\nPlease fix the failing checks before starting development.');
  process.exit(1);
} else {
  console.log('\nEnvironment is ready. Welcome to the team!');
}

Run it with node scripts/verify-setup.js and hand the output to your team lead if anything fails.

Common Issues and Troubleshooting

1. Authentication Loop When Cloning

Symptom: Git repeatedly prompts for credentials when cloning from Azure DevOps, even after entering correct credentials.

Fix: This usually means Git Credential Manager is not properly installed or configured. Verify with:

git config --global credential.helper

It should return manager or manager-core. If it is empty or set to something else, reinstall Git Credential Manager:

git config --global credential.helper manager

If you are on a corporate network with SSL inspection, you may also need:

git config --global http.sslBackend schannel

2. VS Code Extension Cannot Find Organization

Symptom: The Azure DevOps extension shows "No organizations found" despite being signed in with the correct account.

Fix: This often happens when you have multiple Microsoft accounts (personal and work). Open VS Code settings and explicitly set the organization:

{
  "azure-devops.organization": "https://dev.azure.com/your-org",
  "azure-devops.project": "your-project"
}

If the issue persists, sign out of all Microsoft accounts in VS Code, restart the editor, and sign in with only the account that has Azure DevOps access.

3. Pipeline YAML IntelliSense Not Working

Symptom: No autocompletion or validation in pipeline YAML files.

Fix: Ensure the file is recognized as an Azure Pipelines file. Check the language mode in the bottom-right corner of VS Code. It should say "Azure Pipelines" not "YAML". If it shows "YAML", click it and select "Azure Pipelines" from the dropdown. To make this permanent, add the file association to your workspace settings as shown in the configuration section above.

4. Pull Request Creation Fails with Policy Error

Symptom: Creating a PR from VS Code fails with "Policy requirements not met."

Fix: This means your branch policies require certain conditions before a PR can be created. Common culprits:

• No linked work items — Add #workItemId to your commit messages
• No build passing — Push your changes and wait for the CI build to complete
• Branch is not up to date with target — Rebase or merge the target branch into your feature branch

Check the policy requirements in Azure DevOps under Project Settings > Repositories > Policies > Branch Policies for the target branch.

5. Live Share Session Disconnects Behind VPN

Symptom: Live Share sessions drop or fail to connect when participants are on VPN.

Fix: Live Share uses relay servers that VPN split-tunneling may block. Add the following to your VS Code settings:

{
  "liveshare.connectionMode": "relay",
  "liveshare.allowGuestDebugControl": true
}

If relay mode does not work, try "direct" mode and ensure ports 443 and 22 are open on your VPN configuration.

Best Practices

• Always link commits to work items. Use #workItemId in every commit message. This takes two seconds and creates an audit trail that is invaluable during incident investigations and compliance audits.

• Use workspace files for team consistency. Check your .code-workspace file into the repository so every team member gets the same extensions, settings, and tasks. This eliminates the "works on my machine" problem for tooling.

• Enable auto-fetch in VS Code. Setting git.autofetch to true with a 120-second interval keeps your local branch references current. You will see when teammates push changes without manually running git fetch.

• Install the Azure Pipelines extension before writing YAML. IntelliSense catches typos, missing required fields, and deprecated task versions before you push. This saves at least one or two failed pipeline runs per change.

• Use branch naming conventions that include work item IDs. Naming branches like feature/1234-add-validation or bugfix/2045-timeout-fix creates a natural link between branches and the work they implement. Most Azure DevOps extensions can parse these patterns.

• Review PRs in your IDE, not the browser. You have IntelliSense, type checking, go-to-definition, and all your custom extensions in the IDE. Browser reviews miss issues that are obvious when you can navigate the codebase.

• Run pipeline scripts locally before pushing. Extract pipeline script steps into standalone files and execute them locally. This cuts the feedback loop from 5-10 minutes to seconds.

• Keep PATs scoped narrowly and rotate them regularly. Create separate PATs for different purposes (IDE access, CLI tools, CI/CD) with the minimum required permissions. Set expiration dates and track them in your team's credential management system.

• Use Live Share for synchronous debugging sessions. When a bug requires two pairs of eyes, Live Share is faster and more effective than screen sharing because both participants have full editor control.

References

• Azure DevOps Documentation — Official Microsoft documentation for all Azure DevOps services
• Azure Repos Extension for VS Code — Official extension for Azure DevOps integration in VS Code
• Azure Pipelines Extension — YAML IntelliSense and pipeline management
• Visual Studio Team Explorer — Guide to Team Explorer in Visual Studio
• Git Credential Manager — Cross-platform credential management for Git
• Visual Studio Live Share — Real-time collaborative development documentation
• Azure DevOps CLI — Command-line interface for Azure DevOps operations