Building an ASP.NET Core Application Using Azure Pipelines

1. What is it?

An Azure DevOps Build Pipeline (CI Pipeline) automates the process of retrieving ASP.NET Core source code from a Git repository, restoring NuGet packages, compiling the application, running tests, publishing the application, and generating a deployable artifact.

Main purpose:

• Automate the build process whenever developers push code.

• Identify compilation and unit-test failures early.

• Generate consistent deployment packages.

• Avoid manual builds and publishing.

• Make build artifacts available for deployment to SIT, UAT, and Production.

2. How does it work?

ASP.NET Core CI Build Flow

Developer (.NET / Visual Studio)
           |
           | git push
           v
Azure Repos / GitHub
           |
           | CI Trigger
           v
Azure DevOps Pipeline
           |
           v
1. Checkout Source Code
           |
           v
2. Setup .NET SDK
           |
           v
3. Restore NuGet Packages
           |
           v
4. Build ASP.NET Core Solution
           |
           v
5. Run Unit Tests
           |
           v
6. Publish ASP.NET Core Application
           |
           v
7. Generate Deployment Artifact
           |
           v
8. Publish Pipeline Artifact
           |
           v
Available for CD Pipeline
           |
           v
      SIT → UAT → PROD

The CI pipeline ends when the artifact is generated and stored. The CD pipeline subsequently deploys that artifact to the required environment.

3. Azure Pipelines YAML Example

Assume our ASP.NET Core solution has the following structure:

MyApplication/
│
├── src/
│   ├── MyApp.API/
│   │   └── MyApp.API.csproj
│   │
│   ├── MyApp.Application/
│   ├── MyApp.Domain/
│   └── MyApp.Infrastructure/
│
├── tests/
│   └── MyApp.Tests/
│       └── MyApp.Tests.csproj
│
├── MyApplication.sln
└── azure-pipelines.yml

azure-pipelines.yml

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:

# 1. Checkout source code
- checkout: self

# 2. Install .NET SDK
- task: UseDotNet@2
  displayName: 'Install .NET SDK'
  inputs:
    packageType: 'sdk'
    version: '8.0.x'

# 3. Restore NuGet packages
- script: dotnet restore MyApplication.sln
  displayName: 'Restore NuGet Packages'

# 4. Build solution
- script: >
    dotnet build MyApplication.sln
    --configuration $(buildConfiguration)
    --no-restore
  displayName: 'Build Solution'

# 5. Run unit tests
- script: >
    dotnet test tests/MyApp.Tests/MyApp.Tests.csproj
    --configuration $(buildConfiguration)
    --no-build
  displayName: 'Run Unit Tests'

# 6. Publish ASP.NET Core API
- task: DotNetCoreCLI@2
  displayName: 'Publish Web API'
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: 'src/MyApp.API/MyApp.API.csproj'
    arguments: >
      --configuration $(buildConfiguration)
      --output $(Build.ArtifactStagingDirectory)/publish
    zipAfterPublish: true
    modifyOutputPath: false

# 7. Publish artifact
- task: PublishPipelineArtifact@1
  displayName: 'Publish Build Artifact'
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)/publish'
    artifact: 'drop'
    publishLocation: 'pipeline'

This example assumes the solution builds and the test project exists. The pipeline uses a Microsoft-hosted Ubuntu agent and .NET 8.

4. Explanation of Each Step

Important commands

Restore

dotnet restore MyApplication.sln

Downloads required NuGet packages based on the project dependencies.

Build

dotnet build MyApplication.sln --configuration Release

Compiles the entire solution, including referenced projects. A compilation error causes the step to fail.

Test

dotnet test tests/MyApp.Tests/MyApp.Tests.csproj \
  --configuration Release

Executes automated tests. A failed test normally fails the pipeline.

Publish

dotnet publish src/MyApp.API/MyApp.API.csproj \
  --configuration Release \
  --output ./publish

Generates files required to run the application, including application DLLs, dependencies, and configuration files. The YAML example also packages the publish output as a ZIP file.

5. What Is a Build Artifact?

A build artifact is the output generated by a successful build and publish process. It is stored in Azure DevOps and can be downloaded or consumed by a deployment pipeline.

Example:

Azure Pipeline
    |
    v
Build Successful
    |
    v
Publish Application
    |
    v
MyApp.API.zip
    |
    v
Pipeline Artifact: drop
    |
    +----> Deploy to SIT
    |
    +----> Deploy to UAT
    |
    +----> Deploy to Production

Important: We should deploy the same tested artifact across SIT, UAT, and Production rather than rebuilding the source separately for each environment.

Environment-specific settings and secrets should be supplied securely during deployment or at runtime.

6. Important Azure Pipeline Variables

7. Real-Time Project Scenario

Consider a banking application developed using ASP.NET Core Web API, Clean Architecture, and SQL Server.

A developer completes a feature and merges the changes into main.

1. Azure Pipelines automatically starts because of the CI trigger.

2. The agent checks out the latest source code.

3. The required .NET SDK and NuGet packages are made available.

4. The solution is compiled in Release mode.

5. Unit tests are executed.

6. The Web API project is published.

7. The deployment ZIP is generated and uploaded as the drop artifact.

8. The CD pipeline can deploy the artifact to Azure App Service, IIS, or another supported hosting environment.

If the build or tests fail, the pipeline stops before publishing the artifact, preventing a failed build from progressing to deployment.

8. Important Interview Questions

Q1. What is the difference between dotnet build and dotnet publish?

dotnet build compiles the application, whereas dotnet publish prepares the application and its required dependencies for deployment.

Q2. Why do we use --no-restore during build?

Because NuGet packages have already been restored in an earlier step. It avoids performing the restore operation again.

Q3. What happens when unit tests fail?

The test step fails, and subsequent steps normally do not execute. Therefore, the deployment artifact is not published.

Q4. What is the difference between Build Artifacts and Pipeline Artifacts?

Both store build outputs. Pipeline Artifacts are optimized for Azure DevOps Services pipeline workflows, while Build Artifacts provide compatibility with older build and release workflows.

Q5. Can the same artifact be deployed to multiple environments?

Yes. The same artifact can be promoted through SIT, UAT, and Production using environment-specific configuration.

Q6. Does the build pipeline deploy the application?

Not necessarily. A CI pipeline normally builds, tests, and publishes artifacts. Deployment is handled by CD stages, which can also be included in the same multi-stage YAML pipeline.

9. Interview-Ready Answer

In my ASP.NET Core projects, I use Azure DevOps YAML pipelines to automate the CI process. Whenever code is merged into the main branch, the pipeline starts automatically.

First, the pipeline checks out the source code from Azure Repos or GitHub. Then it installs the required .NET SDK, restores NuGet packages, and builds the solution in Release mode.

After a successful build, it executes unit tests to validate the application. Next, it runs dotnet publish to generate the deployable application files and packages them into a ZIP.

Finally, the ZIP is published as a Pipeline Artifact using PublishPipelineArtifact@1. This artifact can then be consumed by the CD pipeline and deployed to SIT, UAT, and Production without rebuilding the application.

Key sequence to remember:

Checkout → SDK → Restore → Build → Test
         → Publish → ZIP → Artifact

This is the standard ASP.NET Core CI build process that you should be able to explain and implement during an Azure DevOps interview.