Непрерывная интеграция

редактировать
Практика разработки программного обеспечения, основанная на частой отправке детализированных изменений

В разработке программного обеспечения, непрерывно интеграция (CI) - это практика объединения рабочих копий всех разработчиков в общую основную ветку несколько раз в день. Грэди Буч впервые предложил термин CI в своем методе 1991 г., хотя он не выступал за интеграцию несколько раз в день. Экстремальное программирование (XP) восприняло концепцию CI и выступило за интеграцию более одного раза в день - возможно, до десятков раз в день.

Содержание

  • 1 Обоснование
  • 2 Рабочие процессы
    • 2.1 Выполнение тестов локально
    • 2.2 Компиляция кода в CI
    • 2.3 Запуск тестов в CI
    • 2.4 Развертывание артефакта из CI
  • 3 История
  • 4 Обычные практики
    • 4.1 Поддержание кода репозиторий
    • 4.2 Автоматизировать сборку
    • 4.3 Сделать самотестирование сборки
    • 4.4 Каждый день фиксирует базовый план
    • 4.5 Каждый фиксатор (базовый план) должен быть собран
    • 4.6 Каждое исправление ошибки фиксация должна сопровождаться тестовым примером
    • 4.7 Обеспечьте быструю сборку
    • 4.8 Тестируйте в клоне производственной среды
    • 4.9 Упростите получение последних результатов
    • 4.10 Все могут увидеть результаты последняя сборка
    • 4.11 Автоматизация развертывания
  • 5 Затраты и преимущества
  • 6 См. также
  • 7 Ссылки
  • 8 Внешние ссылки

Обоснование

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

Чем дольше продолжается разработка ветки без обратного слияния с основной веткой, тем выше риск множественных конфликтов и сбоев интеграции, когда ветвь разработчика в конечном итоге снова объединяется. Когда разработчики отправляют код в репозиторий, они должны сначала обновить свой код, чтобы отразить изменения в репозитории с тех пор, как они взяли свою копию. Чем больше изменений содержит репозиторий, тем больше работы должны выполнить разработчики, прежде чем отправлять свои собственные изменения.

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

Рабочие процессы

Запускать тесты локально

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

Компиляция кода в CI

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

Запускать тесты в CI

В дополнение к автоматическим модульным тестам организации, использующие CI, обычно используют сервер сборки для реализации непрерывных процессов применения контроля качества в целом - небольшие части усилий, прикладываемых часто. В дополнение к запуску модульных и интеграционных тестов, такие процессы запускают дополнительный статический анализ, измеряют и профилируют производительность, извлекают и форматируют документацию из исходного кода и упрощают ручные процессы QA. В популярном сервисе Travis CI для открытых источников только 58,64% заданий CI выполняют тесты.

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

Развертывание артефакта из CI

Теперь CI часто переплетается с непрерывной доставкой или непрерывным развертыванием в так называемом конвейере CI / CD. «Непрерывная доставка» гарантирует, что программное обеспечение, зарегистрированное на основной линии, всегда находится в состоянии, которое может быть развернуто для пользователей, а «непрерывное развертывание» делает процесс развертывания полностью автоматизированным.

История

Самой ранней известной работой по непрерывной интеграции была среда Infuse, разработанная GE Kaiser, DE Perry и WM Schell.

В 1994 году Грейди Буч использовал фразу непрерывная интеграция в объектно-ориентированный анализ и дизайн с приложениями (2-е издание), чтобы объяснить, как при разработке с использованием микропроцессов «внутренние выпуски представляют собой своего рода непрерывную интеграцию системы и существуют для принудительного закрытия микропроцесса».

В 1997 году Кент Бек и Рон Джеффрис изобрели Extreme Programming (XP), работая над комплексной системой компенсации Chrysler <60.>проект, в том числе непрерывная интеграция. Бек опубликовал статью о непрерывной интеграции в 1998 году, подчеркнув важность личного общения по сравнению с технической поддержкой. В 1999 году Бек подробно остановился на своей первой полной книге по экстремальному программированию. CruiseControl, один из первых инструментов CI с открытым исходным кодом, был выпущен в 2001 году.

Обычные практики

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

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

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

Для достижения этих целей непрерывная интеграция основана на следующих принципах.

Поддержание репозитория кода

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

Автоматизировать сборку

Одна команда должна иметь возможность построения системы. Многие инструменты сборки, такие как make, существуют уже много лет. Другие новейшие инструменты часто используются в средах непрерывной интеграции. Автоматизация сборки должна включать автоматизацию интеграции, которая часто включает развертывание в производственной среде. Во многих случаях сценарий сборки не только компилирует двоичные файлы, но также создает документацию, страницы веб-сайтов, статистику и распространяемые носители (например, Debian DEB, Red Hat RPM или Windows Файлы MSI ).

Сделать самотестирование сборки

После того, как код построен, все тесты должны быть запущены, чтобы подтвердить, что он ведет себя так, как ожидают разработчики.

Все соглашаются базовый план каждый день

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

Каждая фиксация (до базовой линии) должна быть построена

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

Каждая фиксация исправления ошибки должна сопровождаться тестовым набором

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

Сохраняйте сборку быстрой

Требуется сборка выполнить быстро, чтобы в случае возникновения проблемы с интеграцией ее можно было быстро выявить.

Тестирование в клоне производственной среды

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

Упростите получение последних результатов

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

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

Все могут видеть результаты последней сборки

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

Автоматическое развертывание

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

Затраты и преимущества

Непрерывная интеграция предназначена для получения таких преимуществ, как:

  • Ошибки интеграции обнаруживаются на ранней стадии и их легко отследить благодаря небольшим наборам изменений. Это экономит и время, и деньги на протяжении всего проекта.
  • Избегает хаоса в последнюю минуту в даты выпуска, когда все пытаются проверить свои слегка несовместимые версии
  • Когда модульные тесты терпят неудачу или ошибка возникает, если разработчикам необходимо вернуть кодовую базу в состояние без ошибок без отладки, теряется только небольшое количество изменений (поскольку интеграция происходит часто)
  • Постоянная доступность «текущей» сборки для тестирования, демонстрации или выпуска
  • Частая проверка кода подталкивает разработчиков к созданию модульного, менее сложного кода

При непрерывном автоматическом тестировании преимущества могут включать:

  • Обеспечивает дисциплину частого автоматизированного тестирования
  • Немедленная обратная связь о влиянии локальных изменений на всю систему
  • Показатели программного обеспечения, генерируемые в результате автоматического тестирования и CI (например, показатели для покрытия кода, сложность кода и полнота функций ) сосредоточить внимание разработчиков на разработке функционального, качественного кода и помощи d набирать обороты в команде

Некоторые недостатки непрерывной интеграции могут включать:

  • Построение автоматизированного набора тестов требует значительного объема работы, включая постоянные усилия по охвату новых функций и отслеживанию преднамеренных модификаций кода.
  • Есть требуется некоторая работа по настройке системы сборки, и она может стать сложной, что затрудняет гибкую модификацию.
  • Непрерывная интеграция не обязательно полезна, если объем проекта невелик или содержит непроверенный унаследованный код.
  • Добавленная стоимость зависит от качества тестов и насколько тестируем на самом деле код.
  • Большие группы означают, что новый код постоянно добавлен в очередь интеграции, поэтому отслеживание доставок (при сохранении качества) затруднено, а создание очереди сборок может замедлить всех.
  • При нескольких фиксациях и слияниях в день частичный код для функции можно легко отправить, и поэтому интеграционные тесты не пройдут, пока функция не будет завершена.
  • Безопасность и обеспечение критически важных разработок (например, DO-178C, ISO 26262 ) требуют тщательной документации и - обзор процессов, которых сложно добиться при непрерывной интеграции. Этот тип жизненного цикла часто требует выполнения дополнительных шагов до выпуска продукта, когда требуется одобрение продукта регулирующими органами.

См. Также

Ссылки

Внешние ссылки

Последняя правка сделана 2021-05-15 10:59:19
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте