Техлид: CI/CD

Мы спроектировали систему на бумаге, научились контролировать ее качество и спланировали долгосрочное развитие.

Здравствуйте ручные процессы

😡 Чтобы выкатить фикс, нужно собрать коллег из трех команд
😡 Релиз раз в месяц, потому что всегда что-то упадет
😡 На тестирование отдельно закладываем неделю.

Знакомо?

Архитектура живет и развивается только тогда, когда изменения можно вносить быстро, дешево и безопасно. А за это отвечает автоматизация, или наша CI/CD-система. Это та самая DevOps-штука, на которую нанимается целый чел, или даже два. И этой штукой нам надо уметь управлять.

1️⃣Continuous Integration (CI)

По сути, CI ощущается как просто запуск юнит-тестов на каждый коммит. И надеюсь есть мысли, что это не просто так - так как это самая дефолтная линия обороны, которая защищает код и архитектуру от самых вероятных проблем:

▫️Жизнеспособность: например, тесты, которые проверяют, что слой domain не лезет в infrastructure. Чтобы коллега при нарушени архитектурного принципа узнал об этом через 5 минут после коммита, а не на ревью через два дня.
▫️Безопасность: автоматические сканеры уязвимостей и проверку зависимостей на известные дыры. Дпоплнительно смотрим токены и секреты.
▫️Рутина: проверка стиля кода (linting), тесты, сборка билдов. То есть освобождение времени команды на code review, чтобы не искать пропущенные точку с запятой.

CI пайплайн - это такой же важный продукт, как и основной сервис. Он должен быть надежным, быстрым и понятным. Именно он гарантирует, что архитектурные решения, принятые на ревью, будут соблюдаться на практике.

2️⃣Continuous Delivery (CD)

Реализуем изменения в продукте и архитектуре, не останавливая бизнес.

Если CI это контроль качества на заводе, то CD - это автоматизированный конвеер до потребителя. А ручные релизы - прошлый век. Как сделать релиз настолько скучным и обыденным событием, что его можно будет доверить роботу?

▫️Микро-релизы: выкатываем маленькие изменения в прод несколько раз в день, поэтому найти и исправить ошибку гораздо проще, чем когда мы раз в месяц выкатываем 20 фич сразу.
▫️Стратегии развертывания: canary deployment - выкатываем новую версию на небольшой процент пользователей, смотрим на метрики (время ответа, ошибки) и постепенно увеличиваем процент. blue-green - поднимаем рядом с текущей (blue) версией новую (green), и переключаем трафик на новую, а старую держим наготове.
▫️Откат: Нужно уметь откатывать версию одной кнопкой, чтобы не бояться релизов.

Наша роль выбрать и помочь внедрить ту стратегию развертывания, которая лучше всего подходит нашему продукту. и продать это команде и бизнесу.

3️⃣Система контроля версий

Git в реале не просто способ хранения кода. Это что-то типа летописи всех инженерных решений.

▫️Храним наши Architecture Decision Records (ADR) и легковесные Design Docs в markdown-файлах прямо в репозитории. Когда будем смотреть на код и задаваться вопросом "зачем мы это сделали?", то сразу можно найти ADR, объясняющий почему было принято такое решение.
▫️Стратегия ветвления тоже влияет на архитектурный процесс. Либо Git Flow с его долгоживущими ветками (develop, feature) для продуктов с редкими, плановыми релизами. Либо Trunk-Based Development (TBD), где все коммитят в одну основную ветку, что неплохо сочетается с CI/CD.

Скорее всего те стандарты работы с Git, которые есть у вас в компании, уже подходят под необзодимые цели развития продукта. Тут скорее надо объяснить команде, как коммиты, пул-реквесты и ветки связаны с общим процессом поставки ценности.

CI/CD и Git по сути некоторая автоматизация всей нашей эволюции архитектуры, и конкретно в этих моментах техлид инвестирует в скорость, качество и, самое главное, в способность своей системы адаптироваться к будущему. Ну а дальше другие вызовы!

@teamleadosh

#career