Что означает непрерывная интеграция (CI)?

Непрерывная интеграция (CI): взгляд Product Manager

Коротко

CI (Continuous Integration) = когда разработчик пишет код, система автоматически проверяет, что он работает, не сломал ли он что-то, и готов ли к продакшену.

Вместо: "я напишу код, потом месяц будем интегрировать, потом выяснится, что всё сломалось".

Теперь: "я пишу код, за 5 минут система проверяет все, либо ok либо error".

---

Процесс без CI (ужас)

Разработчик A пишет feature (неделю)
  ↓
Разработчик B пишет feature (неделю)
  ↓
Техлид говорит: "давайте объединим ваш код"
  ↓
💥 CONFLICT! (оба изменили одну функцию)
  ↓
Тратим неделю на разбор, что конфликтует
  ↓
Отменяем код B (или A)
  ↓
Тестируем ВЕСЬ продукт (может быть 100+ часов)
  ↓
💥 Выясняется: code A сломал feature C
  ↓
Исправляем A на неделю
  ↓
Наконец можем выкатить на продакшен

От идеи к продакшену: 1-2 месяца на интеграцию.

Это кошмар.

---

Процесс с CI (нормально)

Разработчик A пишет code → коммитит в git
  ↓
🤖 CI pipeline автоматически:
  1. Запускает все тесты
  2. Проверяет linting (стиль кода)
  3. Проверяет покрытие тестами (>90%?)
  4. Собирает приложение
  5. Развёртывает в staging
  ↓
✅ ИЛИ ❌
  ✅ Всё прошло → код готов к мёрджу
  ❌ Тест упал → автоматический сигнал: "fix тест перед мёрджем"
  ↓
Разработчик B делает то же самое
  ↓
✅ Когда оба готовы → мёрджим в main
  ↓
🤖 CI снова запускается
  ↓
✅ Если всё ok → автоматически выкатываем на продакшен

От идеи к продакшену: 30 минут.

---

Конкретные шаги CI

Шаг 1: Коммит

git commit -m "Add feature X"
git push

Шаг 2: Webhook срабатывает GitHub отправляет сигнал в CI систему (Jenkins, GitHub Actions, GitLab CI и т.д.).

Шаг 3: CI запускает тесты

# На свежем сервере CI
cd /tmp/repo
git clone <твой репо>
cd my-app

# Установи зависимости
npm install

# Запусти тесты
npm run test
# Результат: 450 passed, 0 failed ✅

# Проверь linting
npm run lint
# Результат: no errors ✅

# Построй приложение
npm run build
# Результат: OK, 2.4 MB ✅

Шаг 4: Результат

Если всё прошло:
  ✅ Pull Request помечен зелёным галочкой
  ✅ PM может мёржить PR без страха
  ✅ Код безопасно попадёт на продакшен

Если что-то не прошло:
  ❌ Pull Request помечен красным крестом
  ❌ Можно даже не смотреть, известно: есть баг
  ❌ Разработчик должен фиксить

---

Зачем PM нужна CI

1. Скорость доставки

• Без CI: фича пишется неделю + интеграция 2 недели
• С CI: фича пишется неделю, выкатывается в день
• Результат: вместо 1 фичи в месяц, 4 фичи в месяц

2. Меньше багов в продакшене

• Без CI: баги найдутся через неделю, когда тестировать было поздно
• С CI: баги найдутся за 5 минут, когда разработчик ещё помнит код
• Результат: production bugs -70%

3. Доверие к релизам

• Если CI прошла → я уверен, что всё работает
• Не нужно 2 дня на QA, потом -5% багов в продакшене
• Результат: вместо "надеялся" = "знаю, что работает"

4. Меньше meetings

• Без CI: "как давела интеграция?" (ежедневная встреча)
• С CI: смотрю на дэшборд → вижу, 15 фич в очереди, все прошли
• Результат: экономия 5 часов встреч в неделю

---

Типы CI checks

1. Unit тесты (самые быстрые)

def test_user_creation():
    user = create_user("alice@example.com")
    assert user.email == "alice@example.com"

# Запускается за миллисекунды
# Проверяет: функция create_user работает?

2. Integration тесты (медленнее)

def test_user_signup_flow():
    # signup → отправка email → создание акка
    user = signup("alice@example.com")
    assert email_sent == True
    assert user.created == True

# Запускается за секунды
# Проверяет: весь flow работает?

3. E2E тесты (самые медленные)

// Playwright: открыть браузер, как реальный пользователь
await page.goto('https://example.com');
await page.fill('input[name=email]', 'alice@example.com');
await page.click('button:has-text("Sign up")');
await expect(page).toHaveText('Welcome!');

// Запускается за минуты
// Проверяет: на самом деле пользователь может зарегистрироваться?

4. Linting (анализ кода)

# Проверяет стиль
# "используй 2 пробела для индента"
# "переменные в camelCase"
# "не оставляй console.log"

5. Coverage (покрытие тестами)

Если код содержит 1000 строк,
a тесты покрывают только 600 строк,
то coverage = 60%.

Ваш стандарт: >90%.
Если новый код имеет покрытие <80%,
CI отклоняет его.

6. Security scan (поиск уязвимостей)

# Проверяет: используешь ли хардкодные пароли?
# Отправляешь ли data в небезопасных местах?
# Есть ли SQL injection уязвимость?

---

Примеры CI систем

GitHub Actions (встроена в GitHub)

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm install
      - run: npm test
      - run: npm run build

GitLab CI (встроена в GitLab)

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script: npm test

build:
  stage: build
  script: npm run build

Jenkins (самостоятельная, более мощная)

pipeline {
    agent any
    stages {
        stage('Test') {
            steps { sh 'npm test' }
        }
        stage('Build') {
            steps { sh 'npm run build' }
        }
    }
}

---

Как CI помогает PM

Сценарий 1: Спешка

Продукт критичен, нужно выкатить в продакшен ЗА ЧАС.

Без CI: неможно. Нужна минимум неделя на тестирование.
С CI: есть шанс.
  Разработчик пишет code → коммитит
  CI за 5 минут проверяет
  ✅ Если ok → можешь выкатить за час
  ❌ Если баги → видна ошибка, фиксим 30 минут, потом выкатываем

Сценарий 2: А/B тестирование

Хочешь быстро проверить две версии фичи.

Лучше:
  Разработчик A пишет Version A → коммитит
  Разработчик B пишет Version B → коммитит
  CI проверяет обе → обе готовы
  Выкатываем 50% Version A, 50% Version B
  За неделю узнаем, какая лучше

Хорошо:
  Написана фича, потом неделю интегрируем, потом A/B...
  = 3 недели

Сценарий 3: Много разработчиков

Теам из 50 разработчиков, все пишут в один продукт.

Без CI:
  Один разработчик ломает всё → неизвестно, кто
  Ломаются 10 других разработчиков
  На интеграцию уходит неделя

С CI:
  Один разработчик ломает → CI сигналит сразу
  "Твой PR не прошёл тесты"
  Он фиксит за 5 минут
  Остальные не пострадали

---

Минусы CI (почему не всегда используют)

Минус 1: Infrastructure

• Нужны сервера для запуска тестов
• Нужны люди для настройки
• Бюджет: $500-5000/месяц

Минус 2: Тесты должны быть хорошие

• Если тесты плохие → CI постоянно падает
• "Crying wolf" → разработчики игнорируют CI
• Нужна культура: тесты это ценность

Минус 3: Медленность

• Если тесты долгие (часам) → разработчик ждёт
• Должны быть быстрые тесты (< 5 минут)

---

Матрица: CI для разных команд

---

Финал

CI = автоматизация проверки кода

Для PM это значит:

• Разработка быстрее (нет недели интеграции)
• Продакшен надёжнее (меньше багов)
• Доверие выше (я знаю, что работает)

Если ты PM и у тебя нет CI → это tech debt. Пора её внедрять.