Непрерывная интеграция: определение

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

Непрерывная интеграция, как и непрерывная доставка, очень популярна, особенно когда речь идет о гибкой разработке программного обеспечения. Цель этого современного подхода — работать небольшими шагами, чтобы сделать сам процесс разработки более эффективным и иметь возможность более гибко реагировать на изменения. Непрерывная интеграция была впервые упомянута в описании agile-метода «Экстремальное программирование» Кентом Беком.

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

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

На практике непрерывная интеграция обычно происходит следующим образом: Перед разработчиком стоит задача создать функцию. Прежде чем приступить к программированию, он загружает текущую версию полного кода приложения, так называемый mainline. Теперь они могут работать над этой версией, которая находится на их персональном компьютере (также называемой рабочей копией). Выполнив свою задачу, они тестируют программу, удаляют все ошибки и теперь могут поместить новую версию обратно в mainline. 

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

Если вы решили использовать непрерывную интеграцию, вам придется следовать некоторым правилам. Большинство программистов следуют принципу, который Мартин Фаулер (разработчик программного обеспечения) создал для успешной непрерывной интеграции. Прежде всего, они следят за тем, чтобы все участники процесса находились на одном уровне и чтобы никто не создавал хаос, отклоняясь от них.

Звучит естественно, но это один из самых важных факторов: все члены команды должны использовать один и тот же источник (репозиторий) при работе над кодом. Это относится не только к исходному коду, поскольку работающее приложение требует дополнительных элементов, таких как базы данных. Они тоже должны быть собраны в одном месте. Поэтому Мартин Фаулер рекомендует создавать репозиторий, чтобы разработчик мог работать с совершенно новым рабочим компьютером и находить все необходимые файлы в одном центральном месте.

Чтобы сделать из исходного кода работающую программу, необходимо скомпилировать его, обновить базы данных и переместить файлы в нужное место. Этот процесс можно автоматизировать. В идеале процесс сборки должен быть возможен с помощью всего одной команды.

Команда получает еще больше преимуществ от автоматизации и ускорения непрерывной интеграции, если интегрирует механизмы тестирования в процесс сборки. Как и сам процесс сборки, тесты (лучшей практикой является внедрение целого набора различных механизмов тестирования) должны выполняться с минимальными усилиями.

Непрерывная интеграция может работать только в том случае, если все члены команды поддерживают систему. Как только одному разработчику не удается постоянно интегрировать свой код в магистраль, другие разработчики принимают ложные предпосылки. Все полагают, что работают над стабильной системой, но если кто-то слишком долго (более одного дня) удерживает код, последующая отладка может стать проблемой. Как это часто бывает в жизни, коммуникация при непрерывной интеграции является важным фактором. Если разработчики держат друг друга в курсе событий, мелкие проблемы могут быть решены быстро.

Программный код, находящийся в магистрали, всегда должен быть протестирован и быть функциональным. Поэтому каждый разработчик может интегрировать свой код только в эту основную ветку и не работать в своей собственной ветке. В этом контексте каждый разработчик должен убедиться, что его собственный вклад определенно функционирует. Для этого они должны протестировать код и сборку после интеграции. Если возникает ошибка, они должны ее исправить. Это гарантирует, что код всегда будет безошибочным.

Одна из самых важных вещей, когда речь идет о непрерывной интеграции, заключается в том, что неисправная версия никогда не должна оставаться на главной линии. Для разработчиков это означает, что исправление не должно откладываться. По словам Мартина Фаулера, нет ничего страшного в том, что сборки не работают и код необходимо переделать, но система непрерывной интеграции всегда требует, чтобы ремонт был выполнен немедленно. Это связано с тем, что все разработчики должны иметь возможность предполагать, что код работает в магистрали — если это не так, то вся команда собирает в нестабильных системах, вызывая лавину ошибок.

Фактическая интеграция кода (включая тестирование) должна происходить как можно быстрее. Экстремальное программирование (XP) отводит на это всего 10 минут. Поскольку разработчик может интегрировать несколько раз в день, длительное время сборки приведет к большим потерям рабочего времени. Поэтому необходимо создать механизмы, ускоряющие этот процесс. Чтобы обеспечить такие высокие скорости, необходимо смириться с тем, что вы не сможете напрямую проводить все возможные тесты. Вместо этого внедряется двухэтапная система: на первом этапе, который происходит в повседневной работе, испытания проводятся таким образом, чтобы достичь короткого времени сборки. Вторая фаза тестирования, с другой стороны, длится несколько часов и включает в себя углубленные проверки.

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

Все разработчики в команде должны иметь легкий доступ к последней версии и возможность запускать программу. Это относительно легко сделать: поскольку непрерывная интеграция требует, чтобы все файлы хранились в одном репозитории, разработчикам просто нужно знать его местоположение. Для этого есть несколько веских причин: тестировщики могут запускать дополнительные тесты в процессе программирования, заинтересованные стороны могут использовать исполняемые файлы в демонстрационных целях, а менеджеры по качеству могут проверять их количество.

Важно не только, чтобы каждый участник процесса имел доступ к исходному коду, но и чтобы было понятно, какие изменения были внесены и кем. Коммуникация также означает, что разработчики должны общаться друг с другом, когда они находятся в процессе сборки. Для этого некоторые команды используют отдельные дисплеи или визуальные средства, которые показывают, что они находятся в середине интеграции.

Наконец, распространение программного обеспечения также должно быть автоматизировано. Файлы необходимо перемещать из одной среды в другую, что может отнимать много времени. Для этого процесса имеет смысл использовать скрипты. Они позволят автоматизировать и ускорить процесс.

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

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

• Jenkins: Очень популярная программа для Java — это форма от Hudson, которая больше не развивается. Программа с открытым исходным кодом работает с различными инструментами сборки и системами контроля версий.
• Travis CI: Этот инструмент непрерывной интеграции особенно популярен, поскольку он легко работает с GitHub. Онлайн-репозиторий информирует Travis об изменениях в коде. Программное обеспечение доступно в бесплатной версии для проектов с открытым исходным кодом и в платной версии для всех остальных проектов.
• Bamboo: Сервер Bamboo позволяет разработчикам интегрировать, развертывать и управлять релизами. Производитель Atlassian предлагает программное обеспечение в виде веб-интерфейса на базе Java. Bamboo поддерживает разработчиков посредством автоматизации и работает с различными инструментами сборки. Для проектов с открытым исходным кодом обычно платное предложение доступно бесплатно.
• Gitlab CI: GitLab предлагает собственную программу для непрерывной интеграции, которая работает с известной версией управления. Конвейер может быть разработан индивидуально и, следовательно, адаптирован к каждому проекту. GitLab также поддерживает CI Docker.
• CircleCI: Существует две различные версии этой программы непрерывной интеграции. Либо вы выбираете вариант непосредственно в облаке провайдера, либо создаете свой собственный локальный сервер для использования.
• CruiseControl: Первоначально разработанная ThoughtWorks (компанией, в которой работает Мартин Фаулер), CruiseControl сейчас является независимым проектом. Среди прочего, CruiseControl предлагает разработчикам приборную панель — их собственный веб-сайт, на котором можно увидеть статус сборки.
• Codeship: Codeship пытается предоставить разработчикам очень простой способ непрерывной интеграции. На основе контейнерной технологии можно легко создавать автоматизмы. Компания предлагает две различные версии для этой задачи: basic и pro.
• TeamCity: Коммерческое программное обеспечение TeamCity придает большое значение совместимости с другими инструментами. Многие программы поддерживаются уже в стандартной версии, но ассортимент также может быть расширен за счет плагинов. Предварительно протестированный коммит — еще одна их особенность. TeamCity самостоятельно проверяет переписанный код перед его интеграцией в основной и сообщает разработчику о любых ошибках.