Что происходит при релизе GitLab Flow?

Что происходит при релизе GitLab Flow

GitLab Flow — это методология работы с ветками git, которая является промежуточным вариантом между Git Flow и простой Feature Branch workflow. Понимание процесса релиза критично для организации эффективной разработки в современных командах.

Основные компоненты GitLab Flow

Ветки в GitLab Flow

GitLab Flow использует следующую структуру веток:

• main (master) — основная ветка, всегда готова к продакшену
• production — опциональная ветка для стабильного продакшена (если требуется)
• feature ветки — ветки для разработки новых функций
• environment ветки — staging, pre-production ветки (опционально)

Процесс релиза на разных уровнях

Сценарий 1: Simple GitLab Flow (без production ветки)

1. Разработчик создает feature ветку из main:
   git checkout -b feature/add-authentication
   
2. Работает над функцией, делает коммиты:
   git commit -m "Add login handler"
   git commit -m "Add JWT validation"
   
3. Создает Merge Request в main:
   git push origin feature/add-authentication
   # Открывает MR в GitLab UI
   
4. Code Review и обсуждение в MR
   
5. При одобрении разработчик или мейнтейнер merges MR
   
6. GitLab запускает CI/CD pipeline:
   - Запуск тестов
   - Линтинг кода
   - Билд артефактов
   - Автоматический deploy в production

Сценарий 2: GitLab Flow с production веткой

main (development) → staging → production
      ↑                              ↑
      |                              |
   feature ветки              релизные коммиты

Процесс:

# Шаг 1: Обычная разработка на feature ветках
git checkout -b feature/new-api
# Работа, коммиты
git push origin feature/new-api
# MR в main

# Шаг 2: После merge в main
# CI/CD автоматически:
# - Запускает тесты
# - Деплоит в staging окружение
# - Запускает e2e тесты

# Шаг 3: Когда готово к production релизу:
git tag v1.2.3  # Создается git tag
git push origin v1.2.3

# Шаг 4: Через production ветку:
git checkout production
git merge --ff-only main
git push origin production

# Шаг 5: CI/CD pipeline для production:
# - Запуск финальных проверок
# - Deploy в production
# - Smoke тесты
# - Оповещение команды

Детальное описание этапов релиза

1. Инициирование релиза

Релиз начинается когда:

• Завершены необходимые features
• Все тесты проходят в main
• Проведен code review
• Версия залогирована в CHANGELOG

# Типичный GitLab CI конфиг для releasе
stages:
  - test
  - build
  - deploy_staging
  - deploy_production
  - notify

test_job:
  stage: test
  script:
    - pip install -r requirements.txt
    - pytest --cov
    - flake8 .

build_artifact:
  stage: build
  script:
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA .
    - docker push myapp:$CI_COMMIT_SHORT_SHA
  only:
    - main

deploy_staging:
  stage: deploy_staging
  script:
    - kubectl set image deployment/myapp myapp=myapp:$CI_COMMIT_SHORT_SHA --record
  environment:
    name: staging
  only:
    - main

deploy_production:
  stage: deploy_production
  script:
    - kubectl set image deployment/myapp myapp=myapp:$CI_COMMIT_SHORT_SHA --record
  environment:
    name: production
  only:
    - production
  when: manual

2. Версионирование

# setup.py или pyproject.toml
version = "1.2.3"

# CHANGELOG.md
## [1.2.3] - 2024-03-22
### Added
- New authentication system
- API rate limiting

### Fixed
- Fixed memory leak in worker threads
- Corrected timezone handling

3. Тестирование перед релизом

# Smoke тесты перед production
import requests

class SmokeTests:
    def test_api_health(self):
        response = requests.get("https://api.example.com/health")
        assert response.status_code == 200
    
    def test_critical_endpoints(self):
        endpoints = [
            "/api/v1/users",
            "/api/v1/products",
            "/api/v1/orders"
        ]
        for endpoint in endpoints:
            response = requests.get(f"https://api.example.com{endpoint}")
            assert response.status_code == 200
    
    def test_database_connectivity(self):
        # Проверка соединения с БД
        response = requests.post("https://api.example.com/debug/db-check")
        assert response.json()["status"] == "ok"

4. Развертывание в production

# Актуальный процесс при merged в production ветку:

# 1. GitLab CI/CD детектирует push в production
# 2. Запускается deploy job с правами
# 3. Rolling update новой версии
# 4. Health checks проверяют старт сервисов
# 5. Gradual rollout (if configured)

# Пример с канарейным релизом
kubectl set image deployment/myapp myapp=myapp:1.2.3 \
  --record && \
kubectl rollout status deployment/myapp

5. Мониторинг после релиза

# Метрики которые отслеживаются
metrics = {
    "error_rate": "должна быть < 0.1%",
    "response_time": "должно быть < 500ms",
    "cpu_usage": "должно быть < 70%",
    "memory_usage": "должно быть < 80%",
    "failed_requests": "должны отсутствовать"
}

Ключевые различия от Git Flow

Best Practices для релизов

1. Автоматизация

• Весь процесс должен быть в GitLab CI
• Минимум ручных шагов -롤백автоматизирован

2. Версионирование

• Следовать Semantic Versioning (MAJOR.MINOR.PATCH)
• Обновлять CHANGELOG
• Создавать git tags

3. Мониторинг

• Health checks перед finalization
• Метрики production окружения
• Алерты при аномалиях

4. Rollback Strategy

# Быстрый откат при проблемах
git revert <commit-hash>
git push origin production
# или
kubectl rollout undo deployment/myapp

Заключение

При релизе в GitLab Flow:

1. Feature ветка → main (через MR)
2. Автоматический deploy в staging
3. Manual trigger для production
4. Production ветка merged из main
5. Автоматический deploy в production
6. Мониторинг и готовность к rollback

Это позволяет команде быстро доставлять функции при сохранении стабильности production.