Skip to main content
CI/CD and deployment slots for Azure App Service. CI/CD (Continuous Integration / Continuous Deployment) automates build and release workflows so teams can integrate changes from multiple contributors and push updates reliably and quickly. Azure App Service supports two primary CI/CD patterns:
  • Automated deployment — Connect App Service to a repository (GitHub, Bitbucket, Local Git, or Azure Repos). Commits to the chosen branch trigger builds and automatic deployments.
  • Manual deployment — Push artifacts to storage or a location that App Service pulls from. Note: integrations with OneDrive and Dropbox for App Service and Azure Functions were retired on September 30, 2023 — disable and migrate any such integrations.
Automated deployments are recommended for frequent changes and multiple contributors. Manual deployments can be appropriate for single, infrequent updates or specific artifact workflows, but confirm that your storage integration is supported and secure.
A CI/CD diagram with orange "Automated Deployment" and purple "Manual Deployment" panels on the left. On the right a central service icon connects to repository and storage options labeled Azure Repos, Bitbucket, Git, OneDrive, and Dropbox.
This section shows a concise, reproducible example of connecting Azure Repos to an App Service so commits trigger automatic deployments. How the connection works (high level)
  1. Make a code change locally and push it to the chosen branch in your repository.
  2. App Service Deployment Center detects the new commit, triggers a build, and deploys the artifact to the configured App Service instance.
  3. Verify the change by refreshing your web app or checking Deployment Center logs.
Example: commit a small HTML change
  1. Edit a simple header in index.html. Example excerpt:
  1. Commit and push to Azure Repos (or another supported provider). Example (abbreviated) git output:
  1. In the Azure portal, open your App Service → Deployment Center. Select the source (Azure Repos, GitHub, etc.), pick organization/project/repository and the branch you want to deploy, and save the configuration. After saving, Deployment Center logs display build and deployment events triggered by commits.
A screenshot of the Microsoft Azure portal showing the Deployment Center for a web app called "kodekloudemoapp." The Logs tab is open, displaying recent deployment entries with commit IDs, authors, timestamps and statuses.
After the CI/CD build completes, refresh the web app to confirm the change is live — e.g., the header now displays “KodeKloud Dashboard”. Repeat this process for iterative changes and watch Deployment Center trigger new builds automatically. Deployment slots Deployment slots let you host multiple instances of the same App Service app (production, staging, QA, UAT, dev, etc.) within a single App Service plan. Each slot is a full App Service instance with its own hostname and can receive traffic routing percentages (useful for A/B testing, gradual rollouts, or previewing features). Typical workflow
  • Commit code to a development branch → CI/CD deploys to a non-production slot (for example, dev).
  • Validate the app in that slot using its unique URL.
  • Promote validated changes to production by merging the branch to main (triggering production CI/CD) or by swapping the slot into production.
Benefits of slot swapping
  • Reduces downtime and cold starts by swapping warmed-up instances.
  • Provides a fast rollback path by swapping back to the previous slot.
Limits by App Service plan Slot configuration: sticky vs swapped
  • By default, most app settings and connection strings are part of the site configuration and are swapped between slots.
  • Mark a setting as a “slot setting” to make it sticky to that slot (it will not swap).
  • Other configuration items are not swapped (examples include custom domains, scale settings, VNet integration, TLS/SSL certificates, and certain diagnostic settings).
For the complete and up-to-date list of swapped vs non-swapped settings, see the Microsoft documentation: https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
A slide titled "Deployment Slots – Considerations" showing an Azure CI/CD flow from Azure Repos to a Staging slot and a Swap to Production. Below are two columns listing settings that can be swapped and settings that aren't swapped.
Example workflow: create a dev branch, a dev slot, deploy to slot, then swap
  1. Create a dev branch in Azure Repos (or locally and push). In Azure DevOps you can create branches from the Files view.
  2. In the App Service blade, open Deployment slots → Add. Choose a slot name (for example, dev) and select whether to clone the production configuration. In this example we choose “Do not clone settings” to keep the slot independent.
Screenshot of the Microsoft Azure portal on the "kodekloudemoapp" Deployment Slots page. An "Add a slot" pane is open to create a "dev" slot with "Do not clone settings" selected.
  1. After creation, the slot runs as a separate instance with its own URL. Configure a CI/CD pipeline (Deployment Center) to deploy commits from the dev branch to the dev slot.
Screenshot of the Microsoft Azure portal showing the "Deployment slots" page for a web app named "kodekloudemoapp." It lists production and dev slots with their status (Running), app service plan, and traffic percentage.
  1. Configure Deployment Center for the dev slot and select Azure Repos → dev branch as the source. The slot will build and deploy automatically on commits.
A screenshot of the Microsoft Azure portal showing the Deployment Center for the App Service slot "dev (kodekloudemoapp/dev)" with Azure Repos selected as the source. The page displays Azure Repos settings (organization, project, repository, branch) along with the left navigation menu and top action buttons.
  1. Push a change to the dev branch. Confirm success in the dev slot’s Deployment Center logs.
A screenshot of the Microsoft Azure portal showing the Deployment Center for an App Service slot named "dev (kodekloudemoapp/dev)". The Logs tab lists recent commits with times, commit IDs, deployment statuses (all successful) and short messages.
  1. Promote the change to production when ready:
    • Option 1: Create and complete a pull request from dev → main. The merge triggers CI/CD for main and deploys to production.
    • Option 2: Swap the dev slot into production to instantly promote the validated slot without a code merge.
Example repo view in Azure DevOps while preparing merges:
A screenshot of the Azure DevOps Repos interface for a project called "App Service Demo Site," showing the file tree and a long list of HTML component files and folders. The main pane lists filenames, last-change timestamps (Yesterday) and a commit hash for each entry.
If you complete the pull request from dev to main, Deployment Center for the production slot will detect the new commit and deploy it to production.
A screenshot of an Azure DevOps pull request for the "prod-change" branch with the "Complete pull request" dialog open. The dialog shows merge type and post-completion options (e.g., complete associated work items, delete branch) and a "Complete merge" button.
Swap directly between slots (no merge required)
  • In the App Service blade, open Deployment slots → Swap.
  • Choose the source slot (for example, kodekloudemoapp-dev) and the target (production), review the configuration changes that will apply, and confirm.
A screenshot of the Microsoft Azure portal showing the "Deployment Slots" page for a web app named "kodekloudemoapp." A "Swap" pane is open, selecting source "kodekloudemoapp-dev" and target "kodekloudemoapp" and listing configuration changes.
After a successful swap:
  • Production immediately serves the dev changes.
  • The dev slot now contains the previous production code, enabling a quick rollback by swapping back.
  • Check CI/CD logs and slot deployment logs to review deployments and swap history.
This walkthrough demonstrates how to use Azure Repos with App Service Deployment Center and how deployment slots let you validate non-production changes and promote them into production with minimal downtime.
If you previously relied on OneDrive or Dropbox continuous deployments, migrate those workflows before September 30, 2023, to avoid service interruptions. Use supported sources such as Azure Repos, GitHub, or Bitbucket.
Further study and references Consider expanding your learning to container-based hosting on Azure (App Service for Containers, Azure Kubernetes Service) and deepening knowledge of App Service configuration, networking, and security features.

Watch Video