Какой для тебя самый идеальный процесс CI/CD?

Идеальный процесс CI/CD для Java разработчика

Это субъективный вопрос, и важно объяснить свою позицию, обосновав её практическими соображениями. Вот мой идеальный процесс на основе 10+ лет опыта.

1. Локальная разработка

Всё начинается до push'а в репозиторий:

# Разработчик работает локально
git checkout -b feature/user-authentication

# Перед commit'ом:
make lint          # Linter (Checkstyle, PMD, SpotBugs)
make format        # Code formatter (Google Java Format)
make test          # Unit тесты с coverage > 90%
make test:integration # Integration тесты

# Если всё зелено, только тогда commit
git commit -m "feat: implement JWT authentication"

Это самое важное: рано ловить проблемы.

2. Pre-push checks (Git hooks)

# .git/hooks/pre-push
#!/bin/bash
set -e

echo "Running pre-push checks..."
make lint
make test
make build

# Если что-то упало — push не произойдёт
echo "All checks passed!"

Одновременно:

• Статический анализ кода (SonarQube, Checkstyle)
• Проверка зависимостей (OWASP Dependency Check)
• Code style (Prettier, Spotless)

3. CI Pipeline (при push'е в репозиторий)

Удеал для Java проекта (GitHub Actions / GitLab CI / Jenkins):

name: CI/CD Pipeline

on:
  push:
    branches: [main, develop, "feature/**"]
  pull_request:
    branches: [main, develop]

jobs:
  # Стадия 1: Компиляция и анализ
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-java@v3
        with:
          java-version: '21'
          
      # Кэширование Maven зависимостей
      - uses: actions/cache@v3
        with:
          path: ~/.m2
          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
          
      - run: mvn clean compile -q
      - run: mvn spotbugs:check -q
      - run: mvn checkstyle:check -q
  
  # Стадия 2: Тесты
  test:
    needs: build
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:15
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        env:
          POSTGRES_PASSWORD: testpass
    
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-java@v3
        with:
          java-version: '21'
      
      # Unit тесты
      - run: mvn test -q --tb=short
      
      # Integration тесты в изолированной БД
      - run: mvn verify -q -Dgroups=integration
      
      # Coverage отчёт
      - run: mvn jacoco:report -q
      - uses: codecov/codecov-action@v3
        with:
          file: ./target/site/jacoco/jacoco.xml
          fail_ci_if_error: true
          min-coverage: 90
  
  # Стадия 3: Безопасность
  security:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: dependency-check/Dependency-Check_Action@main
        with:
          project: 'My Java App'
          path: '.'
          format: 'CSV'
      
      # Проверка уязвимостей
      - run: mvn org.owasp:dependency-check-maven:check -q
  
  # Стадия 4: SonarQube анализ
  sonar:
    needs: [test, security]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-java@v3
        with:
          java-version: '21'
      
      - run: mvn sonar:sonar -q \
              -Dsonar.projectKey=my-app \
              -Dsonar.host.url=${{ secrets.SONAR_HOST_URL }} \
              -Dsonar.login=${{ secrets.SONAR_TOKEN }}
      
      # Fail if quality gate failed
      - name: Check SonarQube Quality Gate
        run: |
          status=$(curl -s -u ${{ secrets.SONAR_TOKEN }}: \
            ${{ secrets.SONAR_HOST_URL }}/api/qualitygates/project_status?projectKey=my-app \
            | jq '.projectStatus.status')
          [ "$status" = '"OK"' ] || exit 1

  # Стадия 5: Build Docker образа
  docker-build:
    needs: sonar
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' || github.ref == 'refs/heads/develop'
    
    steps:
      - uses: actions/checkout@v3
      - uses: docker/setup-buildx-action@v2
      
      - name: Build Docker image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} myapp:latest
      
      - name: Push to registry
        run: |
          docker push myapp:${{ github.sha }}
          docker push myapp:latest
  
  # Стадия 6: E2E тесты
  e2e:
    needs: docker-build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' || github.ref == 'refs/heads/develop'
    
    services:
      app:
        image: myapp:${{ github.sha }}
        ports:
          - 8080:8080
    
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - run: npm ci --prefix tests/e2e
      - run: npm run test:e2e -- --baseURL=http://localhost:8080
      
      - uses: actions/upload-artifact@v3
        if: failure()
        with:
          name: playwright-report
          path: tests/e2e/playwright-report/
  
  # Стадия 7: Deployment на staging
  deploy-staging:
    needs: e2e
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/develop'
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Deploy to staging
        run: |
          kubectl set image deployment/myapp \
            myapp=myapp:${{ github.sha }} \
            -n staging
          kubectl rollout status deployment/myapp -n staging
      
      - name: Smoke tests
        run: |
          curl -f https://staging.myapp.com/health || exit 1

  # Стадия 8: Deployment на production
  deploy-production:
    needs: e2e
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    
    environment:
      name: production
      url: https://myapp.com
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Canary deployment (10% traffic)
        run: |
          kubectl set image deployment/myapp-canary \
            myapp=myapp:${{ github.sha }} \
            -n production
      
      - name: Wait and monitor (5 min)
        run: sleep 300
      
      - name: Check canary metrics
        run: |
          error_rate=$(kubectl logs -l canary=true -n production | grep ERROR | wc -l)
          [ $error_rate -lt 10 ] || (echo "Too many errors" && exit 1)
      
      - name: Full deployment
        run: |
          kubectl set image deployment/myapp \
            myapp=myapp:${{ github.sha }} \
            -n production
          kubectl rollout status deployment/myapp -n production
      
      - name: Verify production
        run: |
          curl -f https://myapp.com/health || exit 1
          curl -f https://myapp.com/api/v1/status || exit 1

4. Критерии success/fail

Pipeline должен fail если:

// ❌ Compilation error
// ❌ Test failure
// ❌ Code coverage < 90%
// ❌ SpotBugs findings
// ❌ OWASP dependency issues
// ❌ SonarQube Quality Gate failed
// ❌ Formatting issues
// ❌ E2E test failed
// ❌ Deployment failed

5. Мониторинг после деплоя

# Post-deployment checks
Prometheus metrics: error_rate < 1%
Datadog APM: P95 latency < 500ms
ELK logs: no CRITICAL errors
SentryIO: zero new exceptions in first 5 min

If any fails → automatic rollback

6. Ключевые принципы

1. Fail fast — проблемы находятся как можно раньше
2. Parallelization — стадии независимы, выполняются параллельно
3. Automation — всё автоматизировано, не нужны ручные approvals
4. Быстрота — pipeline выполняется < 10 минут
5. Visibility — логи, отчёты, метрики доступны
6. Rollback — всегда есть быстрый способ откатиться
7. Безопасность — проверка на каждом шаге

7. Инструменты в экосистеме

Build:         Maven / Gradle
Test:          JUnit 5 / TestNG
Coverage:      JaCoCo
Static:        SonarQube, SpotBugs, Checkstyle
Security:      OWASP Dependency Check, Snyk
Docker:        Docker, Docker Compose
K8s:           Kubernetes, Helm
Monitor:       Prometheus, Grafana, Datadog
Logs:          ELK Stack, Loki
Tracing:       Jaeger, DataDog

Выводы

Идеальный CI/CD:

• Локально: всё проверяется перед push'ем (make lint, test, build)
• В CI: параллельное выполнение тестов, анализа, сборки
• Качество: coverage, SonarQube, security checks
• Быстро: finish за 5-10 минут
• Безопасно: автоматический rollback при проблемах
• Прозрачно: логи и метрики доступны всем

Это обеспечивает уверенность в коде и быстрые итерации разработки.