Continuous Integration

Идея CI в одном предложении

Каждый разработчик вливает свои изменения в общую ветку часто и мелко, а на каждое изменение автоматика проверяет, что ничего не сломалось.

Слово "continuous" здесь о частоте: не раз в неделю большим куском, а много раз в день маленькими. Чем мельче порция, тем проще найти, что именно сломало сборку.

Что обычно гоняет CI

Типичный CI-прогон на каждый push в merge request:

checkout кода
  -> установка зависимостей
  -> линтер / форматтер   (стиль, очевидные ошибки)
  -> сборка / компиляция  (вообще собирается?)
  -> юнит-тесты           (логика не сломана?)
  -> прочие проверки      (типы, security-скан, размер бандла)

Если любой шаг падает, прогон красный и merge request нельзя влить. Это и есть автоматический "контроль качества на входе".

Fail fast

Хороший pipeline падает как можно раньше и дешевле. Сначала быстрые проверки (линтер — секунды), потом дорогие (интеграционные тесты - минуты). Нет смысла гонять 10-минутные тесты, если код даже не компилируется.

Цель — чтобы разработчик узнал о поломке за минуты после push, пока контекст ещё в голове, а не через день на код-ревью.

Зелёный main — это правило

Главная ветка (main/master) должна всегда быть в рабочем, проходящем тесты состоянии. Из неё в любой момент собирается релиз.

Поэтому:

• прямой push в main запрещён, только через merge/pull request,
• MR не вливается, пока CI красный,
• часто требуется ещё и approve от ревьюера.

Это та самая защита ветки, про которую был урок в треке Git. CI — её обязательная половина: правило "main всегда зелёный" держится на том, что проверки автоматические и обойти их нельзя.

Почему часто сливать — безопаснее

Контринтуитивно: чем чаще вливаешь, тем меньше риск. Большая ветка, живущая две недели, расходится с main всё сильнее. В момент слияния получаешь гору конфликтов и сюрпризов. Это называется merge hell.

Подход, где все работают близко к main и вливаются по чуть-чуть, называется trunk-based development. Мелкие MR проще ревьюить, быстрее проходят CI и реже конфликтуют.

Что нужно от кода, чтобы CI работал

CI не магия, он лишь запускает то, что ты написал. Чтобы это имело смысл:

• тесты должны существовать и быть быстрыми (медленные никто не ждёт),
• сборка должна быть воспроизводимой (зафиксированные версии зависимостей — lock-файл),
• проверки должны быть детерминированными: "плавающий" тест, который падает через раз (flaky), быстро приучает команду игнорировать красный CI, и тогда он бесполезен.

Что важно запомнить

CI = вливать часто и мелко + автоматически проверять каждое изменение.

Типовой прогон: зависимости -> линтер -> сборка -> тесты. Падает -> MR не вливается.

Fail fast: дешёвые проверки раньше дорогих, чтобы поломка всплыла за минуты.

main всегда зелёный: push только через MR, влить нельзя при красном CI.

Частые мелкие слияния (trunk-based) безопаснее редких больших: нет merge hell.

В следующем уроке разберём вторую букву: чем Continuous Delivery отличается от Continuous Deployment.