Как выставлялся Pull Request на PROD

# Как выставлялся Pull Request на PROD

Этот вопрос проверяет ваше понимание процесса развёртывания и управления кодом в production. Расскажу о полном цикле.

Мой рабочий процесс

Фаза 1: Разработка (локально)

1.1. Создание ветки

# Обновляю main
git checkout main
git pull origin main

# Создаю ветку для задачи
git checkout -b feature/add-cart-api
# или
git checkout -b fix/issue-123
# или
git checkout -b chore/update-dependencies

Название ветки отражает тип работы:

• feature/ — новая функция
• fix/ — исправление бага
• chore/ — техдолг, обновление зависимостей
• refactor/ — рефакторинг
• docs/ — документация

1.2. Разработка и коммиты

# Пишу код
# Запускаю тесты локально
mvn test

# Проверяю линтинг
mvn spotbugs:check

# Коммитю
git add .
git commit -m "feat: implement add to cart endpoint"

# Ещё коммиты при необходимости
git add .
git commit -m "test: add integration tests for cart"

git add .
git commit -m "docs: update API documentation"

1.3. Регулярные pull from main

Чтобы избежать конфликтов, периодически обновляю ветку:

git fetch origin
git rebase origin/main
# Если есть конфликты — разрешаю их

Фаза 2: Открытие Pull Request

2.1. Подготовка к PR

# Убедиться, что всё скомпилировалось и тесты пройдены
mvn clean verify

# Отправить ветку на GitHub
git push origin feature/add-cart-api

2.2. Создание PR

Иду на GitHub/GitLab и создаю Pull Request:

Название PR:

feat: add product to cart API endpoint

Описание PR:

## Description
Implements the "Add to Cart" endpoint for the shopping cart feature.

## Changes
- Created CartController with POST /api/v1/carts/items endpoint
- Implemented CartService with business logic
- Added validation for product ID and quantity
- Added comprehensive error handling
- Added unit and integration tests

## Testing
- All unit tests pass: `mvn test`
- All integration tests pass
- Manual testing on localhost:8080

## Related Issue
Closes #123

## Checklist
- [x] Code follows project style guidelines
- [x] Tests added/updated
- [x] Documentation updated
- [x] No breaking changes

2.3. PR обычно линкую на issue

Closes #123
Related to #456

Фаза 3: Code Review

3.1. Автоматические проверки (CI/CD)

ГитHub автоматически запускает:

# .github/workflows/test.yml
name: Tests
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run tests
        run: mvn test
      - name: Code quality
        run: mvn spotbugs:check
      - name: Build
        run: mvn clean package

Если что-то не пройдёт — будет красный крестик. Я исправляю и пушу ещё коммиты.

3.2. Code Review от коллег

Колеги смотрят на PR:

• Правильная ли логика?
• Нет ли потенциальных багов?
• Соответствует ли архитектуре?
• Хорошие ли названия переменных?
• Есть ли better way сделать это?

Они могут оставить комментарии:

💭 Consider using Optional.orElseThrow() instead of traditional check

Я отвечаю и исправляю код.

3.3. Одобрение (Approval)

Когда код хороший — коллега нажимает "Approve".

Обычно нужно:

• 1-2 approval'а от коллег
• Все CI проверки пройдены
• Нет конфликтов с main

Фаза 4: Merge в main

4.1. Merge PR

После утверждения я нажимаю "Merge Pull Request" на GitHub.

Обычно используется стратегия:

• Squash and merge — все коммиты объединяются в один (часто)
• Create a merge commit — создаётся коммит merge'а (иногда)
• Rebase and merge — перебасируется на main (редко)

# Мой выбор обычно:
# Использую squash, чтобы история была чистой

4.2. Автоматический deploy в staging

Обычно после merge'а в main автоматически:

# .github/workflows/deploy-staging.yml
name: Deploy to Staging
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to staging
        run: |
          ./scripts/deploy-staging.sh

Код в staging для финального QA тестирования.

Фаза 5: Deploy на PROD

5.1. Когда готов к production

Не все merge'и идут сразу на production. Может быть:

• Отдельная ветка release/* для версий
• Manual trigger для deploy на prod
• Формальный процесс release (особенно в крупных компаниях)

5.2. Проверки перед prod

Перед deploy на production проверяю:

# Проверить все тесты ещё раз
mvn test -DreuseForks=false

# Проверить покрытие
mvn jacoco:report

# Проверить статический анализ
mvn pmd:check spotbugs:check

# Проверить сборку
mvn clean package -DskipTests

5.3. Способы deploy

Вариант 1: Автоматический deploy via git push (Dokku, Heroku)

# После merge в main, push в special remote
git push dokku main

# или для GitHub Actions
# Автоматически развертывается по schedule или manual trigger

Вариант 2: Docker контейнер

# CI автоматически собирает Docker image
docker build -t myapp:1.2.3 .
docker push myregistry/myapp:1.2.3

# Deploy в Kubernetes
kubectl set image deployment/myapp myapp=myregistry/myapp:1.2.3

Вариант 3: Облачные платформы

# AWS Elastic Beanstalk
eb deploy production

# Google Cloud
gcloud app deploy

# Azure
az webapp deployment source config-zip

5.4. Мониторинг после deploy

# Смотрю логи
docker logs -f myapp

# Проверяю метрики
# Alertmanager / Grafana

# Проверяю APM (Application Performance Monitoring)
# New Relic / DataDog / Sentry

# Если проблемы — быстрый rollback

Пример workflow для моего проекта

# .github/workflows/prod-deploy.yml
name: Production Deploy
on:
  workflow_dispatch:  # Manual trigger
    inputs:
      version:
        description: 'Version to deploy'
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          ref: v${{ github.event.inputs.version }}
      
      - name: Run tests
        run: mvn test
      
      - name: Build
        run: mvn package -DskipTests
      
      - name: Build Docker image
        run: docker build -t myapp:${{ github.event.inputs.version }} .
      
      - name: Push to registry
        run: docker push myregistry/myapp:${{ github.event.inputs.version }}
      
      - name: Deploy to production
        run: |
          # Kubernetes deploy
          kubectl set image deployment/myapp \
            myapp=myregistry/myapp:${{ github.event.inputs.version }}
      
      - name: Verify deployment
        run: |
          curl https://api.example.com/health
          echo "Deployment successful"

Best Practices

1. Отдельная ветка для каждой задачи — не в main разрабатывать
2. Маленькие PR'ы — легче ревьюить, легче откатывать
3. Понятные commits — "fix bug" плохо, "fix null pointer in UserService.getUser()" хорошо
4. Всегда тестировать — перед PR и перед deploy
5. Code review обязателен — даже если я уверен в коде
6. Monitoring после deploy — следить за ошибками и метриками
7. Быстрый rollback — если что-то сломалось, быстро откатить
8. Документировать breaking changes — если что-то изменилось в API

Вывод

Процесс deploy на prod:

1. Создаю ветку и разрабатываю локально
2. Открываю Pull Request с описанием
3. Проходят автоматические проверки (CI)
4. Code review от коллег
5. Merge в main после approval
6. Автоматический deploy в staging
7. Manual или автоматический deploy в production
8. Мониторинг и быстрый rollback при необходимости

Это гарантирует качество и быстрое реагирование на проблемы.