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 free 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.

We regularly encounter a situation: "The site is not opening" at 3 a.m. — and it turns out that the VPS disk is full because nginx logs haven't been rotated for six months. Or the server went down under load on the day of an advertising campaign launch because the shared hosting had a limit of 50 concurrent connections. Setting up hosting and deployment is not about "where it's cheaper" but about what happens when something goes wrong. Our team helps avoid such incidents by designing infrastructure that accounts for real load patterns.

When to choose Vercel and Netlify?

Vercel is built for Next.js — deploy in one push, preview deployments for every PR, automatic CDN, Edge Functions, ISR without configuration. For frontend projects and JAMstack, it's the optimal choice: no operational overhead, time-to-deploy measured in minutes.

Real limitations: Vercel Serverless Functions run in us-east-1 by default (latency for Europe +80–100ms), Function timeout 300 seconds on Pro, Bandwidth 1TB/month on Pro. For heavy backend, you need workers or a separate server.

Netlify is closer to static sites and Edge Functions based on Deno Deploy. Build minutes are the main limitation on the free tier.

Why is Docker the foundation of predictable deployment?

"It works on my machine" — classic. Docker solves this through environment containerization. But a bad Dockerfile creates new problems.

A typical mistake: copying everything into the image without .dockerignore, resulting in an 800MB image instead of 80MB. node_modules inside the image weighs as much. Correct approach: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Final image: 180MB instead of 1.2GB. CI build time is reduced due to layer caching — if package.json hasn't changed, the layer with npm ci is taken from cache.

Docker Compose for local development and simple production scenarios: application + PostgreSQL + Redis in one configuration. For production on a single server, it's a perfectly viable option if there's no requirement for horizontal scaling.

More about containerization — Wikipedia: Docker.

How to set up Nginx as a reverse proxy?

Nginx in front of the application is standard for VPS and dedicated servers. Main functions: SSL termination, gzip, static files, rate limiting, upstream load balancing.

A configuration often done incorrectly: worker_processes auto — number of processes equals CPU count. worker_connections 1024 — that's 1024 per worker process. With 4 CPUs and 1024 connections = 4096 concurrent connections. For a high-traffic site, you need worker_connections 4096 and set keepalive_timeout 65.

For static assets with hash in the filename:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable tells the browser: don't revalidate this file even on hard refresh. This only works correctly with content-hashed filenames (which Vite/webpack do by default). Documentation — Wikipedia: Nginx.

AWS: flexibility and complexity

EC2 + Auto Scaling Group — classic for horizontal scaling. AMI with pre-installed application, Launch Template, ASG with min/desired/max instances, Application Load Balancer. When CPU > 70% for 3 minutes — scale out, when CPU < 30% for 15 minutes — scale in. Health check via ALB removes unhealthy instances from rotation.

ECS Fargate — containers without managing EC2. Deploy a Docker image, specify CPU/memory (512 CPU units = 0.5 vCPU, from 512MB memory), Fargate launches it. More expensive than Lambda, but no cold start and no timeout limitations. Suitable for long-running processes, WebSocket servers, heavy workers.

RDS for PostgreSQL with Multi-AZ: automatic failover in 1–2 minutes when primary fails. Read Replicas for scaling reads. RDS Proxy for connection pooling — Lambda functions cannot hold long-term connections, the proxy buffers this.

Kubernetes: when it is justified

K8s adds significant operational complexity. Justified when: multiple teams deploy independent services, fine-grained resource allocation per service is needed, canary deployments and blue/green without downtime are required.

AWS EKS, GKE, or managed k8s from Hetzner (cheaper). Helm charts for standard services. Horizontal Pod Autoscaler based on CPU and custom metrics (RPS via Prometheus).

For most startups and medium-sized projects, Kubernetes is overkill. ECS or Fly.io provide 80% of the capabilities with 20% of the operational complexity.

Monitoring and alerting

A server without monitoring is waiting for an incident. Minimal stack: Prometheus + Grafana (or Grafana Cloud for managed), alerting on disk > 80%, memory > 85%, CPU > 90% over 5 minutes, error rate > 1%. Uptime via Better Uptime or Upptime (self-hosted).

Logs: Loki + Grafana or CloudWatch Logs Insights. Structured JSON logs (winston, pino) are mandatory — otherwise, log searching becomes a pain.

What is included in hosting setup

• Audit of current infrastructure and load profiling
• Selection of target architecture (VPS, AWS, serverless, Kubernetes)
• Setting up CI/CD pipeline (GitHub Actions, GitLab CI) with automatic deployment
• IaC via Terraform or Pulumi (infrastructure as code)
• Configuration of Nginx, SSL certificates, HTTP/2, brotli
• Monitoring and alerting (Prometheus + Grafana, PagerDuty)
• Documentation of runbooks and team training

Additionally, contact us if you need migration from current hosting or integration with external services.

Work process

1. Audit of current infrastructure (2–5 days)
2. Selection of target architecture with load and budget justification (1–3 days)
3. Setting up CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 days)
4. IaC via Terraform or Pulumi (3–10 days)
5. Setting up monitoring and alerting (2–5 days)
6. Documentation of runbooks and team training (1–3 days)

Our experience — 7 years on the market, over 50 projects, guarantee of operability after deployment.

Timeline

• Basic deployment on VPS with Docker + Nginx + CI/CD: 1–2 weeks.
• Setting up AWS infrastructure with Auto Scaling, RDS, CDN: 3–6 weeks.
• Migration to EKS from scratch: 6–12 weeks.
• Setting up Vercel/Netlify for JAMstack: 3–5 days.

The cost is calculated individually depending on complexity and scope of work. Get a consultation — we'll evaluate your architecture in one day.