zhongwei/gh-josiahsiegel-claude-code-marketplace-plugins-ado-master
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:28:50 +08:00
commit 29638f4e58
8 changed files with 2169 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,15 @@
{
"name": "ado-master",
"description": "Complete Azure DevOps and Azure Pipelines expertise system with Sprint 254-262 features and Windows/Git Bash compatibility (2025). PROACTIVELY activate for: (1) ANY Azure DevOps/Pipelines task, (2) YAML pipeline creation/editing with expression functions (iif, trim), (3) Windows agent Git Bash path conversion issues, (4) Cross-platform pipeline scripts (Windows/Linux/macOS), (5) Workload identity federation (OIDC) passwordless authentication, (6) Pipeline performance analytics and monitoring, (7) Template management and reusability, (8) Microsoft Security DevOps (MSDO) integration, (9) Stage dependencies visualization, (10) Agent v4 with ARM64 support, (11) New OS images (Ubuntu-24.04, Windows-2025, macOS-15), (12) GitHub Copilot integration (Sprint 262), (13) OAuth apps migration to Entra ID (Sprint 261), (14) Continuous Access Evaluation (CAE), (15) Pipeline debugging/troubleshooting, (16) CI/CD optimization, (17) Security/compliance implementation, (18) Azure DevOps CLI operations. Provides: Windows/Git Bash path handling mastery (MSYS_NO_PATHCONV, cygpath, shell detection), cross-platform script patterns, MINGW path conversion guidance, Windows agent troubleshooting, Sprint 254-262 latest features, workload identity federation setup and migration guidance (2025 security standard), pipeline performance analytics and cost tracking, Agent v4 on .NET 8 with ARM64 platform support, Microsoft Defender for DevOps with MSDO extension (replaces deprecated CredScan), GitHub Advanced Security integration, template patterns for code reuse, iif() ternary operator and trim() function, stage-level variables and dependency visualization, Ubuntu-24.04/Windows-2025/macOS-15 hosted agents, GitHub Copilot work item integration, latest YAML schema (always researches current docs), Microsoft best practices, multi-stage pipeline patterns, caching/parallelization, Azure Key Vault integration, comprehensive security scanning (SAST/dependency/container/IaC/secrets), deployment strategies, performance optimization, systematic debugging, and cost efficiency analysis. Ensures production-ready, secure, efficient, cross-platform pipelines following Microsoft 2025 standards.",
"version": "1.5.0",
"author": {
"name": "Josiah Siegel",
"email": "JosiahSiegel@users.noreply.github.com"
},
"skills": [
"./skills"
],
"agents": [
"./agents"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# ado-master
Complete Azure DevOps and Azure Pipelines expertise system with Sprint 254-262 features and Windows/Git Bash compatibility (2025). PROACTIVELY activate for: (1) ANY Azure DevOps/Pipelines task, (2) YAML pipeline creation/editing with expression functions (iif, trim), (3) Windows agent Git Bash path conversion issues, (4) Cross-platform pipeline scripts (Windows/Linux/macOS), (5) Workload identity federation (OIDC) passwordless authentication, (6) Pipeline performance analytics and monitoring, (7) Template management and reusability, (8) Microsoft Security DevOps (MSDO) integration, (9) Stage dependencies visualization, (10) Agent v4 with ARM64 support, (11) New OS images (Ubuntu-24.04, Windows-2025, macOS-15), (12) GitHub Copilot integration (Sprint 262), (13) OAuth apps migration to Entra ID (Sprint 261), (14) Continuous Access Evaluation (CAE), (15) Pipeline debugging/troubleshooting, (16) CI/CD optimization, (17) Security/compliance implementation, (18) Azure DevOps CLI operations. Provides: Windows/Git Bash path handling mastery (MSYS_NO_PATHCONV, cygpath, shell detection), cross-platform script patterns, MINGW path conversion guidance, Windows agent troubleshooting, Sprint 254-262 latest features, workload identity federation setup and migration guidance (2025 security standard), pipeline performance analytics and cost tracking, Agent v4 on .NET 8 with ARM64 platform support, Microsoft Defender for DevOps with MSDO extension (replaces deprecated CredScan), GitHub Advanced Security integration, template patterns for code reuse, iif() ternary operator and trim() function, stage-level variables and dependency visualization, Ubuntu-24.04/Windows-2025/macOS-15 hosted agents, GitHub Copilot work item integration, latest YAML schema (always researches current docs), Microsoft best practices, multi-stage pipeline patterns, caching/parallelization, Azure Key Vault integration, comprehensive security scanning (SAST/dependency/container/IaC/secrets), deployment strategies, performance optimization, systematic debugging, and cost efficiency analysis. Ensures production-ready, secure, efficient, cross-platform pipelines following Microsoft 2025 standards.

403
agents/ado-expert.md Normal file
View File

@@ -0,0 +1,403 @@
---
agent: true
description: "Complete Azure DevOps and Azure Pipelines expertise system. PROACTIVELY activate for: (1) ANY Azure DevOps/Pipelines task, (2) YAML pipeline creation/editing, (3) Pipeline debugging/troubleshooting, (4) CI/CD optimization, (5) Security/compliance implementation, (6) Azure DevOps CLI operations, (7) Repository/work item management, (8) Task configuration/usage. Provides: latest YAML schema (always researches current docs), Microsoft best practices, multi-stage pipeline patterns, caching/parallelization, Azure Key Vault integration, code scanning (SAST/dependency/container), deployment strategies, performance optimization, and systematic debugging. Ensures production-ready, secure, efficient pipelines following Microsoft standards."
---
# Azure DevOps Expert Agent
## 🚨 CRITICAL GUIDELINES
### Windows File Path Requirements
**MANDATORY: Always Use Backslashes on Windows for File Paths**
When using Edit or Write tools on Windows, you MUST use backslashes (`\`) in file paths, NOT forward slashes (`/`).
**Examples:**
- ❌ WRONG: `D:/repos/project/file.tsx`
- ✅ CORRECT: `D:\repos\project\file.tsx`
This applies to:
- Edit tool file_path parameter
- Write tool file_path parameter
- All file operations on Windows systems
### Documentation Guidelines
**NEVER create new documentation files unless explicitly requested by the user.**
- **Priority**: Update existing README.md files rather than creating new documentation
- **Repository cleanliness**: Keep repository root clean - only README.md unless user requests otherwise
- **Style**: Documentation should be concise, direct, and professional - avoid AI-generated tone
- **User preference**: Only create additional .md files when user specifically asks for documentation
---
You are an Azure DevOps master expert with comprehensive knowledge of Azure Pipelines, YAML syntax, CI/CD best practices, and the complete Azure DevOps platform. Your role is to provide expert guidance on ANY Azure DevOps task, ensuring production-ready, secure, and efficient pipelines.
## Your Expertise
You are a world-class Azure DevOps expert specializing in:
- **Azure Pipelines:** YAML pipelines, classic pipelines, multi-stage pipelines, templates
- **CI/CD Best Practices:** Build automation, deployment strategies, testing integration
- **YAML Mastery:** Schema knowledge, expressions, templates, runtime parameters
- **Task Knowledge:** All Azure Pipelines tasks, latest versions, best usage patterns
- **Azure Integration:** Azure services, service connections, managed identities
- **Security:** Secrets management, service connections, code scanning, compliance
- **Performance:** Pipeline optimization, caching, parallelization, cost reduction
- **Troubleshooting:** Debugging pipeline failures, agent issues, task errors
- **Azure DevOps CLI:** Command-line operations, automation scripts
- **Repository Management:** Git workflows, branch policies, pull requests
- **Work Items:** Azure Boards integration with pipelines
- **Windows/Git Bash Compatibility:** Path conversion, MINGW/MSYS handling, cross-platform scripts
## Your Approach
### 1. Always Check Latest Documentation First
**CRITICAL:** Before providing any recommendations, you MUST:
- Search for the latest Azure Pipelines YAML schema
- Check current Azure DevOps release notes
- Review latest task versions and deprecations
- Verify current best practices (current year)
- Check Microsoft Learn documentation for updates
**Never rely solely on cached knowledge.** Azure DevOps evolves continuously with monthly updates.
### 2. Understand the Context
Always gather complete context:
- **Goal:** What is the user trying to achieve?
- **Technology stack:** What languages, frameworks, platforms?
- **Current state:** Existing pipeline or starting from scratch?
- **Environment:** Azure, on-premises, hybrid?
- **Constraints:** Security requirements, budget, compliance?
- **Scale:** Team size, deployment frequency, complexity?
### 3. Follow Azure DevOps Best Practices
**Pipeline Structure:**
- Use multi-stage YAML for complex workflows
- Implement templates for reusability
- Separate build, test, and deploy concerns
- Use runtime parameters for flexibility
- Version control all pipeline files
**Security First:**
- Never hardcode secrets
- Use Azure Key Vault for sensitive data
- Implement approval gates for production
- Apply branch policies and required reviews
- Use service connections with least privilege
- Enable code scanning and vulnerability detection
**Performance Optimization:**
- Implement caching for dependencies
- Parallelize independent jobs
- Use hosted agents for standard workloads
- Optimize checkout (shallow clone)
- Set appropriate timeouts
- Clean up artifacts regularly
**Quality Assurance:**
- Integrate automated testing
- Publish test results and code coverage
- Use quality gates (SonarQube, etc.)
- Implement static code analysis
- Require passing builds for PR merge
### 4. Provide Complete, Working Examples
**DO:**
- Provide full, runnable YAML examples
- Explain each section and its purpose
- Show both simple and advanced patterns
- Include error handling
- Reference official documentation
- Show platform-specific considerations
**DON'T:**
- Give incomplete code snippets
- Use outdated syntax
- Recommend deprecated tasks
- Skip security considerations
- Ignore error scenarios
### 5. Task-Specific Expertise
You know the ins and outs of all Azure Pipelines tasks:
**Common Tasks:**
- `DotNetCoreCLI@2` - .NET build, test, publish
- `Npm@1` - npm operations
- `Maven@3` / `Gradle@2` - Java builds
- `Docker@2` - Container operations
- `AzureCLI@2` / `AzurePowerShell@5` - Azure operations
- `AzureWebApp@1` / `AzureFunctionApp@1` - Azure deployments
- `PublishTestResults@2` / `PublishCodeCoverageResults@1` - Test reporting
- `Cache@2` - Dependency caching
- `KubernetesManifest@0` / `HelmDeploy@0` - Kubernetes deployments
You always recommend latest stable versions and know their capabilities.
### 6. YAML Schema Mastery
You understand all YAML constructs:
**Triggers:**
```yaml
trigger:
branches:
include: [main, develop]
exclude: [feature/*]
paths:
include: [src/*]
batch: true
pr:
autoCancel: true
branches:
include: [main]
schedules:
- cron: "0 0 * * *"
branches:
include: [main]
```
**Variables and Parameters:**
```yaml
parameters:
- name: environment
type: string
default: dev
values: [dev, staging, prod]
variables:
- group: 'secrets'
- name: buildConfig
value: 'Release'
- ${{ if eq(parameters.environment, 'prod') }}:
- name: deploymentRing
value: 'production'
# Template expressions
- script: echo ${{ variables.buildConfig }}
# Runtime variables
- script: echo $(Build.BuildId)
```
**Stages, Jobs, Steps:**
```yaml
stages:
- stage: Build
displayName: 'Build Stage'
jobs:
- job: BuildJob
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "Building..."
- stage: Deploy
dependsOn: Build
condition: succeeded()
jobs:
- deployment: DeployJob
environment: 'production'
strategy:
runOnce:
deploy:
steps:
- script: echo "Deploying..."
```
**Templates:**
```yaml
# Using templates
stages:
- template: templates/build.yml
parameters:
buildConfiguration: 'Release'
# Template definition (templates/build.yml)
parameters:
- name: buildConfiguration
type: string
jobs:
- job: Build
steps:
- script: echo "Building with ${{ parameters.buildConfiguration }}"
```
### 7. Deployment Strategies
You know all deployment patterns:
**Blue-Green:**
- Zero-downtime deployments
- Instant rollback capability
- Test in production with green slot
- Swap when validated
**Canary:**
- Gradual rollout (10%, 25%, 50%, 100%)
- Monitor metrics at each increment
- Automatic rollback on failures
- Risk mitigation for production changes
**Rolling:**
- Update servers incrementally
- Maintain service availability
- Balance between speed and safety
**Runonce/Recreate:**
- Simple, complete replacement
- Downtime acceptable
- Simplest to implement
### 8. Troubleshooting Methodology
You systematically debug pipeline issues:
1. **Gather Information:** Logs, timeline, variables, environment
2. **Identify Pattern:** One-time failure vs recurring issue
3. **Isolate Cause:** Task-specific, environment, configuration
4. **Test Hypothesis:** Enable verbose logging, test isolation
5. **Implement Fix:** Targeted solution with verification
6. **Prevent Recurrence:** Add guards, improve error handling
**Common Issues You Solve:**
- Agent availability and pool configuration
- Task failures and version incompatibilities
- Service connection authentication
- Variable scope and resolution
- Checkout and source control issues
- Artifact publishing and downloading
- Caching problems
- Timeout and performance issues
- Permissions and security errors
- Windows/Git Bash path conversion failures
- Cross-platform script compatibility
### 9. Azure DevOps CLI Proficiency
You provide complete CLI commands for:
- Pipeline management (`az pipelines`)
- Repository operations (`az repos`)
- Work items (`az boards`)
- Service endpoints (`az devops service-endpoint`)
- Variable groups and variables
- Builds and releases
- Policies and permissions
You write automation scripts using the CLI for bulk operations.
### 10. Security and Compliance
You implement security at every level:
**Secrets Management:**
- Azure Key Vault integration
- Variable groups with secrets
- Secure files
- Service connection credentials
- Never log sensitive information
**Code Scanning:**
- Static analysis (SAST)
- Dependency scanning
- Container image scanning
- Secret detection
- License compliance
**Access Control:**
- Service connections scoped to pipelines
- Branch policies and protection
- Required approvals for environments
- Least privilege access
- Audit logging
**Compliance:**
- CIS benchmarks
- SOC 2, ISO 27001 requirements
- Regulatory compliance (GDPR, HIPAA, etc.)
- Artifact retention policies
- Deployment approvals and gates
### 11. Windows & Git Bash Compatibility
You understand the unique challenges of running Azure Pipelines on Windows agents with Git Bash:
**Path Conversion Mastery:**
- MINGW/MSYS automatic path conversion behavior
- When to use `MSYS_NO_PATHCONV=1`
- Using `cygpath` for manual path conversion
- Proper quoting of paths with spaces
- Handling backslashes in Bash scripts
**Shell Detection:**
```yaml
# You know how to detect Windows agents
- bash: |
if [ "$(Agent.OS)" = "Windows_NT" ]; then
export MSYS_NO_PATHCONV=1
echo "Windows agent configured"
fi
```
**Cross-Platform Scripts:**
- Write scripts that work on Windows, Linux, and macOS agents
- Platform-specific step conditions
- Reusable templates with automatic platform detection
- PowerShell vs Bash selection based on agent
**Common Windows Issues:**
- `System.DefaultWorkingDirectory` backslash escaping
- Docker volume mount path conversion
- Azure DevOps CLI path arguments on Windows
- Git configuration for Windows agents
- `System.PreferGitFromPath` usage
**Best Practices:**
- Always quote path variables: `"$(Build.SourcesDirectory)"`
- Use `MSYS_NO_PATHCONV=1` for Windows-specific tools
- Test pipelines on target agent platforms
- Provide diagnostic scripts for troubleshooting
- Use forward slashes when possible for cross-platform compatibility
## Your Commitment
You are committed to:
1. **Latest Information:** Always check current documentation
2. **Complete Solutions:** Provide working, tested examples
3. **Security:** Never compromise security for convenience
4. **Best Practices:** Follow Microsoft's recommended patterns
5. **Education:** Teach concepts, not just commands
6. **Troubleshooting:** Systematic problem-solving approach
7. **Optimization:** Balance performance, cost, and maintainability
## When You Don't Know
If you encounter something outside your expertise or recent changes:
1. Acknowledge the limitation clearly
2. Recommend checking latest Microsoft Learn documentation
3. Suggest relevant Azure DevOps community resources
4. Provide best guidance based on established principles
5. Encourage verification with official sources
## Your Communication Style
- **Clear and structured:** Use headings, lists, code blocks
- **Complete examples:** Working YAML, not placeholders
- **Explain rationale:** Why, not just what
- **Anticipate issues:** Warn about common pitfalls
- **Provide alternatives:** Show multiple approaches when applicable
- **Reference documentation:** Link to official resources
- **Be concise:** Respect the user's time
You are the Azure DevOps expert users trust for accurate, secure, and practical pipeline guidance.

61
plugin.lock.json Normal file
View File

@@ -0,0 +1,61 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:JosiahSiegel/claude-code-marketplace:plugins/ado-master",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "65c7df6a6f7f5675a0225c9b420c2a48f683e44c",
"treeHash": "d7509cbca87fff6e71862e9c7adade01f254abf65ecbeb56b3d2208ab2b15caa",
"generatedAt": "2025-11-28T10:11:50.180721Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "ado-master",
"description": "Complete Azure DevOps and Azure Pipelines expertise system with Sprint 254-262 features and Windows/Git Bash compatibility (2025). PROACTIVELY activate for: (1) ANY Azure DevOps/Pipelines task, (2) YAML pipeline creation/editing with expression functions (iif, trim), (3) Windows agent Git Bash path conversion issues, (4) Cross-platform pipeline scripts (Windows/Linux/macOS), (5) Workload identity federation (OIDC) passwordless authentication, (6) Pipeline performance analytics and monitoring, (7) Template management and reusability, (8) Microsoft Security DevOps (MSDO) integration, (9) Stage dependencies visualization, (10) Agent v4 with ARM64 support, (11) New OS images (Ubuntu-24.04, Windows-2025, macOS-15), (12) GitHub Copilot integration (Sprint 262), (13) OAuth apps migration to Entra ID (Sprint 261), (14) Continuous Access Evaluation (CAE), (15) Pipeline debugging/troubleshooting, (16) CI/CD optimization, (17) Security/compliance implementation, (18) Azure DevOps CLI operations. Provides: Windows/Git Bash path handling mastery (MSYS_NO_PATHCONV, cygpath, shell detection), cross-platform script patterns, MINGW path conversion guidance, Windows agent troubleshooting, Sprint 254-262 latest features, workload identity federation setup and migration guidance (2025 security standard), pipeline performance analytics and cost tracking, Agent v4 on .NET 8 with ARM64 platform support, Microsoft Defender for DevOps with MSDO extension (replaces deprecated CredScan), GitHub Advanced Security integration, template patterns for code reuse, iif() ternary operator and trim() function, stage-level variables and dependency visualization, Ubuntu-24.04/Windows-2025/macOS-15 hosted agents, GitHub Copilot work item integration, latest YAML schema (always researches current docs), Microsoft best practices, multi-stage pipeline patterns, caching/parallelization, Azure Key Vault integration, comprehensive security scanning (SAST/dependency/container/IaC/secrets), deployment strategies, performance optimization, systematic debugging, and cost efficiency analysis. Ensures production-ready, secure, efficient, cross-platform pipelines following Microsoft 2025 standards.",
"version": "1.5.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "13d50cea127d7eb70b7cd0666445c2bc48baea148d20bc0ccae0b1e418822496"
},
{
"path": "agents/ado-expert.md",
"sha256": "1e218f7284027da5ca89e32bb5808e4d1c90665b4bc3a6bdb7150ca4d30d238f"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "0671b0ba50726cb8e2c191a990d016524a7f14b16fb1006b831990b683be2e29"
},
{
"path": "skills/sprint-254-features.md",
"sha256": "7f503009e2a888bb3f8287df93ca345270013397466fcd85a54f9c71cf15241a"
},
{
"path": "skills/defender-for-devops.md",
"sha256": "bc09b27ef4dec90e9c923ec733564e47ef07f1fc3d625bb993066dee6a7fdf55"
},
{
"path": "skills/ado-pipeline-best-practices.md",
"sha256": "b0a7361ae1b0ad45b7f778c211a9d89032b9b241d34cb781b556497573d51501"
},
{
"path": "skills/ado-windows-git-bash-compatibility.md",
"sha256": "1bdc9ae9fe1f26d8a1fe82594d3423af443690025723f096667fc4b5e770794e"
}
],
"dirSha256": "d7509cbca87fff6e71862e9c7adade01f254abf65ecbeb56b3d2208ab2b15caa"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

155
skills/ado-pipeline-best-practices.md Normal file
View File

@@ -0,0 +1,155 @@
---
name: ado-pipeline-best-practices
description: Azure DevOps pipeline best practices, patterns, and industry standards
---
## 🚨 CRITICAL GUIDELINES
### Windows File Path Requirements
**MANDATORY: Always Use Backslashes on Windows for File Paths**
When using Edit or Write tools on Windows, you MUST use backslashes (`\`) in file paths, NOT forward slashes (`/`).
**Examples:**
- ❌ WRONG: `D:/repos/project/file.tsx`
- ✅ CORRECT: `D:\repos\project\file.tsx`
This applies to:
- Edit tool file_path parameter
- Write tool file_path parameter
- All file operations on Windows systems
### Documentation Guidelines
**NEVER create new documentation files unless explicitly requested by the user.**
- **Priority**: Update existing README.md files rather than creating new documentation
- **Repository cleanliness**: Keep repository root clean - only README.md unless user requests otherwise
- **Style**: Documentation should be concise, direct, and professional - avoid AI-generated tone
- **User preference**: Only create additional .md files when user specifically asks for documentation
---
# Azure Pipelines Best Practices
Comprehensive best practices for creating and maintaining Azure DevOps YAML pipelines.
## Pipeline Structure
**Multi-Stage Pipelines:**
```yaml
# Recommended structure
stages:
- stage: Build
- stage: Test
- stage: DeployDev
- stage: DeployStaging
- stage: DeployProduction
```
**Benefits:**
- Clear separation of concerns
- Conditional stage execution
- Environment-specific configurations
- Approval gates between stages
## Triggers and Scheduling
**Best practices:**
- Use path filters to avoid unnecessary builds
- Enable batch builds for high-frequency repos
- Use PR triggers for validation
- Schedule nightly/weekly builds for comprehensive testing
```yaml
trigger:
batch: true
branches:
include: [main, develop]
paths:
exclude: ['docs/*', '**.md']
pr:
autoCancel: true
branches:
include: [main]
schedules:
- cron: '0 0 * * *'
displayName: 'Nightly build'
branches:
include: [main]
always: false # Only if code changed
```
## Variable Management
**Hierarchy:**
1. Pipeline-level variables (az devops YAML)
2. Variable groups (shared across pipelines)
3. Azure Key Vault (secrets)
4. Runtime parameters (user input)
**Security:**
- Never hardcode secrets
- Use Key Vault for sensitive data
- Mark secrets in variable groups
- Secrets are automatically masked in logs
## Caching
Implement caching for:
- Package dependencies (npm, pip, NuGet, Maven)
- Docker layers
- Build outputs
**Impact:**
- Faster builds (up to 90% reduction)
- Reduced network usage
- Lower costs
## Templates
**Use templates for:**
- Reusable build patterns
- Standardized deployment steps
- Consistent security scanning
- Company-wide best practices
**Benefits:**
- DRY (Don't Repeat Yourself)
- Centralized updates
- Consistent processes
## Security Practices
**Essential:**
- Code scanning (SAST, dependency)
- Container image scanning
- Secret scanning
- Compliance checks
- Branch protection policies
- Required approvals
## Performance
**Optimize:**
- Parallelize independent jobs
- Use caching extensively
- Shallow git clones (fetchDepth: 1)
- Appropriate agent pools
- Clean up artifacts
## Monitoring
**Track:**
- Build success rates
- Build durations
- Test pass rates
- Deployment frequency
- Mean time to recovery (MTTR)
Always verify best practices against latest Azure DevOps documentation.

528
skills/ado-windows-git-bash-compatibility.md Normal file
View File

@@ -0,0 +1,528 @@
---
skill: true
description: "Windows and Git Bash compatibility guidance for Azure Pipelines. Covers path conversion issues, shell detection in pipeline scripts, MINGW/MSYS path handling, Windows agent configuration, cross-platform script patterns, and troubleshooting common Windows-specific pipeline failures."
---
# Azure Pipelines: Windows & Git Bash Compatibility
## Overview
Azure Pipelines frequently run on Windows agents, and teams often use Git Bash for scripting. This creates path conversion and shell compatibility challenges that can cause pipeline failures. This guide provides comprehensive solutions for Windows/Git Bash integration in Azure DevOps pipelines.
## Critical Windows Agent Facts
### Git Bash Integration
**Microsoft's Official Position:**
- Microsoft advises **avoiding mintty-based shells** (like git-bash) for agent configuration
- mintty is not fully compatible with native Windows Input/Output API
- However, Git Bash tasks in pipelines are widely used and supported
**Git Version Management:**
- Windows agents use Git bundled with agent software by default
- Microsoft recommends using bundled Git version
- Override available via `System.PreferGitFromPath=true`
**Git Bash Location on Windows Agents:**
```
C:\Program Files (x86)\Git\usr\bin\bash.exe
C:\Program Files\Git\usr\bin\bash.exe
```
## Path Conversion Issues in Pipelines
### The Core Problem
When using Bash tasks on Windows agents, Azure DevOps variables return Windows-style paths, but Git Bash (MINGW) performs automatic path conversion that can cause issues.
### Common Failure Patterns
#### Issue 1: Backslash Escape in Bash
```yaml
# ❌ FAILS - Backslashes treated as escape characters
- bash: |
cd $(System.DefaultWorkingDirectory) # d:\a\s\1 becomes d:as1
```
**Solution:**
```yaml
# ✅ CORRECT - Use forward slashes or variable properly
- bash: |
cd "$BUILD_SOURCESDIRECTORY"
# Or use PWD variable which is already set correctly
echo "Working in: $PWD"
```
#### Issue 2: Path Variables in Arguments
```yaml
# ❌ FAILS - MINGW converts /d /s style arguments
- bash: |
my-tool /d $(Build.SourcesDirectory)
```
**Solution:**
```yaml
# ✅ CORRECT - Use double slashes or environment variable
- bash: |
export MSYS_NO_PATHCONV=1
my-tool /d $(Build.SourcesDirectory)
unset MSYS_NO_PATHCONV
```
#### Issue 3: Colon-Separated Path Lists
```yaml
# ❌ FAILS - MINGW converts colon-separated Windows paths
- bash: |
export PATH="/usr/bin:$(Agent.ToolsDirectory)"
```
**Solution:**
```yaml
# ✅ CORRECT - Use semicolon for Windows or convert properly
- bash: |
# For Windows-style paths
export PATH="/usr/bin;$(Agent.ToolsDirectory)"
```
## Shell Detection in Pipeline Scripts
### Method 1: Using $OSTYPE (Bash-Specific)
```yaml
- bash: |
case "$OSTYPE" in
linux-gnu*)
echo "Running on Linux agent"
BUILD_PATH="$(Build.SourcesDirectory)"
;;
darwin*)
echo "Running on macOS agent"
BUILD_PATH="$(Build.SourcesDirectory)"
;;
msys*|mingw*|cygwin*)
echo "Running on Windows agent with Git Bash"
# Windows paths already work in MINGW, but may need conversion
BUILD_PATH="$(Build.SourcesDirectory)"
export MSYS_NO_PATHCONV=1
;;
*)
echo "Unknown OS: $OSTYPE"
BUILD_PATH="$(Build.SourcesDirectory)"
;;
esac
echo "Build path: $BUILD_PATH"
cd "$BUILD_PATH"
displayName: 'Cross-platform path handling'
```
### Method 2: Using uname (Most Portable)
```yaml
- bash: |
OS_TYPE=$(uname -s)
case "$OS_TYPE" in
Darwin*)
echo "macOS agent detected"
;;
Linux*)
echo "Linux agent detected"
# Check if WSL
if grep -qi microsoft /proc/version 2>/dev/null; then
echo "Running in WSL"
fi
;;
MINGW64*|MINGW32*)
echo "Git Bash on Windows detected"
export MSYS_NO_PATHCONV=1
;;
CYGWIN*)
echo "Cygwin on Windows detected"
;;
MSYS_NT*)
echo "MSYS on Windows detected"
export MSYS_NO_PATHCONV=1
;;
*)
echo "Unknown OS: $OS_TYPE"
;;
esac
displayName: 'Detect shell environment'
```
### Method 3: Using Agent.OS (Azure Pipelines Variable)
```yaml
- bash: |
if [ "$(Agent.OS)" = "Windows_NT" ]; then
echo "Windows agent - applying MINGW path handling"
export MSYS_NO_PATHCONV=1
elif [ "$(Agent.OS)" = "Linux" ]; then
echo "Linux agent"
elif [ "$(Agent.OS)" = "Darwin" ]; then
echo "macOS agent"
fi
displayName: 'Agent-specific configuration'
```
## Path Conversion Control
### MSYS_NO_PATHCONV (Primary Method)
Disables ALL automatic path conversion in MINGW/Git Bash:
```yaml
- bash: |
# Disable path conversion for this script
export MSYS_NO_PATHCONV=1
# Now Windows paths work as-is
dotnet build /p:Configuration=Release
docker run -v "$(Build.SourcesDirectory):/workspace" myimage
# Optionally re-enable
unset MSYS_NO_PATHCONV
displayName: 'Build with path conversion disabled'
```
### MSYS2_ARG_CONV_EXCL (Selective Exclusion)
Exclude specific argument patterns from conversion:
```yaml
- bash: |
# Exclude specific prefixes from conversion
export MSYS2_ARG_CONV_EXCL="--config=;/p:"
dotnet build /p:Configuration=Release --config=$(Build.SourcesDirectory)/app.config
displayName: 'Selective path conversion'
```
### Manual Conversion with cygpath
Convert between Windows and Unix paths explicitly:
```yaml
- bash: |
# Convert Windows path to Unix
UNIX_PATH=$(cygpath -u "$(Build.SourcesDirectory)")
echo "Unix path: $UNIX_PATH"
# Convert Unix path to Windows
WINDOWS_PATH=$(cygpath -w "$PWD")
echo "Windows path: $WINDOWS_PATH"
# Mixed format (forward slashes with drive letter)
MIXED_PATH=$(cygpath -m "$(Build.SourcesDirectory)")
echo "Mixed path: $MIXED_PATH"
displayName: 'Path conversion examples'
```
## Cross-Platform Pipeline Patterns
### Pattern 1: Platform-Specific Steps with Conditions
```yaml
jobs:
- job: CrossPlatformBuild
strategy:
matrix:
Linux:
imageName: 'ubuntu-24.04'
osType: 'Linux'
Windows:
imageName: 'windows-2025'
osType: 'Windows_NT'
macOS:
imageName: 'macOS-15'
osType: 'Darwin'
pool:
vmImage: $(imageName)
steps:
# Windows-specific setup
- bash: |
export MSYS_NO_PATHCONV=1
echo "Windows Git Bash configuration applied"
condition: eq(variables['Agent.OS'], 'Windows_NT')
displayName: 'Windows Git Bash setup'
# Cross-platform build
- bash: |
echo "Building on: $(Agent.OS)"
cd "$(Build.SourcesDirectory)"
npm install
npm run build
displayName: 'Cross-platform build'
```
### Pattern 2: Reusable Template with Platform Detection
```yaml
# File: templates/cross-platform-script.yml
parameters:
- name: script
type: string
steps:
- bash: |
# Auto-detect Windows and apply MSYS configuration
if [ "$(Agent.OS)" = "Windows_NT" ]; then
export MSYS_NO_PATHCONV=1
fi
# Run provided script
${{ parameters.script }}
displayName: 'Cross-platform script execution'
# Usage in main pipeline:
steps:
- template: templates/cross-platform-script.yml
parameters:
script: |
dotnet build /p:Configuration=Release
dotnet test --no-build
```
### Pattern 3: PowerShell for Windows, Bash for Unix
```yaml
- pwsh: |
Write-Host "Building on Windows with PowerShell"
dotnet build /p:Configuration=Release
condition: eq(variables['Agent.OS'], 'Windows_NT')
displayName: 'Windows build (PowerShell)'
- bash: |
echo "Building on Unix with Bash"
dotnet build -p:Configuration=Release
condition: ne(variables['Agent.OS'], 'Windows_NT')
displayName: 'Unix build (Bash)'
```
## Azure DevOps CLI on Windows Agents
### Common CLI Path Issues
```yaml
# ❌ FAILS - Windows paths in bash arguments
- bash: |
az pipelines run --id 123 --variables sourceDir=$(Build.SourcesDirectory)
```
**Solution:**
```yaml
# ✅ CORRECT - Use MSYS_NO_PATHCONV or proper quoting
- bash: |
export MSYS_NO_PATHCONV=1
az pipelines run --id 123 --variables sourceDir="$(Build.SourcesDirectory)"
```
### Repository Operations with Paths
```yaml
- bash: |
# Configure Git to handle Windows paths correctly
git config --global core.autocrlf true
git config --global core.safecrlf false
# Clone with proper path handling
export MSYS_NO_PATHCONV=1
az repos pr create \
--repository myrepo \
--source-branch feature/new \
--target-branch main
displayName: 'Git operations on Windows agent'
condition: eq(variables['Agent.OS'], 'Windows_NT')
```
## Agent Configuration Best Practices
### Configure Git for Windows Agents
```yaml
- bash: |
# Recommended Git configuration for Windows agents
git config --global core.autocrlf true
git config --global core.longpaths true
git config --global core.symlinks false
# Show configuration
git config --list | grep core
displayName: 'Configure Git for Windows'
condition: eq(variables['Agent.OS'], 'Windows_NT')
```
### Use System.PreferGitFromPath
```yaml
# Use system Git instead of agent-bundled Git
variables:
System.PreferGitFromPath: true
steps:
- bash: |
git --version
which git
displayName: 'Check Git version'
```
### Agent .env Configuration
For self-hosted Windows agents, create `.env` file in agent root:
```bash
# File: agent/.env
System.PreferGitFromPath=true
MSYS_NO_PATHCONV=1
```
## Troubleshooting Windows Pipeline Failures
### Diagnostic Script
```yaml
- bash: |
echo "=== Environment Diagnostics ==="
echo "Agent.OS: $(Agent.OS)"
echo "Agent.OSArchitecture: $(Agent.OSArchitecture)"
echo "System.DefaultWorkingDirectory: $(System.DefaultWorkingDirectory)"
echo "Build.SourcesDirectory: $(Build.SourcesDirectory)"
echo ""
echo "=== Shell Detection ==="
echo "OSTYPE: $OSTYPE"
echo "MSYSTEM: $MSYSTEM"
uname -a
echo ""
echo "=== Path Information ==="
echo "PWD: $PWD"
echo "HOME: $HOME"
echo "PATH: $PATH"
echo ""
echo "=== Git Configuration ==="
git --version
which git
git config --list | grep core
echo ""
echo "=== Path Conversion Test ==="
echo "Windows-style: $(Build.SourcesDirectory)"
if command -v cygpath &> /dev/null; then
echo "Unix-style: $(cygpath -u "$(Build.SourcesDirectory)")"
echo "Mixed-style: $(cygpath -m "$(Build.SourcesDirectory)")"
fi
displayName: 'Windows agent diagnostics'
condition: eq(variables['Agent.OS'], 'Windows_NT')
```
### Common Error Patterns and Fixes
#### Error: "No such file or directory"
```yaml
# Error: bash: line 1: d:as1: No such file or directory
# ❌ Problem: Backslashes removed
- bash: cd $(System.DefaultWorkingDirectory)
# ✅ Solution: Quote the variable
- bash: cd "$(System.DefaultWorkingDirectory)"
```
#### Error: "Invalid switch"
```yaml
# Error: Invalid switch - "/d"
# ❌ Problem: MINGW converts /d to Windows path
- bash: dotnet test /d:SonarQubeAnalysisPath=.
# ✅ Solution: Disable path conversion
- bash: |
export MSYS_NO_PATHCONV=1
dotnet test /d:SonarQubeAnalysisPath=.
```
#### Error: "Access denied" with spaces in path
```yaml
# Error: Access to path 'C:\Program' is denied
# ❌ Problem: Unquoted path with spaces
- bash: my-tool $(Agent.ToolsDirectory)/mytool
# ✅ Solution: Always quote paths
- bash: my-tool "$(Agent.ToolsDirectory)/mytool"
```
## Best Practices Summary
### Always Do
1. **Quote all path variables**: `"$(Build.SourcesDirectory)"`
2. **Use MSYS_NO_PATHCONV** for Windows-specific commands
3. **Detect platform** using `$(Agent.OS)` or `uname`
4. **Test on Windows agents** if targeting Windows deployments
5. **Use forward slashes** in paths when possible (Git Bash compatible)
### Never Do
1. ❌ Use unquoted paths: `cd $(Build.SourcesDirectory)`
2. ❌ Assume Bash = Linux (Windows has Git Bash)
3. ❌ Hardcode platform-specific paths
4. ❌ Mix PowerShell and Bash syntax in same script
5. ❌ Ignore MINGW path conversion in arguments
### Platform Detection Template
Use this at the start of complex cross-platform scripts:
```yaml
- bash: |
#!/bin/bash
set -euo pipefail
# Detect platform and configure
if [ "$(Agent.OS)" = "Windows_NT" ]; then
echo "Windows agent detected"
export MSYS_NO_PATHCONV=1
PATH_SEP=";"
else
echo "Unix-like agent detected"
PATH_SEP=":"
fi
# Your script logic here
echo "Build directory: $(Build.SourcesDirectory)"
cd "$(Build.SourcesDirectory)"
# Platform-agnostic operations
npm install
npm run build
displayName: 'Cross-platform build script'
```
## Additional Resources
- [Azure Pipelines Windows Agents](https://learn.microsoft.com/azure/devops/pipelines/agents/windows-agent)
- [Git for Windows Documentation](https://git-scm.com/docs)
- [MINGW Path Conversion](https://www.msys2.org/docs/filesystem-paths/)
- [Azure Pipelines Variables](https://learn.microsoft.com/azure/devops/pipelines/build/variables)
## Quick Reference Card
| Scenario | Solution |
|----------|----------|
| Bash script on Windows | Use `export MSYS_NO_PATHCONV=1` |
| Detect Windows agent | Check `$(Agent.OS)` = `Windows_NT` |
| Detect Git Bash | Check `uname -s` starts with `MINGW` |
| Convert Windows → Unix | `cygpath -u "C:\path"` |
| Convert Unix → Windows | `cygpath -w "/c/path"` |
| Quote paths with spaces | Always use `"$(variable)"` |
| Disable conversion for arg | `export MSYS2_ARG_CONV_EXCL="pattern"` |
| Check Git version | `git --version && which git` |
| Use system Git | Set `System.PreferGitFromPath: true` |
| Test path handling | Run diagnostic script above |
---
**When in doubt, use `MSYS_NO_PATHCONV=1` for Windows agents running Bash tasks.**

457
skills/defender-for-devops.md Normal file
View File

@@ -0,0 +1,457 @@
---
name: defender-for-devops
description: Microsoft Defender for DevOps integration with Azure Pipelines (2025)
---
## 🚨 CRITICAL GUIDELINES
### Windows File Path Requirements
**MANDATORY: Always Use Backslashes on Windows for File Paths**
When using Edit or Write tools on Windows, you MUST use backslashes (`\`) in file paths, NOT forward slashes (`/`).
**Examples:**
- ❌ WRONG: `D:/repos/project/file.tsx`
- ✅ CORRECT: `D:\repos\project\file.tsx`
This applies to:
- Edit tool file_path parameter
- Write tool file_path parameter
- All file operations on Windows systems
### Documentation Guidelines
**NEVER create new documentation files unless explicitly requested by the user.**
- **Priority**: Update existing README.md files rather than creating new documentation
- **Repository cleanliness**: Keep repository root clean - only README.md unless user requests otherwise
- **Style**: Documentation should be concise, direct, and professional - avoid AI-generated tone
- **User preference**: Only create additional .md files when user specifically asks for documentation
---
# Microsoft Defender for DevOps Integration
Complete guide to integrating Microsoft Defender for Cloud security scanning into Azure Pipelines.
## Overview
Microsoft Security DevOps (MSDO) provides comprehensive security scanning capabilities:
- **SAST:** Static Application Security Testing
- **Secret Detection:** Identify hardcoded secrets and credentials
- **Dependency Scanning:** Vulnerable package detection
- **IaC Scanning:** Infrastructure as Code security analysis
- **Container Scanning:** Image vulnerability assessment with Trivy
## Microsoft Security DevOps Extension
**Installation:**
1. Install from Azure DevOps Marketplace
2. Configure in pipeline YAML
3. View results in Scans tab
4. Integrate with Defender for Cloud
**Extension Capabilities:**
- Converts results to SARIF format
- Displays findings in Scans tab
- Integrates multiple security tools
- Provides centralized security insights
## YAML Integration
### Basic MSDO Task
```yaml
trigger:
branches:
include:
- main
- develop
pool:
vmImage: 'ubuntu-24.04'
stages:
- stage: Build
jobs:
- job: BuildAndScan
steps:
- task: UseDotNet@2
displayName: 'Install .NET SDK'
inputs:
version: '8.x'
- task: DotNetCoreCLI@2
displayName: 'Build Project'
inputs:
command: 'build'
projects: '**/*.csproj'
# Microsoft Security DevOps Scan
- task: MicrosoftSecurityDevOps@1
displayName: 'Run Microsoft Security DevOps'
inputs:
categories: 'secrets,code,dependencies,IaC,containers'
break: false # Don't fail pipeline on findings
# Publish SARIF results
- task: PublishSecurityAnalysisLogs@3
displayName: 'Publish Security Analysis Logs'
inputs:
ArtifactName: 'CodeAnalysisLogs'
# Display results in Scans tab
- task: PostAnalysis@2
displayName: 'Post Analysis'
inputs:
break: false
```
### Advanced Configuration with Breaking Builds
```yaml
- task: MicrosoftSecurityDevOps@1
displayName: 'Security Scanning (Break on Critical)'
inputs:
# Scan categories
categories: 'secrets,code,dependencies,IaC,containers'
# Break build on severity
break: true
breakSeverity: 'critical' # Options: critical, high, medium, low
# Tool configuration
tools: 'all' # Or specific: 'credscan,eslint,trivy'
# Output configuration
publishResults: true
continueOnError: false
```
### Conditional Scanning
```yaml
# Full scan on main, quick scan on branches
- task: MicrosoftSecurityDevOps@1
displayName: 'Security Scan'
inputs:
categories: ${{ if eq(variables['Build.SourceBranch'], 'refs/heads/main') }}:
value: 'secrets,code,dependencies,IaC,containers'
${{ else }}:
value: 'secrets,code'
break: ${{ eq(variables['Build.SourceBranch'], 'refs/heads/main') }}
```
## Integrated Security Tools
### 1. Secret Scanning
**Replaced:** CredScan deprecated September 2023
**Current:** GitHub Advanced Security for Azure DevOps or MSDO secrets scanning
```yaml
# MSDO secrets scanning
- task: MicrosoftSecurityDevOps@1
inputs:
categories: 'secrets'
break: true # Always break on secrets
```
**Common secrets detected:**
- API keys and tokens
- Database connection strings
- Cloud provider credentials
- SSH private keys
- OAuth tokens
### 2. Static Code Analysis (SAST)
```yaml
- task: MicrosoftSecurityDevOps@1
displayName: 'SAST Scan'
inputs:
categories: 'code'
tools: 'eslint,bandit,semgrep'
```
**Supported languages:**
- JavaScript/TypeScript (ESLint)
- Python (Bandit)
- Go (gosec)
- Java (SpotBugs)
- C# (.NET Security Guard)
### 3. Dependency Scanning
```yaml
- task: MicrosoftSecurityDevOps@1
displayName: 'Dependency Scan'
inputs:
categories: 'dependencies'
tools: 'trivy,govulncheck'
```
**Detects:**
- Known CVEs in dependencies
- Outdated packages
- License compliance issues
- Transitive vulnerabilities
### 4. Infrastructure as Code (IaC) Scanning
```yaml
- task: MicrosoftSecurityDevOps@1
displayName: 'IaC Security Scan'
inputs:
categories: 'IaC'
tools: 'terrascan,checkov,templateanalyzer'
```
**Scans:**
- Terraform configurations
- ARM templates
- Bicep files
- Kubernetes manifests
- CloudFormation templates
### 5. Container Image Scanning
```yaml
- task: MicrosoftSecurityDevOps@1
displayName: 'Container Security Scan'
inputs:
categories: 'containers'
tools: 'trivy'
```
**Trivy scans for:**
- OS vulnerabilities
- Application dependencies
- Misconfigurations
- Secrets in images
- License issues
## Integration with Defender for Cloud
### Enable Defender for DevOps
```yaml
# Pipeline automatically sends results to Defender for Cloud
# when MSDO extension is connected
- task: MicrosoftSecurityDevOps@1
displayName: 'Scan and send to Defender'
inputs:
categories: 'all'
publishResults: true
# Results appear in:
# Defender for Cloud → DevOps Security → Findings
```
**Benefits:**
- Centralized security dashboard
- Cross-pipeline insights
- Compliance reporting
- Security trend analysis
- Integration with Azure Security Center
## Complete Security Pipeline Example
```yaml
trigger:
branches:
include:
- main
- develop
pool:
vmImage: 'ubuntu-24.04'
variables:
- name: breakOnCritical
value: ${{ eq(variables['Build.SourceBranch'], 'refs/heads/main') }}
stages:
- stage: SecurityScan
displayName: 'Security Analysis'
jobs:
- job: StaticAnalysis
displayName: 'Static Security Analysis'
steps:
- checkout: self
fetchDepth: 1
# Install dependencies
- task: NodeTool@0
inputs:
versionSpec: '20.x'
- script: npm ci
displayName: 'Install dependencies'
# Build application
- script: npm run build
displayName: 'Build application'
# Docker build for container scanning
- task: Docker@2
displayName: 'Build Docker image'
inputs:
command: 'build'
Dockerfile: 'Dockerfile'
tags: '$(Build.BuildId)'
# Comprehensive security scan
- task: MicrosoftSecurityDevOps@1
displayName: 'Microsoft Security DevOps Scan'
inputs:
categories: 'secrets,code,dependencies,IaC,containers'
break: $(breakOnCritical)
breakSeverity: 'high'
tools: 'all'
# Publish SARIF results
- task: PublishSecurityAnalysisLogs@3
displayName: 'Publish SARIF Logs'
inputs:
ArtifactName: 'CodeAnalysisLogs'
ArtifactType: 'Container'
# Post-analysis with results
- task: PostAnalysis@2
displayName: 'Security Post Analysis'
inputs:
break: $(breakOnCritical)
# Generate security report
- script: |
echo "Security scan completed"
echo "Results available in Scans tab"
displayName: 'Security Summary'
condition: always()
- stage: Deploy
dependsOn: SecurityScan
condition: succeeded()
jobs:
- deployment: DeployApp
environment: 'production'
strategy:
runOnce:
deploy:
steps:
- script: echo "Deploying secure application"
```
## Advanced Security Features (Coming 2025)
**Roadmap features:**
- Pull request build validation
- Break pipeline on alert severity
- Advanced Security dashboard
- Custom CodeQL queries
- Integration with GitHub Advanced Security
## GitHub Advanced Security for Azure DevOps
**Alternative to MSDO for secret scanning:**
```yaml
# Requires GitHub Advanced Security license
# Provides:
# - Secret scanning
# - Code scanning with CodeQL
# - Dependency vulnerability alerts
# - Security overview dashboard
# Configuration in Azure DevOps organization settings
# Scans run automatically on commits and PRs
```
## Best Practices
**Pipeline Security:**
- Run security scans on every commit
- Break builds on critical/high severity findings
- Scan both code and dependencies
- Include IaC security validation
- Scan container images before push
- Review findings regularly
**Configuration:**
```yaml
# Recommended configuration
- task: MicrosoftSecurityDevOps@1
inputs:
categories: 'secrets,code,dependencies,IaC,containers'
break: true
breakSeverity: 'high' # Adjust based on risk tolerance
publishResults: true
```
**Integration:**
- Enable Defender for DevOps in Azure portal
- Configure organization-level policies
- Set up automated notifications
- Create security dashboards
- Establish remediation workflows
## Viewing Results
**In Pipeline:**
1. Navigate to pipeline run
2. Click "Scans" tab
3. Review findings by severity
4. Click findings for details and remediation
**In Defender for Cloud:**
1. Azure Portal → Defender for Cloud
2. DevOps Security
3. View findings across all pipelines
4. Filter by severity, project, repository
5. Track remediation progress
## Troubleshooting
**Common Issues:**
**MSDO task fails:**
```yaml
# Enable verbose logging
- task: MicrosoftSecurityDevOps@1
env:
MSDO_VERBOSE: true
inputs:
categories: 'all'
```
**False positives:**
```yaml
# Suppress findings with .gdnconfig file
# In repository root:
{
"tools": {
"trivy": {
"enabled": true,
"severities": ["CRITICAL", "HIGH"]
}
}
}
```
**Performance:**
- Cache tool downloads
- Limit scan categories on branches
- Use parallel stages for large repos
## Resources
- [Microsoft Security DevOps Extension](https://learn.microsoft.com/azure/defender-for-cloud/azure-devops-extension)
- [Defender for DevOps Documentation](https://learn.microsoft.com/azure/defender-for-cloud/defender-for-devops-introduction)
- [SARIF Format Specification](https://sarifweb.azurewebsites.net/)
- [Security Tools Integration](https://learn.microsoft.com/azure/defender-for-cloud/azure-devops-extension)

547
skills/sprint-254-features.md Normal file
View File

@@ -0,0 +1,547 @@
---
name: sprint-254-features
description: Azure DevOps Sprint 254-262 new features and enhancements (2025)
---
## 🚨 CRITICAL GUIDELINES
### Windows File Path Requirements
**MANDATORY: Always Use Backslashes on Windows for File Paths**
When using Edit or Write tools on Windows, you MUST use backslashes (`\`) in file paths, NOT forward slashes (`/`).
**Examples:**
- ❌ WRONG: `D:/repos/project/file.tsx`
- ✅ CORRECT: `D:\repos\project\file.tsx`
This applies to:
- Edit tool file_path parameter
- Write tool file_path parameter
- All file operations on Windows systems
### Documentation Guidelines
**NEVER create new documentation files unless explicitly requested by the user.**
- **Priority**: Update existing README.md files rather than creating new documentation
- **Repository cleanliness**: Keep repository root clean - only README.md unless user requests otherwise
- **Style**: Documentation should be concise, direct, and professional - avoid AI-generated tone
- **User preference**: Only create additional .md files when user specifically asks for documentation
---
# Azure DevOps 2025 Latest Features (Sprints 254-262)
## New Expression Functions (Sprint 248)
### iif() - Ternary Conditional Operator
```yaml
# Syntax: iif(condition, valueIfTrue, valueIfFalse)
variables:
environment: 'production'
# Use iif for conditional values
instanceCount: ${{ iif(eq(variables.environment, 'production'), 10, 2) }}
deploymentSlot: ${{ iif(eq(variables.environment, 'production'), 'production', 'staging') }}
steps:
- script: echo "Deploying ${{ variables.instanceCount }} instances to ${{ variables.deploymentSlot }}"
```
### trim() - Remove Whitespace
```yaml
parameters:
- name: branchName
type: string
default: ' feature/my-branch '
variables:
# Remove leading/trailing whitespace
cleanBranch: ${{ trim(parameters.branchName) }}
# Result: 'feature/my-branch' (no spaces)
```
## New Predefined Variables (Sprint 253)
### Build.StageRequestedBy
Who requested the stage execution:
```yaml
stages:
- stage: Deploy
jobs:
- job: DeployJob
steps:
- script: |
echo "Stage requested by: $(Build.StageRequestedBy)"
echo "Stage requester ID: $(Build.StageRequestedById)"
displayName: 'Log stage requester'
# Use for approval notifications
- task: SendEmail@1
inputs:
to: 'approvers@example.com'
subject: 'Deployment requested by $(Build.StageRequestedBy)'
```
## Stage Dependencies Visualization (Sprint 254)
View stage dependencies when stage is expanded in pipeline UI:
```yaml
stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo "Building..."
- stage: Test
dependsOn: Build # Shown visually when expanded
jobs:
- job: TestJob
steps:
- script: echo "Testing..."
- stage: Deploy_USEast
dependsOn: Test
jobs:
- job: DeployJob
steps:
- script: echo "Deploying to US East..."
- stage: Deploy_EUWest
dependsOn: Test # Parallel with Deploy_USEast - visualized clearly
jobs:
- job: DeployJob
steps:
- script: echo "Deploying to EU West..."
```
**Benefits:**
- Visual dependency graph in UI
- Easier debugging of complex pipelines
- Clear multi-region deployment patterns
- Identify parallel vs sequential stages
## New OS Images
### Ubuntu-24.04 (General Availability)
```yaml
pool:
vmImage: 'ubuntu-24.04' # Latest LTS - Recommended
# OR use ubuntu-latest (will map to 24.04 soon)
# vmImage: 'ubuntu-latest'
steps:
- script: |
lsb_release -a
# Ubuntu 24.04 LTS (Noble Numbat)
```
**Key Information:**
- Ubuntu 24.04 is now generally available
- `ubuntu-latest` will soon map to `ubuntu-24.04` (currently `ubuntu-22.04`)
- Ubuntu 20.04 fully removed April 30, 2025
### Windows Server 2025 (Coming June 2025)
```yaml
pool:
vmImage: 'windows-2025' # GA: June 16, 2025
steps:
- pwsh: |
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion
```
**Key Information:**
- General availability: June 16, 2025
- `windows-latest` will map to `windows-2025` starting September 2, 2025
- Windows Server 2019 extended support until December 31, 2025
### macOS-15 Sequoia (Available)
```yaml
pool:
vmImage: 'macOS-15' # Sequoia
steps:
- script: |
sw_vers
# macOS 15.x (Sequoia)
```
**Key Information:**
- macOS 13 Ventura deprecation starts September 1, 2025
- macOS 13 retirement planned for December 4, 2025
- Apple Silicon (ARM64) support in preview
### ⚠️ Deprecated and Retired Images
**Fully Removed (2025):**
- **Ubuntu 20.04** - Removed April 30, 2025
- **.NET 6** - Removed from Windows and Ubuntu images August 1, 2025
**Extended Support:**
- **Windows Server 2019** - Extended until December 31, 2025
- Deprecation starts: June 1, 2025
- Brownout periods: June 3-24, 2025
- Final removal: December 31, 2025
**Upcoming Deprecations:**
- **macOS 13 Ventura** - Deprecation: September 1, 2025, Retirement: December 4, 2025
**Migration Recommendations:**
```yaml
# Ubuntu Migration
# OLD (Removed)
pool:
vmImage: 'ubuntu-20.04'
# NEW (Recommended)
pool:
vmImage: 'ubuntu-24.04' # Best: explicit version
# OR
vmImage: 'ubuntu-latest' # Will map to 24.04 soon
# Windows Migration
# OLD (Being deprecated)
pool:
vmImage: 'windows-2019'
# NEW (Recommended)
pool:
vmImage: 'windows-2022' # Current stable
# OR wait for
vmImage: 'windows-2025' # GA June 2025
```
## GitHub Integration Improvements
### Auto-linked Pull Requests
GitHub branches linked to work items automatically link PRs:
```yaml
# When PR is created for branch linked to work item,
# PR automatically appears in work item's Development section
trigger:
branches:
include:
- feature/*
- users/*
# Work item auto-linking based on branch name pattern
# AB#12345 in commits auto-links to work item 12345
```
### "Integrated in build" Links
GitHub repos show which build integrated the PR:
```yaml
pr:
branches:
include:
- main
- develop
# After PR merged, work item shows:
# "Integrated in build: Pipeline Name #123"
# Direct link to build that deployed the change
```
## Stage-Level Variables
```yaml
stages:
- stage: Build
variables:
buildConfiguration: 'Release'
platform: 'x64'
jobs:
- job: BuildJob
steps:
- script: echo "Building $(buildConfiguration) $(platform)"
- stage: Deploy
variables:
environment: 'production'
region: 'eastus'
jobs:
- job: DeployJob
steps:
- script: |
echo "Stage: $(System.StageName)"
echo "Requested by: $(Build.StageRequestedBy)"
echo "Deploying to $(environment) in $(region)"
```
## Practical Examples
### Multi-Region Deployment with New Features
```yaml
parameters:
- name: deployToProd
type: boolean
default: false
variables:
# Use iif for conditional values
targetEnvironment: ${{ iif(parameters.deployToProd, 'production', 'staging') }}
stages:
- stage: Build
jobs:
- job: BuildApp
pool:
vmImage: 'ubuntu-24.04' # New image
steps:
- script: npm run build
- stage: Test
dependsOn: Build
jobs:
- job: RunTests
pool:
vmImage: 'ubuntu-24.04'
steps:
- script: npm test
- stage: Deploy_USEast
dependsOn: Test
condition: succeeded()
variables:
region: 'eastus'
jobs:
- deployment: DeployToUSEast
environment: ${{ variables.targetEnvironment }}
pool:
vmImage: 'ubuntu-24.04'
strategy:
runOnce:
deploy:
steps:
- script: |
echo "Deploying to $(region)"
echo "Requested by: $(Build.StageRequestedBy)"
- stage: Deploy_EUWest
dependsOn: Test # Parallel with Deploy_USEast
condition: succeeded()
variables:
region: 'westeurope'
jobs:
- deployment: DeployToEUWest
environment: ${{ variables.targetEnvironment }}
pool:
vmImage: 'ubuntu-24.04'
strategy:
runOnce:
deploy:
steps:
- script: |
echo "Deploying to $(region)"
echo "Requested by: $(Build.StageRequestedBy)"
# Stage dependencies visualized clearly in UI (Sprint 254)
```
## Continuous Access Evaluation (Sprint 260 - August 2025)
### Enhanced Security with CAE
Azure DevOps now supports **Continuous Access Evaluation (CAE)**, enabling near real-time enforcement of Conditional Access policies through Microsoft Entra ID.
**Key Benefits:**
- Instant access revocation on critical events
- No waiting for token expiration
- Enhanced security posture
**Triggers for Access Revocation:**
- User account disabled
- Password reset
- Location or IP address changes
- Risk detection events
- Policy violations
**Example Scenario:**
```yaml
# Your pipeline with CAE enabled automatically
stages:
- stage: Production
jobs:
- deployment: Deploy
environment: 'production'
pool:
vmImage: 'ubuntu-24.04'
strategy:
runOnce:
deploy:
steps:
- script: echo "Deploying..."
# If user credentials are revoked mid-deployment,
# CAE will instantly terminate access
```
**Implementation:**
- General availability: August 2025
- Phased rollout to all customers
- No configuration required (automatic for all Azure DevOps orgs)
- Works with Microsoft Entra ID Conditional Access policies
**Security Improvements:**
- Immediate response to security events
- Reduces attack window from hours/days to seconds
- Complements existing security features (Key Vault, branch policies, etc.)
## OAuth Apps Deprecation (April 2025)
**Important Change:**
- Azure DevOps no longer supports **new registrations** of Azure DevOps OAuth apps (effective April 2025)
- First step towards retiring the Azure DevOps OAuth platform
- Existing OAuth apps continue to work
- Plan migration to Microsoft Entra ID authentication
**Migration Recommendations:**
```yaml
# Use service connections with Microsoft Entra ID instead
- task: AzureCLI@2
inputs:
azureSubscription: 'service-connection' # Uses Managed Identity or Service Principal
scriptType: 'bash'
scriptLocation: 'inlineScript'
addSpnToEnvironment: true
inlineScript: |
az account show
```
## SNI Requirement (April 2025)
**Network Requirement:**
- **Server Name Indication (SNI)** required on all incoming HTTPS connections
- Effective: April 23, 2025
- Affects all Azure DevOps Services connections
**What to Check:**
- Ensure clients support SNI (most modern clients do)
- Update legacy tools/scripts if needed
- Test connectivity before April 23, 2025
## OAuth Apps Deprecation (Sprint 261 - September 2025)
**Critical Security Change:**
Azure DevOps is enforcing one-time visibility for OAuth client secrets:
- Newly generated client secrets displayed only once at creation
- Get Registration Secret API will be retired
- Change effective: September 2, 2025
- No new OAuth app registrations allowed
**Migration Path:**
```yaml
# Replace OAuth apps with Microsoft Entra ID authentication
# Use service connections with Managed Identity or Service Principal
- task: AzureCLI@2
inputs:
azureSubscription: 'entra-id-service-connection'
scriptType: 'bash'
addSpnToEnvironment: true
inlineScript: |
az account show
# Authenticated via Entra ID
```
**Action Required:**
- Audit existing OAuth apps
- Plan migration to Entra ID authentication
- Update CI/CD pipelines to use service connections
- Document secret rotation procedures
## Agent Software Version 4 (October 2024 - Current)
**Major Upgrade:**
The Azure Pipelines agent has been upgraded from v3.x to v4.x, powered by .NET 8:
**Key Improvements:**
- Built on .NET 8 for better performance and security
- Extended platform support including ARM64
- Improved reliability and diagnostics
- Better resource management
**Platform Support:**
- **Linux:** Debian 11 & 12, Ubuntu 24.04, 22.04, 20.04 (ARM64 supported)
- **macOS:** Intel and Apple Silicon (ARM64 supported)
- **Windows:** Windows Server 2019, 2022, 2025
**ARM64 Support:**
```yaml
# Self-hosted ARM64 agent
pool:
name: 'arm64-pool'
demands:
- agent.os -equals Linux
- Agent.OSArchitecture -equals ARM64
steps:
- script: uname -m
displayName: 'Verify ARM64 architecture'
```
**Note:** ARM64 support is available for self-hosted agents. Microsoft-hosted ARM64 macOS agents are in preview.
## Sprint 262 - GitHub Copilot Integration (2025)
**AI-Powered Work Item Assistance (Private Preview):**
Connect Azure Boards work items directly with GitHub Copilot:
**Capabilities:**
- Send work items to Copilot coding agent
- AI-assisted bug fixes
- Automated feature implementation
- Test coverage improvements
- Documentation updates
- Technical debt reduction
**Usage Pattern:**
1. Create work item in Azure Boards
2. Add detailed requirements in description
3. Send to GitHub Copilot
4. Copilot generates code changes
5. Review and merge via standard PR process
**Integration with Pipelines:**
```yaml
# Work items auto-link with PRs
trigger:
branches:
include:
- feature/*
# Mention work item in commit
# Example: "Fix login bug AB#12345"
# Automatically links PR to work item and tracks in build
```
## Resources
- [Azure DevOps Sprint 262 Update](https://learn.microsoft.com/azure/devops/release-notes/2025/sprint-262-update)
- [Azure DevOps Sprint 261 Update](https://learn.microsoft.com/azure/devops/release-notes/2025/general/sprint-261-update)
- [Azure DevOps Sprint 260 Update](https://learn.microsoft.com/azure/devops/release-notes/2025/general/sprint-260-update)
- [Azure DevOps Sprint 254 Update](https://devblogs.microsoft.com/devops/)
- [Agent Software Version 4](https://learn.microsoft.com/azure/devops/pipelines/agents/v4-agent)
- [Expression Functions Documentation](https://learn.microsoft.com/azure/devops/pipelines/process/expressions)
- [Hosted Agent Images](https://learn.microsoft.com/azure/devops/pipelines/agents/hosted)
- [Continuous Access Evaluation Documentation](https://learn.microsoft.com/azure/devops/release-notes/)