Модели Git-ветвления и CI/CD

В каких веб-проектах нужен Continuous Delivery / Continuous Deployment, а в каких Trunk-Based Development или Release-Driven?

Разберёмся, какие модели Git-ветвления и CI/CD подходят для разных проектов, а затем применим это к двум твоим проектам.

Сравнение моделей разработки

Модель	Описание	Где подходит
Release-Driven (GitFlow)	Редкие, подготовленные релизы, ручное тестирование, стабильность важна	Энтерпрайз, гос. заказ, тяжёлый B2B
Trunk-Based Development	Все работают с короткими ветками или сразу в main, быстрое слияние	Стартапы, фиче-тестирование
Continuous Delivery (CD)	Каждый коммит может быть выкачан в staging/prod после автоматических тестов	SaaS, продукт с частыми обновлениями
Continuous Deployment	Как CD, но ещё автоматически выкатывается на прод без ручной проверки	Только при 100% автоматических тестах

Как выбрать модель?

Подходит GitFlow / Release-driven, если:

• Есть релиз-циклы (раз в неделю/месяц)
• Выкатываешь только проверенный, протестированный код
• Несколько окружений: dev, staging, production
• Нужно чёткое разделение: разработка / тестирование / прод

Подходит Trunk-Based / CD, если:

• Быстро вносишь изменения, обновления частые и небольшие
• Небольшая команда, нет релиз-менеджеров
• Цель — сократить время от кода до продакшена
• Используешь feature flags и хорошее покрытие тестами

---

Анализ твоих проектов

1. Портал по игре Rust

Характеристики:

• Частые изменения: контент, гайды, новости
• Возможны A/B эксперименты
• Обновления, не требующие deploy'а (CMS, API)
• Скорее всего, небольшая команда

Рекомендация:

Trunk-Based Development + Continuous Delivery — быстро вносишь изменения, они проходят через CI → staging → вручную или автоматически на прод.

---

2. Проект хостинговой компании под Rust серверы

Характеристики:

• Ответственность выше: влияет на клиентов, доступность
• Важна стабильность при выкладках
• Возможна интеграция с внешними системами (платёжки, биллинг)
• Нужно staging, QA, контрольный deploy

Рекомендация:

GitFlow (release-driven) или
Trunk-Based + Continuous Delivery, но с ручным deploy на прод

Можно вести разработку в develop, стабилизировать в release/*, или использовать main с ручной проверкой перед выкладкой.

Финальный совет

Проект	Модель	CI/CD
Портал по Rust	Trunk-Based Development	CI → staging → (по кнопке) прод
Хостинг-панель для Rust серверов	Trunk-Based или GitFlow	CI + staging обязательны, прод вручную

---

Ближайшие задачи:

• Настроить .gitlab-ci.yml под оба проекта
• Сформировать шаблоны пайплайнов: staging/prod, авто-теги, docker push и т.п.
• Выяснить best practices по feature flags и rollback'ам

Рекомендации по моделям разработки и CI/CD для проектов с Laravel/Symfony и Vue/React

Ты используешь Laravel или Symfony на бекенде и Vue или React на фронтенде. Вот рекомендации по выбору модели разработки и настройке CI/CD для твоих проектов с таким стеком.

Общие рекомендации

• CI/CD для PHP (Laravel/Symfony): автоматическая сборка, тестирование (PHPUnit, Pest), статический анализ (PHPStan, Psalm), деплой.
• CI/CD для фронтенда (Vue/React): сборка (Webpack, Vite), ESLint, unit и e2e тесты (Jest, Cypress), деплой ассетов.
• Общая стратегия: разделить пайплайны бекенда и фронта, или объединить в один мультистейдж с независимыми шагами.

---

1. Портал по игре Rust (Trunk-Based + Continuous Delivery)

• Ветки: основная ветка main, короткоживущие фичи (feature/*).
• Пайплайн GitLab CI:
• Запуск тестов Laravel (PHPUnit) и фронтенда (Jest/Cypress) на каждом пуше
• Сборка фронтенда (npm run build)
• Деплой на staging-сервер автоматически после успешных тестов
• Деплой на прод вручную по кнопке после проверки
• Использовать feature flags для включения новых функций без выкладки на прод

---

2. Проект хостинговой компании под Rust сервера (GitFlow или Trunk-Based + ручной прод деплой)

• Ветки: develop для разработки, release/* для подготовки релизов, main для стабильных версий.
• Пайплайн GitLab CI:
• Тесты Laravel и фронтенда на ветках feature/* и develop
• Автоматический деплой на staging для веток develop и release/*
• Ручной деплой на прод из main после тестирования и одобрения
• Важна стабильность, поэтому перед релизом обязательны тесты, code review и smoke тестирование на staging

---

Пример базового .gitlab-ci.yml для Laravel + Vue/React

stages:
  - test
  - build
  - deploy

variables:
  APP_ENV: testing

cache:
  paths:
    - vendor/
    - node_modules/

phpunit:
  image: php:8.2
  stage: test
  services:
    - mysql:latest
  before_script:
    - apt-get update && apt-get install -y unzip git curl libzip-dev
    - docker-php-ext-install zip pdo pdo_mysql
    - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
    - composer install --no-interaction --prefer-dist
    - cp .env.testing .env
    - php artisan key:generate
    - php artisan migrate --env=testing
  script:
    - ./vendor/bin/phpunit --coverage-text
  only:
    - branches

frontend_test:
  image: node:18
  stage: test
  script:
    - npm ci
    - npm run lint
    - npm run test
  only:
    - branches

build_frontend:
  image: node:18
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
  only:
    - branches

deploy_staging:
  stage: deploy
  script:
    - echo "Deploying to staging server..."
    # команды деплоя, например rsync или ssh
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - develop
    - feature/*

deploy_production:
  stage: deploy
  when: manual
  script:
    - echo "Deploying to production server..."
    # команды деплоя
  environment:
    name: production
    url: https://example.com
  only:
    - main

Изображение от pikisuperstar на Freepik