CI/CD

Автоматизация всего, что происходит между коммитом и релизом: сборка, проверки, подпись, доставка. Смысл не в автоматизации ради автоматизации — смысл в том, что процесс каждый раз одинаков и не зависит от того, на чьём ноутбуке он запускается.

Почему это важно. Ручной релиз умеет проводить только один человек, каждый раз он получается чуть-чуть другим, а в цейтноте его вовсе пропускают. Заодно именно там секреты оказываются не в тех местах.

Что нужно понимать

• Что обязано пройти, прежде чем изменение попадёт в основную ветку
• Чем окружение пайплайна отличается от машины разработчика
• Откуда берутся секреты и кто может их прочитать
• Сколько идёт пайплайн и ждёт ли его вообще кто-нибудь
• Что происходит, когда пайплайн падает на основной ветке

Основные темы

Непрерывная интеграция

• Сборка и проверка каждого изменения, а не только перед релизом
• Обязательные проверки: анализатор, тесты, форматирование, сборка — и как удержать их быстрыми
• Кеширование зависимостей и артефактов сборки
• Воспроизводимость, в том числе зафиксированные версии инструментов
• Немедленная реакция на красную основную ветку

Специфика мобильной разработки

• Подпись под iOS и Android и управление сертификатами без боли
• Раннеры на macOS и сколько они стоят
• Номера сборок и версионирование: генерируются, а не вписываются руками
• Флейворы и окружения в одном пайплайне

Доставка

• Внутренняя раздача сборок тестировщикам
• Отправка в стор, поэтапная раскатка и время ревью
• Release notes, собранные из истории изменений
• Откат, который на мобильных означает выкатить вперёд

Секреты

• Никогда в репозитории и никогда в логах
• Разделены по окружениям, с минимальным работающим доступом
• Ротация — и понимание того, что от неё сломается

Как поддерживать это в рабочем состоянии

• Длительность пайплайна как измеряемая величина
• Нестабильный пайплайн считается сломанным
• Сообщения об ошибках, из которых понятно, что делать
• У пайплайна есть владелец, потому что бесхозный пайплайн деградирует

Уровни

Уровень	Как это выглядит
Junior	Работает с готовым пайплайном и чинит собственные падения.
Middle	Пишет и правит workflow, занимается подписью и секретами, держит сборки быстрыми и воспроизводимыми.
Senior	Проектирует весь путь от коммита до стора, включая окружения, раскатку и откат, и отвечает за то, чтобы пайплайну можно было доверять.

Практика

Для начала

• Сделайте проверки блокирующими Пусть анализатор и тесты запрещают мердж, а не просто сообщают о проблеме.

• Ускорьте пайплайн Измерьте время прогона, закешируйте то, что повторяется, и сократите его заметно.

• Найдите секрет в логе Просмотрите вывод своего пайплайна на предмет того, чего там быть не должно.

Глубже

• Автоматизируйте подпись Настройте подпись под iOS и Android так, чтобы релиз не требовал локальной машины.

• Раздавайте сборки тестировщикам автоматически Пусть мердж в основную ветку даёт внутреннюю сборку без участия человека.

• Генерируйте release notes Собирайте их из коммитов или pull request'ов, а не пишите руками.

Проверьте себя

• Сможет ли кто-то другой выпустить релиз сегодня, если вас не будет?
• Сколько идёт ваш пайплайн — и после какого времени люди начнут его обходить?
• Где лежат ваши сертификаты для подписи и что будет, когда они истекут?
• Чем окружение вашего пайплайна отличается от машины разработчика?
• Что происходит, когда основная ветка краснеет: кто это заметит и как быстро?
• Как доставить исправление пользователям меньше чем за час?

Материалы

• Continuous delivery for Flutter apps — официальное руководство, включая мобильную специфику, которой нет в общей документации по CI.
• GitHub Actions documentation — справочник по платформе, на которой работает большинство проектов. Читать прежде всего разделы про кеширование и секреты.
• Fastlane — стандартный инструментарий для подписи, сборки и отправки мобильных приложений. Один только match снимает проблему сертификатов, с которой мучается большинство команд.
• Continuous Delivery — принципы Джеза Хамбла и Дэйва Фарли. Книга старая, но до сих пор яснее всех объясняет, почему пайплайн должен быть единственной дорогой в production.
• Accelerate / DORA metrics — частота развёртываний, время от коммита до релиза, доля неудачных изменений, время восстановления. Четыре числа, которые действительно стоит мерить у процесса доставки.