Restrict who can deploy to Production

1. How do you restrict who can deploy to Production?

In Azure DevOps, we restrict Production deployment using Permissions, Approvals, and Checks.

How does it work?

1. Create a Production Environment in Azure DevOps.

2. Configure Approvals and Checks.

3. Add authorized approvers, such as the Release Manager or Tech Lead.

4. Restrict which users and pipelines can access the Production environment.

5. Deployment proceeds only after the required approval.

Example:

Build Completed
      ↓
Deploy to DEV
      ↓
Deploy to SIT
      ↓
Deploy to UAT
      ↓
Production Deployment Requested
      ↓
Approval Required
      ↓
Release Manager Approves
      ↓
Deploy to Production

Interview Answer:

We restrict Production deployments using Azure DevOps Environment permissions, pipeline permissions, and approval checks. Only authorized users can approve deployments, and only permitted pipelines can deploy to Production.

2. How do you handle a failed deployment and roll back to a previous successful version?

Rollback means restoring the previous working version of an application when a new deployment fails.

How does it work?

1. Deploy the new version to Production.

2. If deployment fails, stop the release or further rollout.

3. Identify the last successful build artifact.

4. Redeploy that previous artifact to Production.

5. Verify the application is working using health checks and testing.

Example:

Production: Version 1.0 (Working)
            ↓
Deploy Version 2.0
            ↓
Deployment Failed
            ↓
Select Previous Successful Artifact
            ↓
Redeploy Version 1.0
            ↓
Verify Application
            ↓
Production Restored

How to do it in Azure DevOps?

1. Open Azure DevOps → Pipelines.

2. Find the previous successful pipeline run.

3. Select its deployment stage and redeploy the previous artifact, using the pipeline's supported rerun or redeployment process.

4. Verify the Production application.

Important: In Azure App Service, we can also use Deployment Slots to swap back to the previous version, provided the previous version remains available in the other slot.

Interview Answer:

If a Production deployment fails, I identify the last successful build artifact and redeploy it using Azure Pipelines. After rollback, I verify application health and functionality. For Azure App Service, deployment slots can also support quick rollback.

Key Point: Always use the same previously tested build artifact for rollback instead of rebuilding the old source code. Database changes may require a separate rollback or recovery plan.