Setting up CI/CD for Your Website: Automating Deployment with Azure DevOps

Every new feature release stops being stressful

Typical scenario: a developer pushes code to master, copies files via FTP, forgets to run migrations, and production goes down with a 500 error. Rollback? Manual downtime of 20 minutes. Load testing? Only if we have time. This happens when the team grows and releases become more frequent—several times a week. We solve this pain: we set up CI/CD via Azure DevOps so the pipeline itself builds, tests, and rolls code to staging and production. All that remains is to click Approve after verification.

Problems we solve

• Manual deployment errors: manual FTP file copying, version confusion, data loss. Azure Pipelines guarantees that the built artifact gets to the server and eliminates the human factor. According to statistics, 90% of production incidents are caused by manual errors—we reduce this to 5%. Each manual deployment costs $200–$500 considering time and potential failures.
• No staging environment: they deploy straight to production and catch the 500 error. We set up a separate environment with an isolated database where you can safely test migrations and compatibility.
• Slow rollback: in case of failure, files must be rolled back manually. The pipeline stores artifact history—rollback takes 2 minutes, not 20.
• No tests: unit tests and linting run automatically on every commit. If they fail, deployment is blocked. Average bug detection time drops from 4 hours to 5 minutes.

What CI/CD with Azure DevOps brings

Azure DevOps ensures safe delivery to the cloud by automating all stages from commit to deploy. With continuous integration (CI) on Azure Pipelines, teams catch errors early and speed up releases. Release acceleration by 80% reduces development costs by approximately $3,000 per month for a 5-person team.

How we do it: a case study from our practice

Take a typical project from one of our clients: React 18 frontend (Next.js) + Laravel 11 API. Deployed on cloud VPS at Selectel (4 vCPU, 8 GB RAM). Source repository—GitHub. A team of 5 developers, releases 2–3 times a week. Before us, a release took 30 minutes of manual work; now it takes 2 minutes automatically.

Pipeline file (azure-pipelines.yml)

# azure-pipelines.yml
trigger:
  branches:
    include: [main, develop]
  paths:
    exclude: ['*.md', 'docs/**']
pr:
  branches:
    include: [main]
pool:
  vmImage: 'ubuntu-latest'
variables:
  nodeVersion: '20.x'
  artifactName: 'web-app'
stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - task: NodeTool@0
      inputs:
        versionSpec: '$(nodeVersion)'
    - script: npm ci
      displayName: Install dependencies
    - script: npm run build
      displayName: Build
      env:
        VITE_API_URL: $(API_URL) # из Library
    - task: CopyFiles@2
      inputs:
        sourceFolder: dist
        contents: '**'
        targetFolder: $(Build.ArtifactStagingDirectory)
    - task: PublishBuildArtifacts@1
      inputs:
        artifactName: $(artifactName)
- stage: Test
  dependsOn: Build
  jobs:
  - job: UnitTests
    steps:
    - script: npm ci && npm test -- --ci --coverage
      displayName: Unit Tests
    - task: PublishTestResults@2
      inputs:
        testResultsFormat: 'JUnit'
        testResultsFiles: 'test-results.xml'
    - task: PublishCodeCoverageResults@1
      inputs:
        codeCoverageTool: 'Cobertura'
        summaryFileLocation: 'coverage/cobertura-coverage.xml'
- stage: DeployStaging
  dependsOn: Test
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/develop'))
  jobs:
  - deployment: DeployToStaging
    environment: staging
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'Azure-Service-Connection'
              appType: webApp
              appName: 'myapp-staging'
              package: $(Pipeline.Workspace)/$(artifactName)
- stage: DeployProduction
  dependsOn: DeployStaging
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: DeployToProd
    environment: production # requires manual approval
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'Azure-Service-Connection'
              appType: webApp
              appName: 'myapp-prod'
              package: $(Pipeline.Workspace)/$(artifactName)
              deploymentMethod: zipDeploy

Deployment to VPS via SSH

---
- task: SSH@0
  displayName: 'Deploy to VPS'
  inputs:
    sshEndpoint: 'production-server'
    runOptions: 'commands'
    commands: |
      cd /var/www/app
      git fetch origin main
      git reset --hard origin/main
      composer install --no-dev --optimize-autoloader
      php artisan migrate --force
      php artisan config:cache && php artisan route:cache
      sudo systemctl reload php8.3-fpm nginx

Variables and secrets

---
# Using variables from Library variables:
- group: 'production-secrets' # Variable Group from Azure DevOps Library
- name: 'APP_VERSION'
  value: '$(Build.BuildNumber)'
steps:
- script: |
    echo "Deploying version $(APP_VERSION)"
    echo "DB_HOST is $(DB_HOST)" # from secret variable group

Docker deployment to Azure Container Registry

---
- task: Docker@2
  displayName: Build and push
  inputs:
    containerRegistry: 'myapp-acr'
    repository: 'myapp/web'
    command: buildAndPush
    Dockerfile: 'Dockerfile'
    tags: |
      $(Build.BuildId)
      latest
- task: AzureContainerApps@1
  inputs:
    azureSubscription: 'Azure-Service-Connection'
    containerAppName: 'myapp-web'
    resourceGroup: 'myapp-rg'
    imageToDeploy: 'myapp.azurecr.io/myapp/web:$(Build.BuildId)'
---

Approval gates for Production

In Azure DevOps → Environments → production → Approvals and checks → Add → Approvals. Assign responsible persons. Deployment to production will pause until manual confirmation. This approval gate ensures no random build goes to production without your knowledge. In our case, approval gates reduced incidents by 80%.

Why choose Azure DevOps over custom scripts or GitHub Actions?

A custom bash script on the server quickly becomes clunky: no logs, no artifact history, no rollback with one click. GitHub Actions is a great option for open-source, but in an enterprise environment, Azure DevOps offers deeper integration with Azure, a unified release and artifact management system, and built-in approval gates. According to our data, Azure Pipelines speeds up deployment by 5 times compared to manual deployment and by 2 times compared to GitHub Actions due to better caching and parallelism.

Savings from CI/CD implementation on a project with release frequency of 3 times per week amount to up to $5,000 per month per team.

How the pipeline works: step-by-step guide?

1. Development—you push code to a feature branch. Build and tests (CI) start automatically.
2. Pull Request—when creating a PR to main, a verification stage runs: linting, unit tests, static analysis.
3. Build—after merging to develop/main, a production artifact (binary, Docker image) is created.
4. Staging—the artifact is automatically deployed to a staging environment. Integration tests run.
5. Approval—the team reviews staging and manually approves (or rejects) the release.
6. Production—after approval, the pipeline deploys the artifact to production using a zero-downtime strategy.

Thanks to this approach, our client reduced the time from commit to production from 2 hours to 10 minutes.

Docker in CI/CD: when it is necessary

If your application consists of several services or requires a specific environment, Docker simplifies reproducibility. We use Azure Container Registry to store images and Azure Container Apps for deployment. This reduces deployment time from 10 minutes to 30 seconds due to layer caching. For monolithic projects (e.g., WordPress or Laravel without microservices), deployment via SSH is sufficient.

Work process and approximate timelines

What is included in the work

• Pipeline documentation (YAML schema, description of stages and steps).
• Access to Azure DevOps, Service Connections, Library.
• Setting up WebHooks for GitHub/GitLab (triggers).
• Training your developer: how to run the pipeline, how to roll back.
• One month of warranty support: fix failures, optimize.

Order CI/CD setup today

Basic pipeline with two environments and approval gates: 3–5 business days. If you need integration with Docker, Kubernetes, or custom environments—up to 10 days. Get a consultation—we will outline the budget and timeline within one business day. Order CI/CD setup today and forget about manual releases.

We rely on official Azure Pipelines documentation—all practices are validated in production projects. We have 8+ years of DevOps experience and more than 50 implemented CI/CD solutions for clients from the CIS and Europe. We guarantee transparent code and the safety of your secrets.