Connect with us

Разработка

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

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

Григорий Петров

Опубликовано

/

     
     

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

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

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

CI_part1_cover_optima

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

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

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

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

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

slon2u

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

Сердце Agile

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

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

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
 

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.