Что происходит от отправления кода на удаленный репозиторий до продакшна

От отправления кода на удаленный репозиторий до продакшна

CI/CD pipeline — это полный цикл жизни кода от момента push'а в репозиторий до развёртывания в production. Это один из самых важных процессов в современной разработке. Давайте разберём каждый этап детально.

Полный цикл жизни кода

Этап 1: Git Push на удалённый репозиторий

git add .
git commit -m "feat: implement new feature"
git push origin feature-branch

В этот момент:

• Код попадает в GitHub/GitLab/Bitbucket
• Автоматически триггерится CI система (если настроена)
• Создаётся webhook уведомление

Этап 2: Непрерывная интеграция (CI)

2.1 Запуск автоматических тестов

# Example: GitHub Actions
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      - name: Set up JDK
        uses: actions/setup-java@v2
        with:
          java-version: '17'
      
      - name: Run tests
        run: mvn clean test
      
      - name: Run integration tests
        run: mvn verify
      
      - name: Code coverage
        run: mvn jacoco:report

Что проверяется:

• Unit тесты (быстрые)
• Integration тесты (медленнее)
• Code quality (SonarQube, Checkstyle)
• Coverage (> 80%)
• Security scanning (SAST)

2.2 Code Quality Checks

// SonarQube проверяет:
// - Code smells
// - Bugs
// - Security vulnerabilities
// - Code coverage
// - Duplication

2.3 Secutiry Scanning

# Проверка на известные уязвимости
- OWASP Dependency Check
- Snyk
- GitHub Advanced Security

# Проверка на утечки secrets
- Repo scanning на API ключи
- Password patterns

Этап 3: Pull Request Review

Если CI passed:

CI Status: ✓ All checks passed
├─ Tests: ✓ PASSED (42 tests)
├─ Coverage: ✓ 85% (above threshold)
├─ Code Quality: ✓ A (SonarQube)
└─ Security: ✓ No vulnerabilities

Код готов для review:

// Код ревьюеры смотрят на:
// 1. Логика реализации
// 2. Соответствие архитектуре
// 3. Производительность
// 4. Security issues
// 5. Best practices

После approval:

• 2+ approval (в большинстве компаний)
• Merge в develop/main ветка
• Автоматически триггерится CD

Этап 4: Build (создание артефакта)

# Build stage
build:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v2
    
    - name: Build JAR
      run: mvn clean package -DskipTests
    
    - name: Build Docker image
      run: |
        docker build -t myapp:${{ github.sha }} .
        docker tag myapp:${{ github.sha }} myapp:latest
    
    - name: Push to Registry
      run: |
        echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USER }} --password-stdin
        docker push myapp:${{ github.sha }}
        docker push myapp:latest

Что создаётся:

• JAR файл (сам артефакт Java приложения)
• Docker образ (контейнер со всеми зависимостями)
• Version tag (git SHA для трейсирования)

Этап 5: Staging Environment

Развёртывание на staging (тестовом сервере):

deploy-staging:
  needs: build
  runs-on: ubuntu-latest
  steps:
    - name: Deploy to Staging
      run: |
        helm upgrade --install myapp ./charts/myapp \
          --namespace staging \
          --set image.tag=${{ github.sha }}

На staging выполняется:

• E2E тесты (автоматизированные)
• Performance тесты
• Security тесты
• Manual QA (если нужна)

Пример E2E тест:

public class E2ETest {
    @Test
    public void userCanCreateOrder() {
        // Открыть приложение
        webDriver.get("https://staging.myapp.com");
        
        // Логин
        webDriver.findElement(By.id("login")).sendKeys("user@test.com");
        webDriver.findElement(By.id("password")).sendKeys("password");
        webDriver.findElement(By.id("loginBtn")).click();
        
        // Создать заказ
        webDriver.findElement(By.id("newOrder")).click();
        // ... assertions ...
    }
}

Этап 6: Approval для Production

Если всё ок на staging:

Release Checklist:
☑ All tests passed
☑ E2E tests completed
☑ Performance tests OK
☑ Security scan cleared
☑ Staging team approved
☑ Rollback plan ready

Release notes создаются:

# Release v1.2.3

## Features
- Added user authentication with OAuth2
- New dashboard analytics

## Bug Fixes
- Fixed payment processing timeout
- Resolved database connection leaks

## Breaking Changes
- Deprecated old API endpoint /v1/users
- Use /v2/users instead

## Rollback Plan
If critical issues occur, revert to v1.2.2

Этап 7: Непрерывное развёртывание (CD)

Blue-Green Deployment (безопасный способ)

# Blue (текущая версия) работает
# Green (новая версия) развёртывается параллельно

Production:
├─ Blue (v1.2.2) - 50% трафика
└─ Green (v1.2.3) - 50% трафика

# Тестируем новую версию
# Если OK -> полностью переходим на Green
# Если ошибка -> откатываемся на Blue (instant rollback)

Canary Deployment (постепенное внедрение)

# Сначала отправляем новую версию на 5% трафика
# Мониторим метрики
# Если всё хорошо -> 25%, 50%, 100%

Production:
├─ v1.2.2 - 95% трафика
└─ v1.2.3 - 5% трафика (canary)

Kubernetes Deployment пример:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v1.2.3
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10

Этап 8: Monitoring & Logging

Сразу после развёртывания включается мониторинг:

// Application Monitoring
- Memory usage
- CPU usage
- Request latency
- Error rate
- Database connections

// Business Metrics
- User sign-ups
- Transaction success rate
- API usage

Stack для мониторинга:

Metrics:
  - Prometheus (сбор метрик)
  - Grafana (визуализация)
  
Logging:
  - ELK Stack (Elasticsearch, Logstash, Kibana)
  - Datadog
  - CloudWatch
  
Tracing:
  - Jaeger
  - Zipkin
  - DataDog APM

Пример мониторинга в коде:

@RestController
public class OrderController {
    
    private final MeterRegistry meterRegistry;
    
    @PostMapping("/orders")
    public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
        long startTime = System.currentTimeMillis();
        
        try {
            Order order = orderService.create(request);
            meterRegistry.counter("orders.created").increment();
            return ResponseEntity.ok(order);
        } catch (Exception e) {
            meterRegistry.counter("orders.failed").increment();
            throw e;
        } finally {
            long duration = System.currentTimeMillis() - startTime;
            meterRegistry.timer("orders.creation.time").record(duration, TimeUnit.MILLISECONDS);
        }
    }
}

Этап 9: Alerting

Если что-то не так:

Alerts:
- Error rate > 1% -> CRITICAL
- Response time > 500ms -> WARNING
- Database connections > 90% -> WARNING
- Out of memory -> CRITICAL

Уведомления идут в:

• Slack
• PagerDuty (if critical)
• Email
• SMS (for critical)

@Component
public class AlertingService {
    
    @Scheduled(fixedRate = 60000)  // каждую минуту
    public void checkMetrics() {
        double errorRate = getErrorRate();
        
        if (errorRate > 0.01) {  // 1%
            sendAlert("High error rate: " + errorRate);
            notifySlack("ERROR: Error rate too high");
        }
    }
}

Этап 10: Incident Response

Если найдена ошибка в production:

1. Alert срабатывает
2. On-call инженер уведомляется
3. Начинается investigation
4. Возможные действия:
   a) Быстрое исправление (hotfix)
   b) Откат к предыдущей версии (rollback)
   c) Scale-up (если это проблема нагрузки)

Hotfix процесс:

# 1. Создать hotfix ветка от main
git checkout -b hotfix/critical-bug main

# 2. Исправить ошибку
vi src/main/java/...

# 3. Запустить тесты
mvn clean test

# 4. Commit и push
git commit -m "fix: critical bug"
git push origin hotfix/critical-bug

# 5. Создать PR
# 6. Быстрый review и merge
# 7. CD автоматически развёртывает
# 8. Merge обратно в develop

Полный цикл в одной диаграмме

dev pushes code
        ↓
[CI Trigger]
├─ Run tests
├─ Code quality check
├─ Security scan
        ↓
[Code Review]
├─ Developers review
├─ Approve/Request changes
        ↓
[Merge to Main]
        ↓
[CD Trigger]
├─ Build artifact
├─ Create Docker image
        ↓
[Deploy to Staging]
├─ Run E2E tests
├─ Performance tests
        ↓
[Approval]
├─ Manual sign-off
├─ Release notes created
        ↓
[Deploy to Production]
├─ Blue-green or Canary
├─ Health checks
        ↓
[Monitoring]
├─ Watch metrics
├─ Check logs
├─ Alert if issues
        ↓
Success or Rollback

Вывод

От push'а в репозиторий до production — это полностью автоматизированный процесс, состоящий из:

1. CI (непрерывная интеграция) — тестирование и валидация
2. Code Review — человеческий контроль качества
3. CD (непрерывное развёртывание) — автоматическое внедрение
4. Monitoring — наблюдение за здоровьем системы
5. Alerting — оповещение о проблемах

Это снижает риск ошибок и ускоряет доставку новых функций. Хороший CI/CD pipeline — это признак зрелой инженерной культуры в компании.