WikiDer > Непрерывная интеграция - Википедия

Continuous integration - Wikipedia

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

Обоснование

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

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

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

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

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

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

Скомпилировать код в CI

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

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

Помимо автоматизированных модульных тестов, организации, использующие CI, обычно используют сервер сборки для реализации непрерывный процессы применения контроль качества в общем - небольшие усилия, прикладываемые часто. В дополнение к запуску модульных и интеграционных тестов такие процессы запускают дополнительный статический анализ, измеряют и профилируют производительность, извлекают и форматируют документацию из исходного кода и упрощают руководство. QA процессы. О популярных Трэвис Си сервис для open-source, только 58,64% заданий CI выполняют тесты.[7]

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

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

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

История

Самой ранней известной работой по непрерывной интеграции была среда Infuse, разработанная Г. Э. Кайзером, Д. Э. Перри и В. М. Шеллом.[8]

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

В 1997 г. Кент Бек и Рон Джеффрис изобрел Экстремальное программирование (XP) находясь на Комплексная система компенсации Chrysler проект, включая непрерывную интеграцию.[1][самостоятельно опубликованный источник] Бек опубликовал статью о непрерывной интеграции в 1998 году, подчеркнув важность личного общения над технологической поддержкой.[10] В 1999 году Бек разработал больше в своей первой полной книге по экстремальному программированию.[11] Круиз-контроль, один из первых инструментов CI с открытым исходным кодом,[12][самостоятельно опубликованный источник] был выпущен в 2001 году.

Общие практики

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

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

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

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

Поддерживать репозиторий кода

Основная статья: Управление версиями

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

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

Основная статья: Автоматизация сборки

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

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

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

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

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

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

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

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

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

Держите сборку быстро

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

Протестируйте в клоне производственной среды

Основная статья: Тестовая среда

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

Сделайте так, чтобы получать самые свежие результаты

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

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

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

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

Автоматизировать развертывание

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

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

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

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

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

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

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

Смотрите также

Рекомендации

  1. ^ а б c Фаулер, Мартин (1 мая 2006 г.). «Непрерывная интеграция». Получено 9 января 2014.
  2. ^ Буч, Гради (1991). Объектно-ориентированный дизайн: с приложениями. Бенджамин Каммингс. п. 209. ISBN 9780805300918. Получено 18 августа 2014.
  3. ^ Бек, К. (1999). «Принятие изменений с помощью экстремального программирования». Компьютер. 32 (10): 70–77. Дои:10.1109/2.796139. ISSN 0018-9162.
  4. ^ Дюваль, Поль М. (2007). Непрерывная интеграция. Повышение качества программного обеспечения и снижение риска. Эддисон-Уэсли. ISBN 978-0-321-33638-5.
  5. ^ Каннингем, Уорд (5 августа 2009 г.). «Ад интеграции». WikiWikiWeb. Получено 19 сентября 2009.
  6. ^ «Что такое непрерывная интеграция?». Веб-сервисы Amazon.
  7. ^ Дюрье, Томас; Абреу, Руи; Монперрус, Мартин; Bissyande, Tegawende F .; Круз, Луис (2019). «Анализ более 35 миллионов рабочих мест Трэвиса Си». Международная конференция IEEE по сопровождению и развитию программного обеспечения (ICSME), 2019 г.. IEEE: 291–295. arXiv:1904.09416. Bibcode:2019arXiv190409416D. Дои:10.1109 / ICSME.2019.00044. ISBN 978-1-7281-3094-1. S2CID 203593737.
  8. ^ Kaiser, G.E .; Perry, D.E .; Шелл, В. М. (1989). Infuse: объединение управления тестированием интеграции с управлением изменениями. Материалы тринадцатой ежегодной международной конференции по компьютерному программному обеспечению и приложениям. Орландо, Флорида. С. 552–558. Дои:10.1109 / CMPSAC.1989.65147.
  9. ^ Буч, Гради (декабрь 1998 г.). Объектно-ориентированный анализ и дизайн с приложениями (PDF) (2-е изд.). Получено 2 декабря 2014.
  10. ^ Бек, Кент (28 марта 1998 г.). «Экстремальное программирование: гуманистическая дисциплина разработки программного обеспечения». Фундаментальные подходы к программной инженерии: первая международная конференция. 1. Лиссабон, Португалия: Springer. п. 4. ISBN 9783540643036.
  11. ^ Бек, Кент (1999). Объяснение экстремального программирования. Эддисон-Уэсли Профессионал. п.97. ISBN 978-0-201-61641-5.
  12. ^ «Краткая история DevOps, часть III: автоматическое тестирование и непрерывная интеграция». CircleCI. 1 февраля 2018 г.. Получено 19 мая 2018.
  13. ^ Браунейс, Дэвид (1 января 2010 г.). «[OSLC] Возможная новая рабочая группа - Автоматизация». open-services.net Сообщество (Список рассылки). Архивировано из оригинал 1 сентября 2018 г.. Получено 16 февраля 2010.
  14. ^ Тейлор, Брэдли. «Развертывание и автоматизация Rails с помощью ShadowPuppet и Capistrano». Рельсовая машина (Всемирная паутина бревно). Архивировано из оригинал 2 декабря 2012 г.. Получено 16 февраля 2010.
  15. ^ См. Например "Debounce". Ардуино. 29 июля 2015.
  16. ^ Фаулер, Мартин. «Практики». Непрерывная интеграция (статья). Получено 29 ноябрь 2015.
  17. ^ Радиган, Дэн. «Непрерывная интеграция». Atlassian Agile Coach.
  18. ^ «Непрерывная интеграция». Мысли.
  19. ^ Данглот, Бенджамин; Монперрус, Мартин; Рудаметкин, Вальтер; Бодри, Бенуа (5 марта 2020 г.). «Подход и эталон для обнаружения поведенческих изменений коммитов в непрерывной интеграции». Эмпирическая разработка программного обеспечения. 25 (4): 2379–2415. arXiv:1902.08482. Дои:10.1007 / s10664-019-09794-7. ISSN 1382-3256. S2CID 67856113.
  20. ^ Райс, Эрик (30 марта 2009 г.). «Непрерывное развертывание за 5 простых шагов». Радар. О'Рейли. Получено 10 января 2013.
  21. ^ Фитц, Тимоти (10 февраля 2009 г.). «Непрерывное развертывание в IMVU: делать невозможное пятьдесят раз в день». Wordpress. Получено 10 января 2013.
  22. ^ Лаукканен, Ээро (2016). «Проблемы, причины и решения при внедрении непрерывной доставки - систематический обзор литературы». Информационные и программные технологии. 82: 55–79. Дои:10.1016 / j.infsof.2016.10.001.
  23. ^ а б c Деббиче, Адам. «Оценка проблем непрерывной интеграции в контексте разбивки требований к программному обеспечению: тематическое исследование» (PDF).

внешняя ссылка