Войти
В разработке программного обеспечения, непрерывно интеграция (CI) - это практика объединения рабочих копий всех разработчиков в общую основную ветку несколько раз в день. Грэди Буч впервые предложил термин CI в своем методе 1991 г., хотя он не выступал за интеграцию несколько раз в день. Экстремальное программирование (XP) восприняло концепцию CI и выступило за интеграцию более одного раза в день - возможно, до десятков раз в день.
При переходе к изменению разработчик берет копию валюты t кодовая база, на которой следует работать. По мере того как другие разработчики отправляют измененный код в репозиторий исходного кода, эта копия постепенно перестает отражать код репозитория. Можно не только изменить существующую базу кода, но и добавить новый код, а также новые библиотеки и другие ресурсы, которые создают зависимости и потенциальные конфликты.
Чем дольше продолжается разработка ветки без обратного слияния с основной веткой, тем выше риск множественных конфликтов и сбоев интеграции, когда ветвь разработчика в конечном итоге снова объединяется. Когда разработчики отправляют код в репозиторий, они должны сначала обновить свой код, чтобы отразить изменения в репозитории с тех пор, как они взяли свою копию. Чем больше изменений содержит репозиторий, тем больше работы должны выполнить разработчики, прежде чем отправлять свои собственные изменения.
В конце концов, репозиторий может настолько отличаться от базовых показателей разработчиков, что они попадут в то, что иногда называют «адом слияния» или «адом интеграции», когда время, необходимое для интеграции, превышает время, которое оно потребовалось внести свои первоначальные изменения.
CI предназначен для использования в сочетании с автоматическими модульными тестами, написанными с помощью практики test управляемая разработка. Это делается путем запуска и прохождения всех модульных тестов в локальной среде разработчика перед фиксацией в основной ветке. Это помогает избежать того, чтобы незавершенная работа одного разработчика сломала копию другого разработчика. При необходимости частично полные функции могут быть отключены перед фиксацией, например, с помощью переключателей функций .
Сервер сборки компилирует код периодически или даже после каждой фиксации и сообщает о результатах разработчикам. Использование серверов сборки было введено за пределами сообщества XP (экстремальное программирование), и многие организации приняли CI, не применяя всю XP.
В дополнение к автоматическим модульным тестам организации, использующие CI, обычно используют сервер сборки для реализации непрерывных процессов применения контроля качества в целом - небольшие части усилий, прикладываемых часто. В дополнение к запуску модульных и интеграционных тестов, такие процессы запускают дополнительный статический анализ, измеряют и профилируют производительность, извлекают и форматируют документацию из исходного кода и упрощают ручные процессы QA. В популярном сервисе Travis CI для открытых источников только 58,64% заданий 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 позволяют запускать сценарии после завершения сборки. В большинстве ситуаций можно написать сценарий для развертывания приложения на живом тестовом сервере, на который может взглянуть каждый. Еще одним шагом вперед в этом образе мышления является непрерывное развертывание, которое требует развертывания программного обеспечения непосредственно в производственной среде, часто с дополнительной автоматизацией для предотвращения дефектов или регрессов.
Непрерывная интеграция предназначена для получения таких преимуществ, как:
При непрерывном автоматическом тестировании преимущества могут включать:
Некоторые недостатки непрерывной интеграции могут включать:
| journal =()