Azure DevOps Q&A Series – Part 2

 

Welcome to Part 2 of our Azure DevOps Q&A series. This section focuses on two of the most essential building blocks of any DevOps workflow — Azure Repos and Azure Pipelines.

In the first half, we’ll explore everything you need to know about Azure Repos — including Git fundamentals, real-world branching strategies, pull requests, merge policies, and repository-level security.

The second half is dedicated to Azure Pipelines — where we’ll cover YAML pipelines, CI/CD concepts, pipeline structure (stages, jobs, steps), agent pools, approvals, artifacts, and other automation practices used in real-world deployments.

Whether you’re building applications, provisioning infrastructure, or managing enterprise DevOps platforms, this part will help you confidently manage code and automation workflows within Azure DevOps.

🔹 Section 1: Azure Repos – Source Control in Azure DevOps

Q1: What is Azure Repos and why is it used?

Azure Repos is the source control service within Azure DevOps. It provides Git-based version control to manage your code, configuration files, infrastructure scripts (like Terraform or Bicep), and documentation — all in one place. It enables:

    • Team collaboration through branches and pull requests
    • Version history for audit and rollback
    • Integration with pipelines, boards, and work items
    • Code reviews via pull requests
    • Policy enforcement for high-quality code

Azure Repos supports both Git (distributed) and TFVC (centralized), but Git is the industry standard and the default for new projects.

Q2: What is the difference between Git and TFVC in Azure Repos?

Feature Git (default) TFVC (legacy)
Model Distributed Centralized
Branching Lightweight and fast Heavy and complex
Offline work Fully supported Limited
Collaboration Excellent for open-source and cross-teams Better suited for tightly controlled environments
Support Industry-standard Deprecated directionally

Git is the recommended choice in almost all modern DevOps scenarios. TFVC is rarely used today and mostly retained for legacy migration.

Q3: What is the difference between a local and a remote Git repository?

Local Repository: Exists on your development machine. You can commit changes, create branches, and work offline.

Remote Repository: Hosted in Azure Repos (or any Git server). Acts as the central source of truth for collaboration.

The typical Git workflow involves:

      • git pull – Sync latest changes from remote to local
      • git commit – Save changes locally
      • git push – Send local commits to the remote repo

Q4: Why is branching strategy important in Azure Repos?

A well-defined branching strategy ensures:

    • Safe parallel development (feature branches)
    • Isolated hotfixes and releases
    • Clean code promotion through environments

Common industry practice:

    • Use main or master as the protected, deployable branch
    • Create short-lived feature branches
    • Use pull requests to merge into main
    • Implement branch policies for validation (build, review)

Q5: What are pull requests in Azure Repos?

A pull request (PR) is a formal proposal to merge code from one branch (usually a feature branch) into another (typically main).

It enables:

    • Code review
    • Threaded comments and discussions
    • Automatic build validation (CI)
    • Enforcement of reviewer approvals

PRs can be linked to work items for traceability. You can configure rules such as minimum number of reviewers, check policies, and prevent auto-complete if checks fail.

Q6: What is a merge conflict and how is it resolved?

A merge conflict happens when two branches modify the same line in a file or change overlapping areas. Git cannot auto-resolve it, so manual intervention is needed.

Resolution involves:

    1. Identifying conflicting files (Git marks them)
    2. Editing the files to choose or combine the changes
    3. Staging and committing the resolved version
    4. Completing the merge or pull request

Azure DevOps provides an inline diff and merge editor in the PR UI.

Q7: How do you secure an Azure Repo using permissions and access control?

Azure Repos supports fine-grained access control using Azure DevOps security groups and repository-level permissions.

You can manage permissions at:

    • Project level (broad access to all repos)
    • Repo level (access to a specific repo)
    • Branch level (specific restrictions on protected branches)

Common permission scopes include:

    • Read: View code and history
    • Contribute: Push commits
    • Create branch: Make new branches
    • Force push: Overwrite history (should be tightly controlled)
    • Bypass policies: Reserved for service accounts or leads

Best practice:

    • Grant minimal required access (principle of least privilege)
    • Avoid giving Contribute to main branch directly — enforce PRs
    • Use AAD groups or Azure DevOps teams to manage permissions at scale

Q8: How does authentication work when accessing Azure Repos from Git clients or tools like VS Code?

When accessing Azure Repos from Git clients (e.g., VS Code, Git CLI, or automation scripts), authentication is required to verify your identity and authorize access to the repository. Azure DevOps supports multiple secure authentication methods depending on the tool and scenario:

✅ Common Authentication Methods:

    1. Git Credential Manager (GCM)
        • Default for modern tools like VS Code, Visual Studio, and Git for Windows
        • Uses Azure AD (OAuth) to authenticate via a secure browser popup
        • Stores credentials securely in the system keychain or credential store
        • Recommended for interactive developer workflows
    1. SSH Keys
        • Public/private key-based authentication
        • Ideal for scripting, automation, or non-interactive agents
        • No passwords or tokens are stored; highly secure when managed correctly
    1. Personal Access Tokens (PAT)
      • A manually generated token used over HTTPS
      • Often used in legacy tools, service connections, or CI/CD pipelines
      • Not recommended for daily development use due to manual management and security risks if exposed

💡 Important Notes:

    • VS Code, when used with Git over HTTPS, does not require you to manually enter a PAT. Instead, it uses Git Credential Manager to authenticate with Azure AD tokens, providing a seamless and secure login.

    • PATs should be treated like passwords — if you use them, scope them minimally and rotate them regularly.

    • In enterprise environments, prefer Azure AD-based login with Conditional Access and MFA for maximum security and compliance.

Q9: What are Branch Policies in Azure Repos and why are they important?

Branch Policies allow you to enforce standards and validations before code can be merged into a protected branch like main or release.

Key policies include:

    • No direct pushes (PRs only)
    • Requestor cannot approve their own pull request
    • Minimum number of reviewers for PR
    • Required linked work item
    • Successful build validation (CI pipeline)
    • Comment resolution before merge
    • Limit merge types (squash, rebase, merge commit)

Branch Policies maintain code quality, enforce team discipline, prevent regressions, and enable traceability.

Q10: What are commits, commit history, and revert in Git (as used in Azure Repos)?

    • A commit is a snapshot of your changes in a Git repository. Each time you save your progress in a particular branch, you make a commit. A commit includes the actual changes made, a commit message, the author’s identity, and a unique hash that acts as a fingerprint for that commit.

    • Every commit must have a message describing the change. This helps others (and your future self) understand the purpose of the change when reviewing history.
    • Commit history is the ordered list of all commits in the repository. It shows who made what change and when. You can view this history in Azure Repos or by using commands like git log.

    • Commits form the backbone of version control, allowing you to track evolution, perform rollbacks, or investigate issues.

    • If you need to undo a change:
      • Use git revert to create a new commit that negates a previous one. This is safe for shared branches.
      • Avoid git reset on shared branches as it rewrites history and can disrupt your teammates’ work.

In Azure Repos, the Commits tab makes it easy to explore commit history, file changes, linked work items, and contributing users.

Q11: What is a good branching strategy to follow in Azure Repos?

A strong branching strategy improves code quality, team collaboration, and release confidence. Most teams follow a model based on the trunk-based or GitFlow approach, customized to their needs.

    • main or master: Protected branch for production-ready code
    • develop: (optional) For integration and staging
    • feature/*: For new features, short-lived and isolated
    • bugfix/*: For fixing bugs in development
    • hotfix/*: For urgent fixes directly into main
    • release/*: For preparing a stable release

Best practices:

    • Use pull requests to merge into main
    • Protect main with branch policies
    • Keep feature branches short-lived
    • Automate branch cleanup post-merge

Q12: What is the difference between a fork and a clone in Git?

In Git, both fork and clone refer to ways of copying a repository — but they serve very different purposes and have different implications, especially when it comes to collaboration.

🔁 Clone

    • A clone is a local copy of an existing Git repository.
    • It is used when you want to contribute directly to the same repository, typically by creating a branch and pushing code back.
    • The cloned repository maintains a connection (called origin) to the source repository, so you can pull and push changes.
    • You still work within the same Azure DevOps project/repo — permissions apply.

✔️ Common usage in Azure Repos: Cloning is the default workflow in Azure DevOps. Team members clone a central repo and work in branches.

🍴 Fork

    • A fork is a server-side copy of a repository, typically made when you don’t have write access to the original repo.
    • You can push code to your fork, and then submit a pull request to the original repository.
    • Forking allows open-source-style contributions and code isolation without direct repo access.
    • In Azure DevOps, forking is available but used less commonly than in platforms like GitHub.

✔️ Forks in Azure DevOps are supported, especially for large teams or contributors outside the core team, but most internal enterprise teams use branching and cloning instead of forks.

Q13: What are the different merge strategies supported in Azure Repos?

    • Merge Commit: Preserves all commits and adds a new merge commit
    • Squash Merge: Combines all changes into a single commit (clean history)
    • Rebase and Fast-forward: Rewrites history to keep it linear

You can enforce your preferred merge strategy using branch policy settings.

Q14: How do you link a work item to a commit or pull request in Azure Repos?

Linking ensures full traceability:

    • Use #ID in commit messages to auto-link
    • Mention #ID in PR descriptions (e.g., Resolves #321)
    • Manually link from the PR UI

This helps track which code delivered a feature or fix and enhances audit readiness.

Q15: How can we automate code quality checks using branch policies and pipelines?

  • Azure DevOps offers robust integration between branch policies, build pipelines, and code quality tools to enforce consistent, high-quality code before it reaches your protected branches (like main or release).

Here’s how you can set up automation for code quality:

🔁 CI Pipelines with Build Validation

      • Use build validation policies to automatically trigger a CI pipeline every time a pull request (PR) is raised against a protected branch.
      • The pipeline runs unit tests, performs build verification, and can fail the PR if the build breaks or tests fail.
      • This ensures broken code or regressions never make it into production branches.

🧪 Static Code Analysis Tools

      • Integrate tools like SonarQube, Checkmarx, WhiteSource, or ESLint into your pipeline.
      • These tools run static analysis during the pipeline execution to scan for:
          • Code smells
          • Security vulnerabilities
          • Maintainability issues
      • You can define quality gates that must pass before the PR can be merged.

✅ Enforced Reviewer Policies

  • Branch policies can require:
      • A minimum number of reviewers
      • Reviewers to resolve all comments
      • Linked work items for traceability
  • This enforces peer review discipline, helping catch bugs and design flaws early.

🛑 Status Checks

  • You can define status checks in the branch policy to block PRs if:
      • Any CI pipeline step fails
      • Quality gate thresholds (e.g., SonarQube ratings) are not met
  • These checks appear directly on the PR screen, making it transparent and auditable.

🔁 Auto-complete Option

  • The auto-complete feature finalizes the PR only when all conditions are met:
    • CI passes
    • Required reviews are completed
    • Linked work items are present
  • This prevents premature merging and ensures a predictable workflow.

🎯 Why it matters:

These integrated checks and gates help ensure code quality without slowing down developers. Instead of relying on manual reviews or post-deployment fixes, quality is shifted left — built into the development lifecycle.

Q16: What are some common mistakes to avoid when working with Git in Azure Repos?

❌ Committing directly to main

❌ Forgetting to pull before pushing

❌ Using git reset on shared branches

❌ Not linking commits or PRs to work items

❌ Force-pushing during merge conflicts

❌ Leaving stale branches post-merge

❌ Inconsistent use of merge strategies

Stick to protected branches, clean up regularly, and enforce automation via policies for a healthy Git workflow.

Section 2 : Azure Pipelines

Q1: What is Azure Pipelines?

Azure Pipelines is a cloud-based service in Azure DevOps that automates build, test, and deployment workflows. It supports both Continuous Integration (CI) and Continuous Deployment/Delivery (CD) using:

      • YAML pipelines (recommended and modern)
      • Classic pipelines (deprecated for new use)

Azure Pipelines works with any language or platform and can deploy to Azure, AWS, GCP, Kubernetes, on-premises servers, or even mobile platforms.

Q2: What are the key differences between classic pipelines and YAML pipelines?

Feature Classic Pipelines YAML Pipelines
Configuration GUI-based (drag-and-drop) Defined as code (YAML files)
Source control Stored separately from code Stored alongside code in repo
CI/CD separation Separate definitions Combined CI/CD in one file
Reusability Limited Reusable templates supported
Industry trend Deprecated Recommended for all use cases

Note: Microsoft recommends using YAML pipelines for all new projects. Classic pipelines are in maintenance mode and may be deprecated in the future.

Q3: What is the difference between CI and CD in Azure Pipelines?

    • CI (Continuous Integration): Automatically builds and tests your application when developers push code to the repo. Goal: detect issues early and maintain a working main branch.
    • CD (Continuous Deployment/Delivery): Automatically deploys the built application to environments like dev, QA, staging, or prod after successful CI.
        • Delivery: Needs manual approval before production.
        • Deployment: Fully automated to production.

In YAML pipelines, CI and CD are defined in the same pipeline file, often separated by stages.

Q4: What are agents in Azure Pipelines?

An agent is the compute resource that runs your pipeline jobs. Azure Pipelines supports:

    • Microsoft-hosted agents: Pre-configured VM with common build tools. No maintenance.
    • Self-hosted agents: Your own VM or container registered as an agent. Gives you control over environment, dependencies, and scaling.

Note: Organizations use self-hosted agents for speed, custom dependencies, or air-gapped environments. But they also bring overhead like updates, patching, and availability.

Q5: What are stages and jobs in a YAML pipeline?

In Azure Pipelines (YAML), the pipeline is composed of stages, each of which can contain multiple jobs, and each job contains a set of steps (tasks/scripts).

      • Stages are top-level divisions and often represent environments or lifecycle phases like Build, Test, Deploy.
      • Jobs run in parallel by default (within a stage) and represent a collection of steps that run together on the same agent.
      • Steps are individual tasks like npm install, terraform plan, or az cli commands.

You can set approvals or conditions at the stage level, which makes stages ideal for organizing complex workflows.

Q6: Why should we use multiple stages in a pipeline?

Using multiple stages provides:

    • Logical separation: Cleanly divide the pipeline into build → test → deploy stages.
    • Environment control: Associate specific stages with Dev, QA, UAT, or Prod environments.
    • Approvals & checks: Add manual approvals, pre-deployment conditions, or gates before sensitive stages (like production).
    • Parallelism: Different jobs within stages can run in parallel, improving efficiency.

Example:

    • Stage 1: Build & Unit Test
    • Stage 2: Deploy to Dev
    • Stage 3: Manual Approval → Deploy to Prod

Q7: What is an artifact in Azure Pipelines?

An artifact is a collection of files or packages generated by a pipeline that is intended for further use — typically in deployment.

Common artifact types include:

      • Compiled binaries (DLLs, JARs, etc.)
      • Docker images
      • Terraform plan outputs
      • NuGet or npm packages

Artifacts are stored and passed between stages or pipelines, especially from build stage to release stage.

Q8: What are environments in Azure Pipelines?

An Environment represents a target where your code is deployed — such as Dev, QA, or Production. It enables:

      • Deployment tracking: Know what was deployed, by whom, and when.
      • Approval gates: Add checks or approvals before deploying to sensitive environments.
    • Integration with resources: Environments can map to Azure resources, Kubernetes namespaces, or VMs.

Note: Environments bring visibility and control to deployments — especially in multi-stage YAML pipelines.

Q9: What are approvals and checks in Azure Pipelines?

Approvals and checks are used to enforce human or automated verification before allowing a stage to run.

    • Manual approvals: Assigned users or groups must approve the deployment.
    • Checks: Automated validations such as invoking a REST API, running an Azure function, or checking business conditions.

Example: Before deploying to Production, you might:

    • Require approval from the product owner
    • Run a security scan API via a gate

Q10: What is the default retention policy for Azure Pipelines? How can we customize it?

By default, Azure DevOps retains pipeline runs (including logs and artifacts) for 30 days.

You can customize retention settings at:

    • Pipeline level – Set specific retention rules per pipeline.
    • Project level – Define default policies for all pipelines.
    • Organization level – Define global retention policies.

You can also:

    • Retain runs indefinitely (e.g., tagged builds, important releases).
    • Automatically delete old runs, build artifacts, and test results to save space.

⚠️ Be mindful of artifact storage costs if you retain too many runs.

Q11: What are container-based agents and why are they useful?

A container-based agent runs inside a Docker container. Azure Pipelines supports specifying a container image in the YAML like this:

pool:
  vmImage: 'ubuntu-latest'
container: mcr.microsoft.com/dotnet/core/sdk:6.0

Benefits:

    • Ensures consistent build environment
    • Useful for dependency-heavy toolchains
    • Easily portable and version-controlled
    • Avoids polluting the host agent

Container agents are especially useful in CI builds where you want full control over the runtime and tools.

Q12: Can we reuse steps or templates across multiple pipelines?

Yes! Azure Pipelines supports YAML templates, which allow you to extract and reuse logic across pipelines.

Template Types:

    • job templates
    • step templates
    • stage templates

Example:

# templates/build.yml
steps:
  - script: npm install
  - script: npm run build

# main pipeline
jobs:
  - job: Build
    steps:
      - template: templates/build.yml

📌 Templates promote DRY (Don’t Repeat Yourself) practices and make pipeline management scalable in large teams.

Q13: How can we control access and security for pipelines?

You can manage pipeline access via:

    • Pipeline-level permissions: Who can edit or run a pipeline.
    • Environment approvals: Who can approve deployments to specific environments.
    • Library secrets: Controlled via variable groups, with permissions for viewing/editing.
    • Resource authorization: Repos, service connections, agent pools must be authorized by the pipeline before use.

🔐 Always follow the principle of least privilege — especially for production pipelines and secrets.

Q14: What are the common deployment strategies supported in Azure Pipelines?

Azure Pipelines supports multiple deployment strategies:

    • Run once (default): Just deploy the new version.
    • Rolling deployment: Gradually roll out to instances (supported in Kubernetes and VMs).
    • Canary deployment: Roll out to a small subset of users before full deployment.
    • Blue-Green deployment: Switch traffic from old (blue) to new (green) environment once validated.
    • Deployment Rings: Progressive exposure — Dev → QA → Staging → Prod.

You can implement these strategies using pipeline stages, deployment jobs, and Azure DevOps Environments.

Leave a comment