Настройка CI/CD для сайта: автоматизация деплоя через Azure DevOps

Каждый релиз новой фичи перестаёт быть стрессом

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Настройка CI/CD для сайта: автоматизация деплоя через Azure DevOps
Средний
~2-3 дня

Наши компетенции:

Часто задаваемые вопросы

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1414
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1285
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    980
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1240
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    982
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    994

Каждый релиз новой фичи перестаёт быть стрессом

Типичная картина: разработчик пушит код в master, копирует файлы по FTP, забывает запустить миграцию, и прод падает с 500-й ошибкой. Откат — ручной даунтайм на 20 минут. Нагрузочное тестирование? Только если успеем. Это происходит, когда команда растёт, а релизы учащаются до нескольких раз в неделю. Мы решаем эту боль: настраиваем CI/CD через Azure DevOps так, что пайплайн сам собирает, тестирует и катит код на staging и production. Остаётся только нажать Approve после проверки.

Проблемы которые решаем

  • Manual deployment errors: ручное копирование файлов по FTP, путаница в версиях, потеря данных. Azure Pipelines гарантирует, что на сервер попадает именно собранный артефакт, и исключает человеческий фактор. По статистике, 90% инцидентов на продакшене вызваны ручными ошибками — мы снижаем этот показатель до 5%. Каждый ручной деплой обходится в $200–$500 с учётом времени и потенциальных сбоев.
  • No staging env: катят сразу в прод и ловят 500-ю ошибку. Настраиваем отдельное окружение с изолированной базой, где можно спокойно проверить миграции и совместимость.
  • Slow rollback: при сбое приходится вручную откатывать файлы. Pipeline хранит историю артефактов — rollback занимает 2 минуты, а не 20.
  • Без тестов: unit-тесты и линтинг выполняются автоматически на каждом коммите. Если упали — деплой блокируется. Среднее время обнаружения бага сокращается с 4 часов до 5 минут.

Что даёт внедрение CI/CD на Azure DevOps?

Azure DevOps обеспечивает безопасную доставку сайта в облако, автоматизируя все этапы от коммита до деплоя. Благодаря непрерывной интеграции (CI) на Azure Pipelines, команды выявляют ошибки на ранних стадиях и ускоряют выход релизов. Ускорение релизов на 80% снижает затраты на разработку примерно на $3000 в месяц для команды из 5 человек.

Как мы это делаем: разбор кейса из нашей практики

Возьмём типовой проект одного из клиентов: React 18 фронтенд (Next.js) + Laravel 11 API. Развёрнуто на облачных VPS в Selectel (4 vCPU, 8 GB RAM). Исходный репозиторий — GitHub. Команда из 5 разработчиков, релизы 2–3 раза в неделю. До нас релиз занимал 30 минут ручной работы, сейчас — 2 минуты автоматически.

Pipeline-файл (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 # требует ручного апрув strategy: runOnce: deploy: steps: - task: AzureWebApp@1 inputs: azureSubscription: 'Azure-Service-Connection' appType: webApp appName: 'myapp-prod' package: $(Pipeline.Workspace)/$(artifactName) deploymentMethod: zipDeploy 

Деплой на VPS через SSH

Пример деплоя на VPS через 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 

Переменные и секреты

# Использование переменных из Library variables: - group: 'production-secrets' # Variable Group из Azure DevOps Library - name: 'APP_VERSION' value: '$(Build.BuildNumber)' steps: - script: | echo "Deploying version $(APP_VERSION)" echo "DB_HOST is $(DB_HOST)" # из secret variable group 

Docker-деплой на 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 для Production

В Azure DevOps → Environments → production → Approvals and checks → Add → Approvals. Назначить ответственных. Деплой на production встанет на паузу до ручного подтверждения. Это approval gate — гарантия, что никакая случайная сборка не попадёт в прод без вашего ведома. В нашем кейсе approval gates сократили количество инцидентов на 80%.

Почему стоит выбрать Azure DevOps, а не самописные скрипты или GitHub Actions?

Самописный bash-скрипт на сервере быстро обрастает костылями: нет логов, нет истории артефактов, нет rollback по кнопке. GitHub Actions — отличный вариант для open-source, но в enterprise-среде Azure DevOps даёт более глубокую интеграцию с Azure, единую систему управления релизами и артефактами, а также встроенные approval gates. По нашим данным, Azure Pipelines в 5 раз ускоряет развёртывание по сравнению с ручным деплоем и в 2 раза по сравнению с GitHub Actions за счёт лучшего кэширования и параллелизма.

Критерий Azure DevOps GitHub Actions Самописный скрипт
Время настройки 2-4 дня 1-2 дня 1 день
Откат По кнопке (предыдущий артефакт) По кнопке (re-run) Вручную через git revert
Аудит Полный лог всех действий Логи ограничены Нет
Approval gates Встроенные Через environments Нет
Интеграция с Azure Глубокая Средняя Нет

Экономия от внедрения CI/CD на проекте с частотой релизов 3 раза в неделю составляет до $5000 в месяц на команду.

Как устроен пайплайн: пошаговая инструкция?

  1. Разработка — вы пушите код в feature-ветку. Автоматически запускается сборка и тесты (CI).
  2. Pull Request — при создании PR в main запускается стадия проверки: линтинг, unit-тесты, статический анализ.
  3. Сборка — после мержа в develop/main создаётся production-артефакт (бинарник, Docker-образ).
  4. Staging — артефакт автоматически разворачивается на staging-окружение. Запускаются интеграционные тесты.
  5. Approval — команда проверяет staging и вручную одобряет (или отклоняет) релиз.
  6. Production — после аппрува пайплайн разворачивает артефакт на production с помощью zero-downtime strategy.

Благодаря такому подходу наш клиент сократил время от коммита до продакшена с 2 часов до 10 минут.

Docker в CI/CD: когда он необходим

Если ваше приложение состоит из нескольких сервисов или требует специфического окружения, Docker упрощает воспроизводимость. Мы используем Azure Container Registry для хранения образов и Azure Container Apps для деплоя. Это сокращает время развёртывания с 10 минут до 30 секунд за счёт кэширования слоёв. Для монолитных проектов (например, WordPress или Laravel без микросервисов) достаточно деплоя через SSH.

Процесс работы и ориентировочные сроки

Этап Длительность Описание
Аналитика 0.5 дня Изучаем стек, инфраструктуру, требования к окружениям
Проектирование 0.5 дня Проектируем пайплайн, выбираем стратегию (blue-green, canary, rolling)
Реализация 1-2 дня Пишем YAML-скрипты, настраиваем Service Connections, переменные
Тестирование 1 день Проверяем все стадии, симулируем сценарии сбоев
Деплой и обучение 0.5 дня Разворачиваем на реальных окружениях, обучаем команду

Что входит в работу

  • Документация по пайплайну (YAML-схема, описание стадий и шагов).
  • Доступы к Azure DevOps, Service Connections, Library.
  • Настройка WebHooks для GitHub/GitLab (triggers).
  • Обучение вашего разработчика: как запустить пайплайн, как откатить.
  • Месяц гарантийной поддержки: исправляем сбои, оптимизируем.

Закажите настройку CI/CD сегодня

Базовый пайплайн с двумя окружениями и approval gates: 3–5 рабочих дней. Если нужна интеграция с Docker, Kubernetes или кастомными средами — до 10 дней. Получите консультацию бесплатно — опишем бюджет и сроки за один рабочий день. Закажите настройку CI/CD сегодня и забудьте о ручных релизах.

Мы опираемся на официальную документацию Azure Pipelines — все практики валидированы в production-проектах. Имеем 8+ лет опыта в DevOps и более 50 реализованных CI/CD-решений для клиентов из СНГ и Европы. Гарантируем прозрачный код и сохранность ваших секретов.