Как происходил процесс деплоя на работе?

Процесс деплоя на моих предыдущих проектах

На моих проектах мы использовали CI/CD-пайплайны (Continuous Integration / Continuous Deployment), которые были настроены в GitLab CI/CD и GitHub Actions. Основной принцип — автоматизация всех этапов от коммита кода до его попадания на продакшен-серверы.

Основные этапы пайплайна:

1. Тестирование: После каждого пуша в репозиторий автоматически запускался набор тестов.

   # Пример секции тестирования в .gitlab-ci.yml
   stages:
     - test
   phpunit:
     stage: test
     script:
       - composer install --no-dev
       - ./vendor/bin/phpunit --testsuite=unit
       - ./vendor/bin/phpunit --testsuite=integration
   

2. Сборка артефакта: Создание готового к деплою пакета — обычно Docker-образа.

   # Dockerfile для PHP-приложения
   FROM php:8.2-fpm-alpine
   WORKDIR /var/www/html
   COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
   COPY . .
   RUN composer install --no-dev --optimize-autoloader
   RUN chown -R www-data:www-data /var/www/html
   

3. Деплой на стейджинг: Автоматическое обновление тестового окружения.

   deploy_staging:
     stage: deploy
     environment:
       name: staging
     script:
       - kubectl set image deployment/myapp php=registry.gitlab.com/group/project:$CI_COMMIT_SHA
     only:
       - develop
   

Стратегии деплоя:

Мы использовали синий-зеленый деплоймент (blue-green deployment) и canary-релизы для минимизации даунтайма и рисков:

• Blue-Green: Две идентичные продакшен-среды. Пока "синяя" активна, на "зеленой" разворачивается новая версия. После тестирования трафик переключается на "зеленую" среду.
• Canary: Новая версия разворачивается на небольшом проценте продакшен-серверов (например, 5%), затем постепенно на всех остальных после мониторинга метрик.

Ключевые практики и инструменты:

• Infrastructure as Code: Конфигурация серверов через Ansible или Terraform.
• Контейнеризация: Все приложения работали в Docker-контейнерах, оркестрировались через Kubernetes.
• Мониторинг и откат: После деплоя автоматически отслеживались метрики (Prometheus/Grafana), логи (ELK-стек). При обнаружении аномалий (рост 5xx ошибок, падение RPS) мог сработать автоматический откат.
• Миграции БД: Выполнялись через Liquibase или встроенные миграции Laravel/Symfony как часть пайплайна, но всегда с созданием бэкапа и возможностью отката.

  // Пример миграции Laravel
  public function up()
  {
      Schema::create('users', function (Blueprint $table) {
          $table->id();
          $table->string('email')->unique();
          $table->timestamps();
      });
  }
  
  public function down()
  {
      Schema::dropIfExists('users');
  }
  

Ручные проверки и согласования:

Несмотря на высокую степень автоматизации, обязательными оставались:

• Code Review перед мержем в основную ветку
• Ручное тестирование на стейджинге для критических функциональностей
• Согласование деплоя на продакшен во время "окон развертывания" (обычно в ночное время с минимальной нагрузкой)

Такой подход обеспечивал стабильность продакшена, скорость доставки изменений (десятки деплоев в день) и безопасность процесса.