Сегодня разработка программного обеспечения по большей части выполняется командами, обращающимися к одному или нескольким репозитариям кода, которые управляются системами контроля версий. Индивидуальные разработчики выбирают области кода, которые требуют изменений, и должны решить, как отразить эти изменения в системе контроля версий.
Иногда изменения в коде достаточно просты и не несут серьезных рисков. В этом случае разработчик вносит правки с минимальным риском вмешательства в работу товарищей, имеющих дело с той же самой базой кода.
Но что, если команда занимается реализацией более серьезной функции, на разработку которой уходит несколько дней, недель или даже месяцев? Когда внесенные в код изменения целесообразно отражать в системе контроля версий? И как при регистрации этих изменений добиться того, чтобы код, созданный командой разработчиков, интегрировался без ошибок сборки и других функциональных дефектов?
Для чего нужна непрерывная интеграция?
Поначалу кажется, что разработку имеет смысл разделить на несколько независимых ветвей контроля версий. Команда должна решить, стоит ли использовать единую функциональную ветвь, или же создать несколько ветвей для каждого из разработчиков.
Однако интуиция подсказывает, что такой способ разработки не является оптимальным. Каждая функциональная ветвь в процессе разработки отклоняется от основной линии. И если такие функциональные ветви используются в течение достаточно продолжительного времени, процесс интеграции становится затруднен, на разрешение конфликтов уходит слишком много времени, а ошибок возникает все больше.
Крупные команды, испытывающие постоянную потребность в разработке и развертывании, быстро придумали новый подход, при котором изменения вносятся часто, а проверка сборки и функциональности выполняется с помощью средств автоматизации. Такой подход получил название непрерывная интеграция (continuous integration, CI).
Определение непрерывной интеграции
Непрерывная интеграция – это философия написания кода и связанный с этим набор правил, регламентирующих внесение небольших изменений и частую проверку кода в репозитариях с системами контроля версий.
Поскольку большинство современных приложений требуют разработки кода на различных платформах и с помощью различных инструментальных средств, команде нужны технологии, позволяющие интегрировать и проверять эти изменения. Техническая цель непрерывной интеграции заключается в создании согласованного и автоматизированного способа сборки, объединения и тестирования приложений. При согласованном процессе интеграции команды чаще фиксируют изменения, что приводит к улучшению взаимодействия и повышению качества программного обеспечения.
Как непрерывная интеграция работает на практике
Непрерывная интеграция – философия и методология разработки, опирающаяся на процессы и автоматизацию сборки программного обеспечения. Придерживаясь CI, разработчики часто фиксируют изменения кода в системе контроля версий, причем у большинства команд процедура фиксации выполняется не реже одного раза в день.
Объясняется это тем, что обнаружить ошибки и другие дефекты программного обеспечения проще после внесения небольших изменений, а не масштабной переделки, занимавшей длительное время. При сокращении продолжительности циклов фиксации снижается и вероятность того, что сразу несколько разработчиков будут редактировать одни и те же куски кода, что потребует их предварительного согласования перед выполнением фиксации.
В процессе внедрения непрерывной интеграции команды зачастую начинают с настройки конфигурации и определения правил управления версиями. Несмотря на частые проверки кода реализация новых функций и внесение изменений могут занимать как короткие, так и длительные промежутки времени. Команды разработчиков, практикующие непрерывную интеграцию, используют различные технологии проверки готовности функционала и кода к выпуску.
Команды, придерживающиеся CI, предпочитают фиксировать код в единственной ветви или стволе разработки. При использовании нескольких ветвей продолжительность их существования стараются минимизировать, объединяя одну ветвь с другой.
Существуют технологии управления функциями, которые требуют более длительной разработки, но при этом по-прежнему интегрируются в ветви. Некоторые команды используют функциональные флаги – свойство конфигурации, позволяющее включать и отключать нужные функции и код прямо в процессе исполнения программы. Функциям, находящимся в процессе разработки, ставятся в соответствие функциональные флаги, они вставляются в основную ветвь и отключаются до момента готовности.
Процесс сборки автоматизируется путем упаковки всего программного обеспечения, базы данных и других компонентов. Например, если вы разрабатываете приложение Java, средства CI упакуют все статические файлы веб-сервера (HTML, CSS и JavaScript) вместе с приложением Java и скриптами базы данных.
Большинство инструментов CI позволяет разработчикам создавать сборки по требованию, программно фиксируя код в репозитарии контроля версий или выполняя соответствующие операции по заранее заданному расписанию. Командам необходимо обсудить расписание сборки, которое наилучшим образом подходит бы для группы заданной численности, количество фиксаций в течение дня и другие вопросы проектирования приложения. Рекомендуется убедиться, что фиксации и сборки выполняются быстро, в противном случае они могут препятствовать прогрессу команд, пытающихся писать код быстро и фиксировать его часто.
Рабочие процессы здесь называются конвейером CI.
Разработка и тестирование с использованием непрерывной интеграции
При внедрении конвейера CI у разработчиков формируется новый технологический процесс. Они вносят правки в код в редакторе, интегрированной среде разработки или в своей собственной, «локальной» среде. В идеале в локальной среде должна присутствовать исполняемая среда, позволяющая запускать основные функциональные тесты. Затем выполняются автоматизированные модульные тесты, которые также легко запускаются в указанных средах.
После успешного прохождения основных тестов выполняется фиксация кода. Платформа CI (например, Jenkins или Travis) запускает сборку, в которой все элементы кода помещаются в один или несколько строительных блоков. Затем процедура CI проводит анализ статического кода и сообщает разработчикам об обнаруженных в сборке ошибках.
В случае обнаружения ошибок члены команды разработчиков должны быстро изучить и разрешить все вопросы, поскольку заблокированный конвейер сборки останавливает процесс разработки всей команды. Многие группы отслеживают показатели успешных сборок и процент ошибок, используя эти данные при поиске резервов для улучшения процесса разработки.
После того, как программное обеспечение упаковано, инструменты CI могут помочь вам перенести сборку программного обеспечения в среду его поставки, активизировать необходимые сервисы (например, перезапустить серверы приложений) и выполнить любые автоматизированные тесты. Эти шаги обычно называют непрерывной поставкой (continuous delivery, CD), а функции тестирования, встроенные в конвейер непрерывных интеграции и поставки (CI/CD), становятся компонентами непрерывного тестирования.
Команды, использующие в своей деятельности CI/CD, способны быстрее предлагать пользователям новые функции и расширения. Средства автоматизации и технологические процессы позволяют сократить объемы написания кода и уменьшить число функциональных дефектов. Технологические процессы такого рода укрепляют взаимодействие в команде и помогают создавать интеллектуальные, еще более инновационные решения. И все это начинается с непрерывной интеграции.
