Deploy the Same Build Artifact Across Dev → SIT → UAT →

1. What is it?

In Azure DevOps, we build the ASP.NET Core application only once and deploy the same build artifact to multiple environments.

The environments are:

Dev: Developers test the application.
SIT: System Integration Testing.
UAT: User Acceptance Testing.
Production: Live application used by customers.

Main purpose: Ensure the same tested application version is deployed across all environments.

2. How does it work?

Developer Pushes Code
        |
        v
   CI Pipeline
        |
        | Restore
        | Build
        | Test
        | Publish
        v
  Build Artifact (ZIP)
        |
        v
   Deploy to DEV
        |
        | Automated Testing
        v
   Deploy to SIT
        |
        | Integration Testing
        v
   Deploy to UAT
        |
        | Manual Approval
        v
 Deploy to PRODUCTION
        |
        v
  Application Live

Important: We do not rebuild the application for each environment. We reuse the same ZIP artifact.

3. Simple YAML example

stages:

- stage: Dev
  jobs:
  - deployment: DeployDev
    environment: 'Dev'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'AzureConnection'
              appName: 'myapp-dev'
              package: '$(Pipeline.Workspace)/drop/webapp.zip'

- stage: SIT
  dependsOn: Dev
  jobs:
  - deployment: DeploySIT
    environment: 'SIT'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'AzureConnection'
              appName: 'myapp-sit'
              package: '$(Pipeline.Workspace)/drop/webapp.zip'

The same approach is used for UAT and Production, changing only the environment and App Service name.

This example assumes the artifact has already been published and is available at the specified path.

4. How are configurations managed?

Each environment may have different connection strings, API URLs, and secrets.

Configuration	Dev	SIT	UAT	Production
App Service	myapp-dev	myapp-sit	myapp-uat	myapp-prod
Database	DevDB	SITDB	UATDB	ProdDB
Environment	Development	SIT	UAT	Production
Approval	Automatic	Automatic	Manual	Manual

We manage these differences using Azure App Service settings, Azure DevOps variables, and Azure Key Vault.

The application artifact remains unchanged.

5. Important interview points

Build Once, Deploy Many: Reuse the same artifact.
Multi-stage YAML Pipeline: Manage Dev, SIT, UAT, and Production.
Dependencies: Use dependsOn to control deployment order.
Approvals: Configure approvals and checks on Azure DevOps Environments, typically before UAT or Production.
Configuration: Keep environment-specific settings outside the artifact.
Rollback: Redeploy a previously successful artifact when necessary.

6. Interview answer

Question: How do you deploy the same build artifact across Dev, SIT, UAT, and Production?

Answer:

"We follow the Build Once, Deploy Many approach in Azure DevOps.

First, our CI pipeline builds and publishes the ASP.NET Core application and generates a ZIP artifact.

Then, our multi-stage CD pipeline deploys the same artifact sequentially to Dev, SIT, UAT, and Production.

Each environment has its own App Service, database connection strings, and configuration settings.

We configure approval gates for UAT and Production to ensure deployments happen only after successful testing and approval."

Remember: One Build → One Artifact → Multiple Environments → Controlled Approvals.

Deploy the Same Build Artifact Across Dev → SIT → UAT → Production