neo-azure-pipelines

name	neo-azure-pipelines
description	Use this skill when the user asks to create, review, debug, or modernize Azure Pipelines YAML for CI/CD, especially .NET builds, Azure App Service deploys, or IIS/on-premises deploys. Prefer bundled templates and verify task syntax against Microsoft docs when version-specific accuracy matters.
compatibility	Supports .NET 6.0 up to .NET 10.0.
metadata	{"version":"1.0.0","category":"DevOps"}

Azure Pipeline Script Design Specifications

Perceive

1. When version-specific syntax or task versions matter, verify them against https://learn.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops; if browsing is unavailable, state the uncertainty and rely on bundled templates plus project evidence.
2. Identify the application's development language (e.g., .NET, Java, Python, Node.js) and its specific version requirements.
3. Identify the target deployment platform (e.g., Azure App Service, Azure Kubernetes Service, Function App, or on-premises servers).
4. Detect the project source code structure to confirm build tools (e.g., Maven, Gradle, Npm, NuGet) and testing frameworks.
5. Read security and compliance requirements, including Static Application Security Testing (SAST), package vulnerability scanning, and container image scanning.
6. Confirm environment variable requirements, secret information sources (e.g., Azure Key Vault), and Service Connection permissions.
7. Proactively scan the skills/neo-azure-pipelines/templates/ directory to identify existing reusable template resources. Includes:
   • Build: build/build-dotnet.yml
   • Deploy: deploy/deploy-app-service.yml, deploy/deploy-iis.yml
   • Utils: util/clean-artifact.yml, util/extract-artifact.yml, util/iis/*.yml, etc.

Reason

1. Compare documented task versions with existing configurations to determine if task versions need updating (e.g., using Checkout@v1 vs. Checkout@v4).
2. Determine whether to adopt a multi-stage architecture based on project scale to achieve logical isolation of Build, Test, Staging, and Production.
3. Evaluate and design build caching strategies, optimizing dependency package folders to reduce execution time.
4. Design trigger mechanisms based on branching strategies, distinguishing trigger paths for Continuous Integration (CI) and Continuous Deployment (CD).
5. Determine the applicability of deployment strategies, such as Blue-Green, Canary, or Rolling Update.
6. Validate conditional execution syntax (Conditions) in Pipeline logic to ensure subsequent steps only execute on specific branches or after successful prerequisites.
7. Prioritize using templates from skills/neo-azure-pipelines/templates/ to assemble the Pipeline, rather than writing raw YAML from scratch.
   • If the project is .NET and needs deployment to IIS, combine build-dotnet.yml and deploy-iis.yml.
   • If artifact manipulation is required, prioritize using util/extract-artifact.yml.

Act

General Output Standards

1. Output YAML configuration scripts that comply with the current project-compatible Azure DevOps schema; state assumptions when exact task versions cannot be verified.
2. Provide comprehensive parameter definitions to increase the flexibility and reusability of Pipeline execution.
3. Generate configuration recommendations for Environments and Approvals and Checks.
4. Output a list of Task resource references used in the script, labeling version numbers to ensure execution environment consistency.
5. Provide preventive comments and explanations for common execution errors (e.g., insufficient permissions, dependency conflicts).
6. Use template syntax to reference selected template files and correctly pass required parameters. For example:

   - template: skills/neo-azure-pipelines/templates/build/build-dotnet.yml
     parameters:
       buildConfiguration: 'Release'
   

CI Workflow: .NET Build Pipeline

When configuring a CI process for a .NET project:

1. Scan the project directory to identify the .NET version (e.g., .NET 6/8), project name, and solution file (.sln).
2. Check for any existing pipeline configurations.
3. Create the .pipelines/templates/build/ and .pipelines/templates/util/ directories.
4. Copy build/build-dotnet.yml and util/clean-artifact.yml templates to their respective locations.
5. Generate azure-pipelines-ci.yml in the project root, ensuring the structure uses proper template syntax with correct parameters.

CD Workflow: Azure App Service Deployment

When configuring a CD process for Azure App Service:

1. Confirm the Azure App Service name, environment name (e.g., Production/Staging), and Service Connection name with the user or from the project context.
2. Identify the Build Artifact name.
3. Copy deploy/deploy-app-service.yml to the project's .pipelines/templates/deploy/ directory.
4. Generate the deployment pipeline file (e.g., azure-pipelines-cd-appservice.yml) in the project root.
5. Ensure the YAML correctly configures environment, strategy: runOnce, and template calls.
6. Advise the user on setting up corresponding Environments and Approvals in Azure DevOps.

CD Workflow: On-Premises IIS Deployment

When configuring a CD process for on-premises IIS:

1. Confirm IIS parameters: Website Name, Physical Path, Deployment Group name, and target environment.
2. Verify if the project requires specific ASP.NET Core environment settings.
3. Copy the entire util/iis/ directory and the deploy/deploy-iis.yml template to the project's .pipelines/templates/ directory.
4. Generate the deployment script (e.g., azure-pipelines-cd-iis.yml) in the project root, referencing deploy-iis.yml with parameters like websiteName and physicalPath.
5. Ensure the script integrates iis-backup.yml and iis-rollback.yml logic.
6. Explain the requirements for Service Connection permissions and Deployment Group configuration.