У терминов, которые мы используем в процессах CI/CD, много общего с терминами из фабричного производства. Например, пайплайн — его наиболее близкий литературный перевод «производственная линия» и это не случайно: лучшие подходы разработки ПО похожи на подходы фабричного производства. 

Эта статья — адаптированный урок Тимофея Ларкина, ведущего инженера X5 Retail Group, «Принципы работы CI и CD» курса по CI/CD. В ней мы расскажем про то, через какие боли проходят те, кто делает софт, как помогают правила бережливого производства, и какие шаги включить в пайплайн, чтобы 20% усилий дали 80% результата. 

Через какие боли надо пройти, чтобы сделать софт

Самая большая боль — поддерживать постоянно рабочую версию кода. Это главная польза для клиентов и смысл софта, а чтобы все работало, нужно вовремя внедрять фичи. 

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

Если начать объяснять эти принципы: поддерживать работу, вовремя внедрять фичи, как можно раньше узнавать об ошибке — японскому производственнику, он, скорее всего, посмеется, и спросит, в какой группе детского сада докладчик. Потому что эти принципы — точная реализация бережливого производства (англ. — lean manufacturing), которое изобрел еще в 1980-х годах на фабриках Toyota японский инженер Тайити Оно.

Как правила бережливого производства работают в CI/CD

Один из принципов бережливого производства «Just-in-Time vs. Just-inCase», то есть «Как раз вовремя» вместо «на всякий случай» точно подходит под процессы CI/CD. 

Суть принципа в том, что первый этап линии, например, станок, который штампует с болванок простую деталь, не производит 1000 штук в день, если второй этап — сборочный станок — может обработать только 10 деталей за день. А если первый станок все-таки наштампует 1000 деталей, свалит их в кучу, а второй станок из них сделает 100 агрегатов — если будет хоть один брак, забраковать придется всю тысячу. 

Так же должно быть и в разработке софта, только вместо деталей — выкатить фичу или сделать багфикс. Большое количество изменений трудно замержить, трудно затестить и растет вероятность мердж-конфликтов, поэтому надо генерить новый код не быстрее, чем команда готова его переварить.

Как быстро узнавать об ошибках в процессах CI/CD

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

Джез Хамбл, сооснователь компании DevOps Research and Assessment и преподаватель Беркли, рекомендует: закоммитьте свои изменения, запушьте их в репозиторий, проверьте сборку. Если сейчас все сломалось — ничего страшного, сломалось только у вас, можно откатиться назад и найти причину. Если все прошло хорошо — помните, что над проектом работает не один разработчик, подтяните в свою сборку свежие изменения из мастера и повторите сборку. Если теперь сломалось — кто-то из коллег закоммитил в мастер то, что делает ваши изменения неактуальными. Если все работает — делайте merge request, вливайте изменения в мастер и, затаив дыхание, следите за билдом. Если все хорошо, вы молодец, возьмите с полки пирожок, вы добавили ценность в прод. А если все сломалось — или чините за 5 минут или откатывайте свой коммит и не будьте тем нехорошим человеком, который сломал всем ветку в пятницу вечером. 

Рекомендация Джеза: если за день вы так и не решились влить свой код в мастер, выкиньте то, что не успели влить, завтра вы напишете лучше.

Как проверить сборку

Несмотря на огромный прогресс нашей индустрии, все еще встречаются разработчики, которые запускают сборку бинарника, джарника или контейнера у себя на ноутбуке, а потом, когда к ним приходят насчет ошибок на продакшене делают круглые глаза и говорят «ничего не знаю, на моем ноуте работало». В 2022 году эта фраза, конечно, такой себе ответ. 

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

Автоматизация — процесс, без которого невозможен CI/CD, кроме простейших проектов, где сбор и деплой помещаются в две строчки.

Смысл пайплайна — повышать качество и быстро отсекать сломанное. Есть четыре шага, которые нужно делать с любым кодом, который попадает в пайплайн:

1. Линтер должен проверить, корректно ли код отформатирован: пробелы, табы и отступы нужной ширины, строки переносим после фигурной скобки. 

2. Запустить статический анализ кода. Это может быть платная тулза типа SonarQube, или статические анализаторы, специфичные для каждого языка. Такие утилиты сразу указывают на не явные ошибки в коде. 

3. Запустить юнит-тесты. Во многих языках есть общепринятые фреймворки для юнит-тестов и все, что нужно — запустить компилятор или специальную тулзу с нужными флагами. Тесты нужно добавить в пайплайн — как только разработчик напишет хотя бы один тест, он начнет прогоняться при каждом запуске. 

4. Провести компиляцию: собрать джарник, докер-контейнер, артефакты.

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

Все шаги пайплайна — те самые 20% усилий, которые делают 80% качества кода, при этом не требуют сложных скриптов, а каждый этап занимает одну-две строчки в конфиге пайплайна. 

Добрые материалы:
What is continuous integration?
These days proper CI is table stakes.
Непрерывная интеграция или „Кто всё сломал?“
Lean Manufacturing: The Path to Success with Paul Akers.
Jez Humble: Continuous Delivery - Sounds Great But It Won't Work Here.