Azure CI/CD for Beginners: From Fundamentals to Your First Pipeline

1. Introduction to Azure CI/CD

Welcome to the exciting world of Continuous Integration and Continuous Delivery with Azure! This document is designed for absolute beginners, guiding you through the foundational concepts of Azure CI/CD all the way to deploying your first application.

What is Azure CI/CD?

Azure CI/CD refers to the practices of Continuous Integration (CI) and Continuous Delivery (CD) implemented using Microsoft Azure DevOps services. These practices are cornerstones of modern software development, enabling teams to deliver high-quality software faster and more reliably.

Continuous Integration (CI): Imagine a team of developers working on the same project. Without CI, integrating their code changes could lead to a chaotic “integration hell” with frequent conflicts and broken builds. CI is a development practice where developers frequently integrate their code changes into a shared repository. Each integration is then verified by an automated build and automated tests. This process helps detect integration errors early and simplifies debugging, making the codebase more stable.
Continuous Delivery (CD): Taking CI a step further, Continuous Delivery ensures that code changes are automatically prepared for release to production after the build and tests pass. This means that a new version of the application is always in a deployable state, though the actual deployment to production might still require a manual approval step.

Why Learn Azure CI/CD?

Learning Azure CI/CD offers numerous benefits, making it a highly sought-after skill in today’s tech landscape:

Automation: Automate repetitive tasks like building, testing, and deploying, freeing up developers to focus on writing code.
Faster Deployments: Accelerate the release cycle, allowing new features and bug fixes to reach users quickly.
Improved Quality: Catch bugs early in the development process through automated testing, reducing the risk of issues in production.
Reduced Risk: Smaller, more frequent code changes are easier to manage and troubleshoot.
Collaboration: Foster better collaboration among development, operations, and quality assurance teams.
Industry Relevance: Azure DevOps is a widely used platform, and CI/CD skills are essential for most modern software development roles.

A Brief History of CI/CD and its Role in Modern Software Development

The concept of Continuous Integration was introduced by Grady Booch in 1991, but it was popularized by Kent Beck in the late 1990s as part of Extreme Programming (XP). Continuous Delivery emerged later as a logical extension, emphasizing that software should always be in a deployable state. These practices, coupled with the rise of cloud computing and DevOps methodologies, have transformed software development. They enable organizations to respond quickly to market changes, deliver value continuously, and maintain a competitive edge.

Setting Up Your Development Environment

To begin your Azure CI/CD journey, you’ll need to set up a few things:

Creating an Azure DevOps Organization

An Azure DevOps organization is the top-level container for all your projects. It’s where you’ll manage users, permissions, and billing.

Go to https://dev.azure.com/ and sign in with your Microsoft account (or create one if you don’t have one).
If you don’t have an organization, you’ll be prompted to create one. Choose a unique name (e.g., yourname-devops) and a region closest to you.
Click “Continue” to create your organization.

Connecting to a Source Control System (e.g., GitHub)

Azure DevOps works seamlessly with various source control systems. For this guide, we’ll focus on GitHub, a popular choice.

Create a New Project: Inside your Azure DevOps organization, click “New Project.” Give it a meaningful name (e.g., my-first-cicd-project), choose “Private” for visibility, and ensure “Git” is selected for version control. Click “Create.”
Connect GitHub:
- Navigate to “Pipelines” > “Create Pipeline.”
- Choose “GitHub” as your code source.
- You’ll be redirected to GitHub to authorize Azure DevOps to access your repositories. Approve and install the Azure Pipelines GitHub App. You can choose to grant access to “Only select repositories” and specify the repositories you’ll be using.
- Select your GitHub repository from the list.

2. Core Concepts and Fundamentals of Azure DevOps for CI/CD

Azure DevOps is a suite of tools that supports the entire software development lifecycle. For CI/CD, these are the fundamental building blocks you need to understand:

Azure Repos

Azure Repos provides Git repositories (or Team Foundation Version Control, TFVC, if you prefer, though Git is recommended for modern development) for storing your source code. It’s where your developers collaborate on code changes.

Detailed Explanation: Azure Repos offers highly scalable and secure Git repositories. It supports features like pull requests, branch policies (to enforce code quality), and code reviews, making it a robust platform for team collaboration.
Interaction with CI/CD: Azure Pipelines continuously monitors your Azure Repos (or connected GitHub repositories) for changes. When a developer pushes new code, it can automatically trigger a CI pipeline.

Azure Pipelines (Builds and Releases)

Azure Pipelines is the heart of Azure CI/CD. It allows you to define, manage, and run automated pipelines for building, testing, and deploying your applications.

Detailed Explanation:
- Pipelines: A pipeline is a workflow that defines your CI/CD process. It’s typically defined in a YAML file (azure-pipelines.yml) stored alongside your code, which offers version control and easier collaboration.
- Stages: Pipelines are organized into stages, which are logical divisions of work (e.g., Build, Test, Deploy to Staging, Deploy to Production). Each stage can have one or more jobs.
- Jobs: A job is a unit of work that runs on an agent (a computing resource). Jobs contain a series of steps. By default, jobs run in parallel within a stage, but you can define dependencies.
- Steps: Steps are the smallest elements of a pipeline and can be a script (e.g., Bash, PowerShell) or a task.
- Tasks: Tasks are pre-packaged scripts or actions that perform specific operations (e.g., NodeTool@0 for installing Node.js, AzureWebApp@1 for deploying to Azure App Service).
- Agents: Agents are the machines that execute the jobs in your pipeline. Azure DevOps provides Microsoft-hosted agents (managed by Microsoft) for various operating systems and tools, or you can set up self-hosted agents.

Code Examples: A very basic YAML pipeline for a Node.js project to illustrate the structure:

trigger:
- main # This pipeline will run whenever there's a push to the 'main' branch

pool:
  vmImage: 'ubuntu-latest' # Specifies the operating system for the agent

steps:
- task: NodeTool@0 # A built-in task to install Node.js
  inputs:
    versionSpec: '18.x' # Specify the Node.js version
  displayName: 'Install Node.js' # A friendly name for the task

- script: | # A script step to execute shell commands
    npm install
    npm run build
  displayName: 'npm install and build' # Another friendly name

Azure Artifacts

Azure Artifacts is a service that allows you to create, host, and share package feeds for various package types (NuGet, npm, Maven, Python, etc.).

Detailed Explanation: It helps manage your dependencies by hosting private feeds. This ensures consistency and security by allowing your teams to use internal package stores or consume packages from public repositories.
Interaction with CI/CD: You can configure your CI pipelines to publish build artifacts to Azure Artifacts, making them available for consumption by other pipelines or projects.

Exercises/Mini-Challenges:

Exercise 1: Create a new project in Azure DevOps.

If you haven’t already, sign in to https://dev.azure.com/.
Create a new Azure DevOps organization if needed.
Inside your organization, click “New Project.”
Name your project MyFirstADOProject, set visibility to “Private,” and choose “Git” for version control.
Explore the different sections of your new project (Boards, Repos, Pipelines, etc.).

Exercise 2: Create a basic “Hello World” YAML pipeline.

In GitHub: Create a new repository (e.g., hello-world-app) and add a simple index.js file with console.log("Hello, Azure CI/CD!");.
In Azure DevOps:
- Go to your MyFirstADOProject and navigate to “Pipelines.”
- Click “Create Pipeline.”
- Choose “GitHub” as your source.
- Select the hello-world-app repository.
- Azure Pipelines will analyze your repository. Choose “Starter pipeline.”
- Replace the default YAML with a simple script to run your index.js file:
```
trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- checkout: self
- task: NodeTool@0
  inputs:
    versionSpec: '18.x'
  displayName: 'Install Node.js'
- script: node index.js
  displayName: 'Run Hello World script'
```
- Click “Save and run.” Observe the pipeline execution. If successful, you’ll see “Hello, Azure CI/CD!” in the logs.

3. Intermediate Topics: Building Your First Pipeline

Now that you understand the core concepts, let’s build a practical CI/CD pipeline for a static website.

Setting up a Basic CI/CD Pipeline for a Static Website

Deploying a static website to Azure Storage is a common and excellent starting point for learning CD. We will connect a GitHub repository, build the static content, and deploy it.

Fork a Sample Static Website Repository from GitHub: You’ll need a static website to work with. Fork a simple HTML/CSS/JS website repository. For example, you can use a basic template like this (though you’ll need to create a package.json if you want npm install and npm run build steps):
Let’s assume you have a repository structure like:
```
my-static-website/
├── index.html
├── css/
│   └── style.css
├── js/
│   └── script.js
└── package.json (optional, for build steps)
```
If your static website doesn’t have a package.json with a build script, you can simply publish the app_location. For a more robust example with a build step, consider a simple React or Vue app.
For simplicity in this beginner guide, let’s assume a static HTML website without a npm run build step for now, directly deploying the app_location. If you wish to include a build step (e.g., for a React app), you would add npm install and npm run build steps before the deployment.
Azure Storage Account Setup: You’ll need an Azure Storage Account configured for static website hosting.
- Go to the Azure Portal.
- Search for “Storage accounts” and click “Create.”
- Fill in the details:
  - Subscription: Your Azure subscription
  - Resource Group: Create a new one (e.g., my-static-web-rg)
  - Storage account name: A unique name (e.g., mystaticweb12345)
  - Location: Choose a region
  - Performance: Standard
  - Redundancy: Locally-redundant storage (LRS)
- Click “Review + create,” then “Create.”
- Once the storage account is deployed, navigate to it. Under “Data management,” select “Static website.”
- Enable “Static website” hosting. Set “Index document name” to index.html and “Error document path” to 404.html (or leave as is if you don’t have one). Note the “Primary endpoint” URL; this is where your website will be accessible.
Create an Azure DevOps Service Connection: To allow Azure Pipelines to deploy to your Azure Storage Account, you need a Service Connection.
- In your Azure DevOps project, go to “Project settings” (bottom-left).
- Under “Pipelines,” click “Service connections.”
- Click “New service connection.”
- Choose “Azure Resource Manager” and click “Next.”
- Select “Service principal (automatic)” and click “Next.”
- Choose your Subscription and the Resource Group where your storage account resides (e.g., my-static-web-rg).
- Give the service connection a descriptive name (e.g., AzureRM-StaticWebsite).
- Click “Save.”
Detailed Explanation of Each Task in a Typical Static Website Deployment Pipeline:
- trigger:: Defines when the pipeline runs. trigger: - main means it will run on every push to the main branch.
- pool:: Specifies the agent pool where the job will run. vmImage: 'ubuntu-latest' selects a Microsoft-hosted Ubuntu agent.
- steps:: A sequence of tasks and scripts.
- - checkout: self: Clones your repository to the agent.
- - task: AzureCLI@2: This is a powerful task that allows you to run Azure CLI commands. We’ll use it to get the deployment token for Azure Static Web Apps, or for deploying directly to Azure Blob Storage if we were using traditional static website hosting.
- - task: AzureStaticWebApp@0: This is a dedicated task for deploying to Azure Static Web Apps. While our initial example uses Azure Storage for basic static website hosting, it’s crucial to know about Azure Static Web Apps as a modern, full-featured solution for static sites with serverless APIs.
Note on Azure Static Web Apps vs. Azure Storage for Static Websites: While Azure Storage can host static websites, Azure Static Web Apps (SWA) is generally the recommended service for modern static websites as it provides:
- Integrated CI/CD with GitHub Actions (and can be used with Azure Pipelines).
- Global distribution of content.
- Free SSL certificates.
- Custom domain support.
- Serverless API integration.
- Preview environments for pull requests.
For this guide, we’ll demonstrate using AzureStaticWebApp@0 task, as it aligns with current best practices for static site deployment in Azure. If you were deploying directly to a blob storage container (the $web container), you would use the AzureRmWebAppDeployment@4 task or AzureBlobStorageFileUpload@2 task, or directly Azure CLI commands to sync the files.
Let’s use a simplified AzureStaticWebApp@0 example. You will need an Azure Static Web App resource created in the Azure portal for this to work.
Creating an Azure Static Web App Resource:
- Go to the Azure Portal.
- Search for “Static Web Apps” and click “Create.”
- Fill in the details, choosing “Other” for deployment details initially, as we’ll connect it via Azure Pipelines.
- After creation, go to the resource, and under “Settings,” click “Manage Deployment Token” and copy this token. You’ll store this as a secret in Azure DevOps.

Code Examples: Full YAML pipeline for building and deploying a static website to Azure Static Web Apps.

Store Deployment Token as a Secret Variable:
- In Azure DevOps, go to “Pipelines” > “Library.”
- Click “+ Variable group.”
- Name it StaticWebAppSecrets.
- Add a variable:
  - Name: SWA_DEPLOYMENT_TOKEN
  - Value: Paste the token you copied from your Azure Static Web App resource.
  - Check “Keep this value secret.”
- Click “Save.”
- Link this variable group to your pipeline. In the pipeline YAML, add:
```
variables:
- group: StaticWebAppSecrets
```

azure-pipelines.yml for a simple static website to Azure Static Web Apps:

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
- group: StaticWebAppSecrets # Link the variable group

steps:
- checkout: self
  submodules: true # If your static site uses submodules

- script: |
    echo "Building static website (if applicable)"
    # For a simple HTML/CSS/JS site, build might just be copying files.
    # For frameworks like React/Vue, this would involve 'npm install' and 'npm run build'.
    # Example for a React app:
    # npm install
    # npm run build    
  displayName: 'Build Static Website'

- task: AzureStaticWebApp@0
  inputs:
    app_location: '/' # Adjust if your app's root is in a subfolder, e.g., '/src' or '/public'
    output_location: '/' # For simple HTML, output is usually root. For frameworks, it's typically 'build' or 'dist'.
    azure_static_web_apps_api_token: $(SWA_DEPLOYMENT_TOKEN) # Reference the secret variable
    deployment_environment: 'production' # Or 'staging' for a staging environment
  displayName: 'Deploy Static Web App to Azure'

Explanation:

The AzureStaticWebApp@0 task is specifically designed for Azure Static Web Apps.
app_location: Specifies the folder where your application source code resides, relative to the repository root.
output_location: Specifies the folder where the compiled application code (after building) is located. If you have a simple HTML site and no build process, this might be the same as app_location. For a React app, it could be /build or /dist.
azure_static_web_apps_api_token: This input securely uses the deployment token from your variable group to authorize the deployment.
deployment_environment: This allows you to specify a target environment. Leave blank for production, or use names like staging to create a staging environment.

Exercises/Mini-Challenges:

Exercise 1: Fork a sample static website repository from GitHub.

Find a simple HTML/CSS/JS website on GitHub, or create a new repository and populate it with a basic index.html and a few assets.
Fork this repository to your own GitHub account.

Exercise 2: Implement the CI pipeline to build the website.

Connect your forked repository to your Azure DevOps project as shown in Section 1.
Create a new pipeline in Azure Pipelines and select your forked repository.
Use the azure-pipelines.yml from the example above.
If your website has a build step (e.g., npm run build), include NodeTool@0 and script tasks for npm install and npm run build. If it’s pure HTML/CSS/JS, the “Build Static Website” script can be a placeholder or simply indicate file readiness.
Run the pipeline and ensure the “Build Static Website” step (or similar) completes successfully.

Exercise 3: Implement the CD pipeline to deploy the website to a storage account (or Azure Static Web App).

Create an Azure Static Web App resource in the Azure Portal if you haven’t already.
Get the deployment token for your Azure Static Web App and save it as a secret variable (SWA_DEPLOYMENT_TOKEN) in an Azure DevOps variable group (StaticWebAppSecrets).
Update your azure-pipelines.yml to include the AzureStaticWebApp@0 task, using the secret token and appropriate app_location and output_location for your website.
Run the pipeline. After successful deployment, navigate to the URL of your Azure Static Web App to see your website live.

4. Advanced Topics and Best Practices for Beginners

As you become more comfortable, consider these topics and best practices to enhance your CI/CD workflows.

Comparing Azure Pipelines with GitHub Actions for CI/CD

Both Azure Pipelines and GitHub Actions offer powerful CI/CD capabilities. While this guide focuses on Azure Pipelines, understanding their differences is valuable.

Feature	Azure Pipelines	GitHub Actions
Integration	Part of Azure DevOps, integrates with Azure services.	Fully integrated into GitHub, strong with GitHub ecosystem.
Configuration	Primarily YAML (or Classic UI for older pipelines).	Exclusively YAML.
YAML Structure	Supports stages, jobs, steps.	Workflows, jobs, steps (stages can be simulated).
Self-Hosted Agents	Supported, with capabilities.	Supported (called self-hosted runners), with labels.
Templates/Reusability	Extensive template support for pipelines.	Strong support for reusable workflows and actions.
Marketplace	Azure DevOps Marketplace for extensions.	GitHub Marketplace for Actions.
Secret Management	Variable Groups, Azure Key Vault integration.	GitHub Secrets, integration with Azure Key Vault (via actions).
Best Use Cases (Simplified)	Enterprise-grade, deeply integrated with Azure, hybrid environments.	Open-source projects, projects heavily invested in GitHub ecosystem, simplified workflows.

When to use each (simplified for beginners):

Azure Pipelines: If your team is already using Azure DevOps for project management (Boards, Repos) or if you have a complex enterprise environment with deep Azure integrations, Azure Pipelines is a natural fit. It offers a comprehensive suite of tools.
GitHub Actions: If your codebase primarily lives on GitHub, especially for open-source projects or if you prefer a more streamlined, GitHub-native CI/CD experience, GitHub Actions is an excellent choice. It’s often perceived as simpler to get started with for basic scenarios directly within your GitHub repository.

Managing Secrets and Sensitive Data: Introduction to best practices using Azure Key Vault (simplified overview)

Storing sensitive information (like API tokens, database connection strings, or deployment passwords) directly in your YAML files or version control is a major security risk. Azure Key Vault provides a secure solution.

What is Azure Key Vault? Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. It helps you control access to sensitive information, ensuring it’s not exposed in plain text.
Simplified Overview for Beginners: Instead of hardcoding your SWA_DEPLOYMENT_TOKEN directly into a variable group in Azure DevOps (though better than YAML), you can store it in Azure Key Vault. Then, your Azure Pipeline can be configured to retrieve the secret from Key Vault at runtime. This adds an extra layer of security and centralized management.
Basic Flow:
1. Create an Azure Key Vault in the Azure Portal.
2. Store your secret (e.g., SWA_DEPLOYMENT_TOKEN) in Key Vault.
3. Grant your Azure DevOps Service Connection (the one you created earlier) permissions to access secrets in that Key Vault.
4. In your Azure Pipeline, link the Key Vault secrets to a variable group. This makes the secrets available as pipeline variables without exposing their actual values in the pipeline definition.
While the full setup involves more steps, understanding that services like Azure Key Vault are critical for secure secret management is an important best practice.

Troubleshooting Common Issues

Even with automation, things can go wrong. Here are common issues and simple troubleshooting tips:

Build Failures:
- Common Causes: Compilation errors, failed tests, missing dependencies, incorrect paths in scripts.
- Simple Solutions:
  - Check Logs: The pipeline logs are your best friend. Look for error messages (often highlighted in red) to pinpoint the exact step and command that failed.
  - Local Reproduction: Try to reproduce the build failure on your local machine. This helps isolate if the issue is with your code or the pipeline environment.
  - Agent Environment: Ensure the agent has the necessary tools and versions installed (e.g., correct Node.js version, .NET SDK).
  - Paths: Double-check file paths and working directories in your YAML, especially for script tasks.
Deployment Errors:
- Common Causes: Incorrect service connection, insufficient permissions, target resource not found, misconfigured deployment parameters.
- Simple Solutions:
  - Service Connection: Verify your Azure Service Connection is configured correctly and has the necessary permissions (e.g., “Contributor” role for the target resource group).
  - Target Resource: Ensure the Azure resource (e.g., Static Web App name, App Service name) specified in your deployment task is correct and exists.
  - Deployment Token/Secrets: If using deployment tokens or secrets, confirm they are correctly configured and accessible by the pipeline.
  - Firewall/Network: Check if any network restrictions or firewalls are blocking the deployment agent’s access to your Azure resources.
Agent Problems:
- Common Causes: No available agents, agent offline, insufficient parallel jobs, agent pools not configured correctly.
- Simple Solutions:
  - Check Parallel Jobs: For Microsoft-hosted agents, ensure you have sufficient “parallel jobs” granted to your organization. New organizations sometimes need to request a free grant.
  - Agent Status: If using self-hosted agents, verify the agent machine is online and the agent software is running.
  - Agent Pool: Ensure your pipeline is configured to use the correct agent pool.
  - Resource Limits: Check if the agent is running out of disk space, memory, or CPU during a build.

5. Guided Projects

These projects will solidify your understanding by applying what you’ve learned.

Project 1: CI/CD for a Simple Web Application (e.g., Node.js or .NET Core)

Objective: Automate the build, test, and deployment of a basic web application to an Azure Web App.

Steps:

Set up a new Azure DevOps project and connect a sample application repository.
- Sample App: Choose a simple Node.js Express app or a .NET Core web API. For example, clone a basic Node.js Express “Hello World” app.
- Azure DevOps Project: Create a new project named WebAppCICDProject.
- GitHub Connection: Connect your cloned sample app repository from GitHub to your new Azure DevOps project.

Create a CI pipeline to build and test the application.

Azure Web App: In the Azure Portal, create an Azure App Service Web App (e.g., a Node.js or .NET Runtime).
Service Connection: Create an Azure Resource Manager Service Connection in Azure DevOps for your Azure subscription/resource group where the Web App is located (e.g., AzureRM-WebApp).

Pipeline YAML (azure-pipelines.yml):

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- checkout: self

- task: NodeTool@0 # Use DotNetCoreCLI@2 for .NET Core
  inputs:
    versionSpec: '18.x' # Adjust for your Node.js or .NET Core version
  displayName: 'Install Node.js'

- script: |
    npm install # npm install for Node.js, dotnet restore for .NET Core
    npm test    # npm test for Node.js, dotnet test for .NET Core    
  displayName: 'Install dependencies, Build, and Run Tests'

- task: ArchiveFiles@2 # Package the application for deployment
  inputs:
    rootFolderOrFile: '$(System.DefaultWorkingDirectory)'
    includeRootFolder: false
    archiveType: 'zip'
    archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
    replaceExistingArchive: true
  displayName: 'Archive Application'

- publish: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
  artifact: drop
  displayName: 'Publish Build Artifact'

Run this pipeline and ensure the build and test steps pass.

Create a CD pipeline to deploy to an Azure Web App.

Extend the YAML (Multi-stage pipeline): Add a deployment stage to the same azure-pipelines.yml file.

# ... (previous CI stages) ...

- stage: Deploy
  displayName: 'Deploy to Azure Web App'
  dependsOn: Build # This stage depends on the Build stage succeeding
  jobs:
  - deployment: DeployWebApp
    displayName: 'Deploy Web App'
    environment: 'Production' # Name of your target environment
    variables:
      WebAppName: 'your-azure-web-app-name' # Replace with your Azure Web App name
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
            displayName: 'Download Build Artifact'

          - task: AzureWebApp@1 # Task to deploy to Azure App Service
            inputs:
              azureSubscription: 'AzureRM-WebApp' # Your Azure Service Connection name
              appType: 'webAppLinux' # or 'webApp' for Windows, 'functionApp' for Azure Function
              appName: '$(WebAppName)'
              package: '$(Pipeline.Workspace)/drop/$(Build.BuildId).zip'
            displayName: 'Deploy Azure Web App'

Update WebAppName and azureSubscription with your specific values.
Run the complete pipeline. Verify the deployment by accessing your Azure Web App URL.

Encourage independent problem-solving for adding a simple test task.
- Challenge: If your sample application doesn’t have tests, add a very basic unit test (e.g., a simple assertion) and integrate it into the CI pipeline’s “Install dependencies, Build, and Run Tests” step. Observe how the pipeline behaves if the test fails.

Project 2: Deploying a Static Website with an Approval Step

Objective: Deploy a static website but require manual approval before the final production deployment. This introduces the concept of release gates.

Steps:

Revisit the static website pipeline.

Use the azure-pipelines.yml you created in Section 3 for deploying a static website to Azure Static Web Apps. Ensure it has at least two stages: one for building (if applicable) and one for deploying.

Add a Staging Deployment Stage: Modify your pipeline to deploy to a “staging” environment first, and then to “production.” You can achieve this by using the deployment_environment input in the AzureStaticWebApp@0 task.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
- group: StaticWebAppSecrets

stages:
- stage: BuildAndDeployStaging
  displayName: 'Build and Deploy to Staging'
  jobs:
  - deployment: DeployStaging
    displayName: 'Deploy Staging'
    environment: 'Staging' # Name this environment 'Staging' in Azure DevOps
    strategy:
      runOnce:
        deploy:
          steps:
          - checkout: self
            submodules: true

          - script: |
              echo "Building static website for Staging"
              # npm install && npm run build (if applicable)              
            displayName: 'Build Static Website for Staging'

          - task: AzureStaticWebApp@0
            inputs:
              app_location: '/'
              output_location: '/'
              azure_static_web_apps_api_token: $(SWA_DEPLOYMENT_TOKEN)
              deployment_environment: 'staging' # Deploy to a staging environment in SWA
            displayName: 'Deploy Static Web App to Staging'

- stage: DeployProduction
  displayName: 'Deploy to Production'
  dependsOn: BuildAndDeployStaging # This stage depends on Staging deployment
  jobs:
  - deployment: DeployProd
    displayName: 'Deploy Production'
    environment: 'Production' # Name this environment 'Production' in Azure DevOps
    strategy:
      runOnce:
        deploy:
          steps:
          - checkout: self
            submodules: true # Or download artifacts from previous stage if build output is packaged

          - script: |
              echo "Deploying production-ready artifacts"
              # If build artifacts are published and downloaded, use them here.              
            displayName: 'Prepare Production Deployment'

          - task: AzureStaticWebApp@0
            inputs:
              app_location: '/' # Ensure this points to your production-ready artifacts
              output_location: '/'
              azure_static_web_apps_api_token: $(SWA_DEPLOYMENT_TOKEN)
              deployment_environment: 'production' # Deploy to the production environment in SWA
            displayName: 'Deploy Static Web App to Production'

Introduce an approval gate in the release process.
- In Azure DevOps, go to “Environments” (under “Pipelines”).
- Create a new environment named Production.
- Click on the Production environment, then “Approvals and checks” (under “Security”).
- Click “+ Add a check,” choose “Approvals,” and add yourself (or a team member) as a required approver. You can also add a timeout.
- Now, when the DeployProduction stage of your pipeline runs, it will pause and wait for your approval before proceeding.
Explain how to configure and manage approvals.
- When an approval is pending, you’ll see a notification in the pipeline run summary.
- Clicking on the pending stage will show you the approval request.
- You can “Approve” or “Reject” the deployment.
- Approvals are a powerful way to implement quality gates and ensure human oversight for critical deployments.
Challenge: Add a separate stage for a staging environment that does not require approval.
- The YAML provided in step 1 already includes a BuildAndDeployStaging stage. This stage, by default, would not have an approval gate.
- To complete the challenge: Ensure you have configured the Staging environment in Azure DevOps (under “Pipelines” -> “Environments”) with no approvals or checks configured. This demonstrates how different environments can have different levels of control.
- You can then create a second Azure Static Web App in the Azure portal, specifically for staging, and use a separate SWA_STAGING_DEPLOYMENT_TOKEN secret and set deployment_environment: 'staging' in its task. This is a more robust approach for distinct environments.

6. Bonus Section: Further Learning and Resources

The journey into Azure CI/CD is ongoing. Here are recommended resources to continue your learning:

Recommended Online Courses/Tutorials:

Microsoft Learn: Azure DevOps paths. Microsoft Learn offers free, interactive learning paths that are excellent for both beginners and experienced professionals. Look for modules on Azure Pipelines, Azure Repos, and CI/CD.
Pluralsight/Udemy courses on Azure CI/CD. Many platforms offer in-depth video courses covering practical implementations and best practices. Search for “Azure DevOps CI/CD” or “Azure Pipelines” on these platforms.

Official Documentation:

Azure DevOps Documentation: The official documentation is always the most up-to-date source for features, tasks, and troubleshooting. It includes comprehensive guides and API references.
- https://learn.microsoft.com/en-us/azure/devops/
Azure Pipelines YAML Schema reference: This is invaluable for understanding the structure and available options for your YAML pipelines.
- https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/

Blogs and Articles:

Microsoft Azure DevOps Blog: Stay updated on the latest features, announcements, and best practices directly from the Azure DevOps team.
- https://devblogs.microsoft.com/devops/
Popular community blogs on Azure CI/CD. Many MVPs and community experts share practical guides and advanced techniques. Look for blogs from well-known DevOps practitioners in the Azure space.

YouTube Channels:

Azure DevOps YouTube channel: Official channel with tutorials, demos, and updates.
- Search “Azure DevOps” on YouTube.
Other prominent tech channels covering DevOps and Azure. Channels like “Fireship,” “Traversy Media,” or specific Azure MVPs often have excellent content.

Community Forums/Groups:

Stack Overflow (Azure DevOps tag). A great place to ask specific questions and find solutions to common problems.
- https://stackoverflow.com/tags/azure-devops
Azure DevOps Community on Microsoft Q&A. Official Microsoft forum for questions and answers.
- https://learn.microsoft.com/en-us/answers/tags/422/azure-devops
LinkedIn Groups: Join groups focused on DevOps, Azure, and CI/CD to connect with peers and experts.

Next Steps/Advanced Topics:

Once you’ve mastered the basics, consider exploring these more advanced topics:

Infrastructure as Code (IaC): Learn to provision your Azure resources using tools like Azure Bicep, ARM Templates, or Terraform, integrating them into your CI/CD pipelines.
DevSecOps: Incorporate security practices and tools (like static code analysis, vulnerability scanning) into your CI/CD pipeline.
Containerized Deployments: Learn to build and deploy containerized applications (Docker) to services like Azure Container Registry and Azure Kubernetes Service (AKS).
Advanced Release Strategies: Explore concepts like blue/green deployments, canary deployments, and feature flags for more controlled and resilient releases.
Monitoring and Alerting: Integrate monitoring and alerting solutions (e.g., Azure Monitor, Application Insights) into your CD pipelines to get feedback on deployed applications.

You’ve taken the first crucial step in understanding and implementing Azure CI/CD. Keep practicing, keep exploring, and you’ll soon be automating your software deployments like a pro!

Azure CI/CD for Beginners: From Fundamentals to Your First Pipeline

// table of contents

Azure CI/CD for Beginners: From Fundamentals to Your First Pipeline

1. Introduction to Azure CI/CD

What is Azure CI/CD?

Why Learn Azure CI/CD?

A Brief History of CI/CD and its Role in Modern Software Development

Setting Up Your Development Environment

Creating an Azure DevOps Organization

Connecting to a Source Control System (e.g., GitHub)

2. Core Concepts and Fundamentals of Azure DevOps for CI/CD

Azure Repos

Azure Pipelines (Builds and Releases)

Azure Artifacts

Exercises/Mini-Challenges:

Exercise 1: Create a new project in Azure DevOps.

Exercise 2: Create a basic “Hello World” YAML pipeline.

3. Intermediate Topics: Building Your First Pipeline

Setting up a Basic CI/CD Pipeline for a Static Website

Code Examples: Full YAML pipeline for building and deploying a static website to Azure Static Web Apps.

Exercises/Mini-Challenges:

Exercise 1: Fork a sample static website repository from GitHub.

Exercise 2: Implement the CI pipeline to build the website.

Exercise 3: Implement the CD pipeline to deploy the website to a storage account (or Azure Static Web App).

4. Advanced Topics and Best Practices for Beginners

Comparing Azure Pipelines with GitHub Actions for CI/CD

Managing Secrets and Sensitive Data: Introduction to best practices using Azure Key Vault (simplified overview)

Troubleshooting Common Issues

5. Guided Projects

Project 1: CI/CD for a Simple Web Application (e.g., Node.js or .NET Core)

Project 2: Deploying a Static Website with an Approval Step

6. Bonus Section: Further Learning and Resources

Recommended Online Courses/Tutorials:

Official Documentation:

Blogs and Articles:

YouTube Channels:

Community Forums/Groups:

Next Steps/Advanced Topics: