Григорий Петров: Управление страхом с помощью Continuous Integration

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

Зачем нужно continuous integration

Самое главное в построении коридоров — это так организовать рабочий процесс, чтобы проверка работы была неизбежной. Эволюция мозга приспособила его постоянно оценивать положение в социуме и «настраивать» модели поведения. Мы очень тонко чувствуем фальшь, и если будет хоть малейшая возможность не делать скучную и неинтересную работу — мы такую возможность придумаем. И миллион оправданий к ней. Если в команде настроена непрерывная интеграция, то все участники понимают неизбежность автоматической сборки проекта. Понимают, и на бессознательном уровне адаптируют свое поведение, стиль работы, отношение к происходящему. Ведь никто не хочет быть супергероем, сломавшим Большое Ночное Тестирование?

Идея continuous integration (далее CI) — в автоматизации ради улучшения рабочего процесса. По доброй традиции CI настраивается так, чтобы вся автоматика выполнялась после того, как разработчик отгрузил на сервер новую порцию исходного кода. Интерактивность очень важна — разработчик должен чувствовать прямую связь между тем, что он сделал push и тем, что через минуту вся команда получила нотификацию о сломанном билде. В этом плане особенно хорошо работают физические индикаторы — вывод текущего состояния CI на большую плазму, загорающиеся красным цветом лампы и так далее. Все это помогает нашему мозгу адаптировать поведение.

И что туда можно запихнуть

Сборка проекта и вердикт «собралось или не собралось» — самое простое, что можно добавить в CI. Обычно все с этого начинают. А затем, войдя во вкус, добавляют все новые и новые автоматизации, чтобы рабочий процесс стал лучше. Вплоть до автоматического анализа сложности кода с помощью метрик вроде «cyclomatic complexity». Тут главное — не увлекаться.

Хорошей идеей будет добавить в CI проверку на соблюдение стандарта кодирования, принятого в команде. Для этого существуют многочисленные программы семейства «lint». Запущенная перед сборкой проекта, такая программа может проверить самые «болезненные» пункты стандарта кодирования: именование идентификаторов и структуру проекта, отступы, принятый в команде стиль расстановки скобок и тому подобное. Неизбежность проверки волшебным образом дисциплинирует разработчиков, они начинают соблюдать стандарт не потому, что «тимлид так сказал», а потому что не хотят «сломать билд». Опять же, главное не увлекаться и сконфигурировать линтер только на несколько самых важных, обязательных пунктов стандарта.

В CI очень хорошо добавлять разнообразные тесты проекта: интеграционные, функциональные, unit-тесты. О тестировании я поговорю отдельно, это очень большая и интересная тем. А начинать можно с самого простого: что собранный проект хотя бы запускается. Такой тест несложно сделать, а добавленный в CI он будет выявлять ошибки вида «ой, а на моем компьютере все работает».

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

Сердце Agile

Continous Integration позволяет извлечь максимальную пользу из agile подхода к созданию софта. Автоматическая сборка и установка позволяет команде фокусироваться на разработке, быстро взаимодействовать с другими участниками процесса и помогать друг другу с задачами без боязни «все сломать».

При использовании CI очень важно не забыть, для чего это все делается. Главная цель — улучшить рабочий процесс, дав нашему мозгу набор легко соблюдаемых и понятных правил. Легко попасть в ловушку, подменив цель процессом. Многие виденные мною команды, к примеру, ставят своей целью 100% покрытие проекта юнит тестами. И совсем не потому, что пишут драйвер. Такая ложная цель создает иллюзию контроля сложности и позволяет избежать действительно сложной работы — создания хороших программ в разумное время. Помните об этом, и continuous integration станет вашим надежным помощником в борьбе со сложностью.