Content is user-generated and unverified.

Azure DevOps Version Control & Collaboration Best Practices

Table of Contents

  1. Branching Strategy
  2. Branch Naming Conventions
  3. Branch Linking with Work Items
  4. Git Workflow
  5. Pull Request Process
  6. How Pull Request Reviews Work in Practice
  7. Code Review Guidelines
  8. Merge Policies & Rules
  9. Environment Management
  10. Hotfix Process
  11. Release Management
  12. Best Practices Summary

Branch Linking with Work Items

Linking Branches to Azure DevOps Work Items

To ensure visibility of developer work even before commits, branches should be properly linked to work items.

Method 1: Create Branch from Work Item (Recommended)

In Azure DevOps Web Interface:

  1. Open the work item (task/user story)
  2. Go to "Development" section
  3. Click "Create a branch"
  4. Select repository and choose base branch (dev)
  5. Branch name will be auto-generated following naming conventions

Result: Branch is automatically linked and visible in work item's "Development" section.

Method 2: Auto-linking via Branch Name

When creating branches manually, use work item ID in branch name:

bash
git checkout dev
git pull origin dev
git checkout -b feature/AB#12345-user-authentication
git push -u origin feature/AB#12345-user-authentication

Azure DevOps will automatically detect and link the branch based on the AB#12345 reference.

Method 3: Manual Linking (If needed)

If auto-linking doesn't work:

  1. Open the work item in Azure DevOps
  2. Go to "Development" section
  3. Click "Add link" → "Existing item"
  4. Select "Branch" and choose your branch

Benefits of Branch Linking

  • Manager visibility: See which developers are actively working on tasks
  • Progress tracking: Monitor development activity before code commits
  • Work item history: Complete audit trail of development work
  • Team coordination: Avoid duplicate work on same features

Branching Strategy

Core Branch Structure

We'll use a Modified Git Flow approach optimized for your environment pipeline:

Protected Branches

  • main - Production-ready code (maps to prod environment)
  • release/* - Release candidates (maps to preprod environment)
  • dev - Integration branch (maps to dev environment)

Supporting Branches

  • feature/* - New features and user stories
  • bugfix/* - Bug fixes during development
  • hotfix/* - Critical production fixes
  • task/* - Technical tasks and improvements

Branch Naming Conventions

Format: type/workitem-description

Feature Branches

feature/AB#12345-user-authentication
feature/AB#12346-payment-integration

Bug Fix Branches

bugfix/AB#12347-login-validation-error
bugfix/AB#12348-dashboard-loading-issue

Task Branches

task/AB#12349-update-dependencies
task/AB#12350-refactor-user-service

Hotfix Branches

hotfix/AB#12351-critical-security-patch
hotfix/AB#12352-payment-gateway-fix

Release Branches

release/v1.2.0
release/v1.2.1

Naming Rules

  • Use Azure DevOps work item ID (AB#) prefix
  • Use kebab-case for descriptions
  • Keep descriptions concise but meaningful
  • Maximum 50 characters total

Git Workflow

Daily Development Flow

1. Starting New Work

bash
# Update dev branch
git checkout dev
git pull origin dev

# Create feature branch
git checkout -b feature/AB#12345-user-authentication

# Link branch to work item in Azure DevOps (automatic with naming convention)

2. During Development

bash
# Regular commits with clear messages
git add .
git commit -m "AB#12345: Implement user login validation"

# Push to remote regularly
git push -u origin feature/AB#12345-user-authentication

3. Completing Work

bash
# Ensure branch is up to date
git checkout dev
git pull origin dev
git checkout feature/AB#12345-user-authentication
git rebase dev

# Push final changes
git push origin feature/AB#12345-user-authentication

# Create Pull Request in Azure DevOps

Commit Message Format

AB#[WorkItemID]: [Type] [Short description]

[Optional detailed description]

Examples:
AB#12345: feat: Add user authentication endpoint
AB#12346: fix: Resolve null pointer exception in payment service
AB#12347: refactor: Extract user validation logic
AB#12348: docs: Update API documentation

Pull Request Process

PR Creation Requirements

  1. Title Format: AB#[WorkItemID]: [Brief description]
  2. Description Template:
markdown
   ## Work Item
   - Links to: AB#[WorkItemID]
   
   ## Summary
   Brief description of changes
   
   ## Changes Made
   - List key changes
   - Include any breaking changes
   
   ## Testing
   - [ ] Unit tests updated/added
   - [ ] Integration tests pass
   - [ ] Manual testing completed
   
   ## Screenshots/Evidence
   (If applicable)
   
   ## Checklist
   - [ ] Code follows team standards
   - [ ] Documentation updated
   - [ ] No merge conflicts
   - [ ] Ready for review

PR Targeting Rules

  • Feature/Bugfix/Task branchesdev
  • Hotfix branchesmain (with immediate cherry-pick to dev)
  • Release branchesmain

How Pull Request Reviews Work in Practice

Real-World PR Workflow

Developer Creates Pull Request

bash
# After completing work (typically 4-5 days)
git add .
git commit -m "AB#12345: Complete user authentication feature"
git push origin feature/AB#12345-user-authentication

Creating PR in Azure DevOps

  1. Navigate to Repos → Pull Requests
  2. Click "New Pull Request"
  3. Select source branch (feature/AB#12345-user-authentication) → target (dev)
  4. Auto-detection: Azure DevOps automatically detects linked work item
  5. Fill description using the PR template
  6. Add reviewers (can be auto-assigned based on code paths or manually selected)

What Happens When PR is Created

  1. Automatic checks run: Build validation, tests, code analysis
  2. Reviewers get notified: Email notifications + Azure DevOps notifications
  3. Review assignment: Based on policies (minimum 1 reviewer required)
  4. Work item updates: PR link appears in associated work item

Reviewer Actions & Timeline

Possible reviewer responses:

  • Approve: ✅ Ready to merge
  • Approve with suggestions: ✅ Minor improvements noted but can merge
  • Wait for author: 🔄 Changes requested before approval
  • Reject: ❌ Significant issues, needs major rework

Example timeline:

  • Day 5: Developer creates PR
  • Day 5: Automated builds and tests run
  • Day 5-6: Reviewer provides feedback
  • Day 6: Developer addresses comments (if any)
  • Day 6: Reviewer approves
  • Day 6: Merge to dev branch

Merge Process

Developer creates PR → Automated checks pass → Reviewer approves → Merge allowed → Code integrated to dev

Branch Protection in Action:

  • Blocked: Direct pushes to main/dev
  • Allowed: Only merges through approved PRs
  • 🔒 Enforced: All team members must follow this process

Example error when trying to bypass:

bash
git push origin dev
# Error: Branch dev is protected and requires a pull request

Code Review Guidelines

Review Requirements

  • Minimum 1 reviewer for all PRs
  • Tech lead approval for changes affecting multiple services or architectural changes

Review Checklist

Code Quality

  • Code follows established patterns and standards
  • No code duplication
  • Proper error handling
  • Security considerations addressed
  • Performance implications considered

Testing

  • Unit tests cover new/changed functionality
  • Integration tests updated if needed
  • Test coverage meets minimum requirements (80%)

Documentation

  • Code comments for complex logic
  • API documentation updated
  • README updated if needed

Review Timeline

  • Standard PRs: Review within 24 hours
  • Hotfixes: Review within 2 hours
  • Large PRs (>500 lines): May require extended review time

Merge Policies & Rules

Azure DevOps Branch Policies

main Branch

  • Require pull request: ✅
  • Minimum reviewers: 1
  • Require reviewer re-approval: ✅
  • Check for linked work items: ✅
  • Check for comment resolution: ✅
  • Merge type: Squash merge only

dev Branch

  • Require pull request: ✅
  • Minimum reviewers: 1
  • Check for linked work items: ✅
  • Build validation: Required
  • Merge type: Merge commit

release/* Branches

  • Require pull request: ✅
  • Minimum reviewers: 1 (tech lead approval recommended)
  • Additional approvers: QA lead sign-off recommended
  • Merge type: Merge commit

Who Can Merge

  • Feature/Task/Bugfix → dev: Any team member with required approval
  • Release → main: Tech lead approval recommended
  • Hotfix → main: Tech lead + one senior developer (emergency exception allowed)

Environment Management

Environment Mapping

main branch → prod environment
release/* → preprod environment  
dev branch → dev environment

Deployment Pipeline

developer → feature branch → dev → QA environment → release branch → preprod environment → main → prod environment

Environment Promotion Rules

  1. Dev Environment: Auto-deploy on merge to dev
  2. QA Environment: Manual trigger after dev testing
  3. Preprod Environment: Auto-deploy on release/* branch creation
  4. Prod Environment: Manual deployment after preprod validation

Quality Gates

  • QA → Stage: All QA tests must pass
  • Stage → Preprod: Performance tests + security scans
  • Preprod → Prod: Business approval + final smoke tests

Hotfix Process

When to Use Hotfixes

  • Critical production bugs affecting users
  • Security vulnerabilities
  • Data corruption issues
  • Service outages

Hotfix Workflow

  1. Create hotfix branch from main
bash
   git checkout main
   git pull origin main
   git checkout -b hotfix/AB#12345-critical-payment-fix
  1. Implement fix with minimal changes
  2. Test thoroughly in isolated environment
  3. Create PR to main with expedited review
  4. Deploy to production after approval
  5. Cherry-pick to dev to prevent regression
bash
   git checkout dev
   git cherry-pick <hotfix-commit-hash>

Emergency Process

For critical outages, tech lead can approve hotfix with single reviewer and deploy immediately, with post-deployment review required.


Release Management

Release Branch Creation

bash
# When ready for release
git checkout dev
git pull origin dev
git checkout -b release/v1.2.0

# Update changelogs, configuration files
git commit -m "Prepare release v1.2.0"
git push origin release/v1.2.0

Release Process

  1. Create release branch from dev
  2. Deploy to preprod for final testing
  3. Bug fixes go directly to release branch
  4. Merge to main when ready for production
  5. Tag release in main branch
  6. Merge back to dev for any release fixes

Best Practices Summary

Daily Practices

  • Pull latest dev before starting work
  • Create feature branches for all changes
  • Commit frequently with clear messages
  • Push branches regularly for backup
  • Link all commits to work items

Code Collaboration

  • Keep PRs focused and reasonably sized (<500 lines)
  • Respond to review comments promptly
  • Use draft PRs for work-in-progress discussions
  • Celebrate good code in reviews, not just critique

Branch Hygiene

  • Delete merged feature branches
  • Keep commit history clean with rebasing
  • Squash commits when merging to main
  • Regular cleanup of stale branches

Communication

  • Update work items with progress
  • Use PR descriptions to explain context
  • Tag relevant team members for reviews
  • Communicate breaking changes in team channels

Tools Integration

  • Configure Azure DevOps work item linking
  • Set up automated build validation
  • Use branch policies consistently
  • Enable notifications for PR activities
Content is user-generated and unverified.
    Azure DevOps Version Control & Collaboration Best Practices | Claude