 | Эта статья включает в себя список общих ссылок , но он остается в значительной степени непроверенным, поскольку в нем отсутствует достаточное количество соответствующих встроенных ссылок . ( Июль 2016 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
| Разработка программного обеспечения |
|---|
В программной инженерии , непрерывная интеграция ( CI ) является практикой объединения всех разработчиков рабочих копий к общим магистральным несколько раз в день. [1] Грэди Буч впервые предложил термин CI в своем методе 1991 г. [2], хотя он не выступал за интеграцию несколько раз в день. Экстремальное программирование (XP) приняло концепцию CI и действительно выступало за интеграцию более одного раза в день - возможно, до десятков раз в день. [3]
Обоснование [ править ]
Приступая к изменению, разработчик берет копию текущей кодовой базы для работы. По мере того как другие разработчики отправляют измененный код в репозиторий исходного кода , эта копия постепенно перестает отражать код репозитория. Можно не только изменить существующую базу кода, но и добавить новый код, а также новые библиотеки и другие ресурсы, которые создают зависимости и потенциальные конфликты.
Чем дольше продолжается разработка ветки без обратного слияния с основной веткой, тем выше риск множественных конфликтов интеграции [4] и сбоев, когда ветвь разработчика в конечном итоге объединяется обратно. Когда разработчики отправляют код в репозиторий, они должны сначала обновить свой код, чтобы отразить изменения в репозитории с тех пор, как они взяли свою копию. Чем больше изменений содержит репозиторий, тем больше работы должны выполнить разработчики, прежде чем отправлять свои изменения.
В конце концов, репозиторий может настолько отличаться от базовых показателей разработчиков, что они войдут в то, что иногда называют «адом слияния» или «адом интеграции» [5], когда время, необходимое для интеграции, превышает время, необходимое для создания их оригинальные изменения. [6]
Рабочие процессы [ править ]
Выполнять тесты локально [ править ]
CI предназначен для использования в сочетании с автоматизированными модульными тестами, написанными на основе методов разработки, основанной на тестировании . Это делается путем запуска и прохождения всех модульных тестов в локальной среде разработчика перед фиксацией в основной ветке. Это помогает избежать того, чтобы незавершенная работа одного разработчика нарушила копию другого разработчика. При необходимости частично завершенные функции могут быть отключены перед фиксацией, например , с помощью переключателей функций .
Скомпилировать код в CI [ править ]
Сервер сборки компилирует код периодически или даже после каждой фиксации и сообщает о результатах разработчикам. Использование серверов сборки было введено за пределами сообщества XP (экстремальное программирование), и многие организации приняли CI, не применяя всю XP.
Запуск тестов в CI [ править ]
В дополнение к автоматическим модульным тестам организации, использующие CI, обычно используют сервер сборки для реализации непрерывных процессов применения контроля качества в целом - небольших усилий, применяемых часто. В дополнение к запуску модульных и интеграционных тестов, такие процессы запускают дополнительный статический анализ, измеряют и профилируют производительность, извлекают и форматируют документацию из исходного кода и упрощают ручные процессы контроля качества . В популярном сервисе Travis CI для open-source только 58,64% заданий CI выполняют тесты. [7]
Это постоянное применение контроля качества направлено на улучшение качества программного обеспечения и сокращение времени, необходимого для его доставки, путем замены традиционной практики применения контроля качества после завершения всей разработки. Это очень похоже на первоначальную идею более частой интеграции, чтобы упростить интеграцию, только применительно к процессам контроля качества.
Развернуть артефакт из CI [ править ]
Теперь CI часто переплетается с непрерывной доставкой или непрерывным развертыванием в так называемом конвейере CI / CD. «Непрерывная доставка» гарантирует, что программное обеспечение, зарегистрированное на основной линии, всегда находится в состоянии, которое может быть развернуто для пользователей, а «непрерывное развертывание» делает процесс развертывания полностью автоматизированным.
История [ править ]
Этот раздел нуждается в расширении . Вы можете помочь, добавив к нему . ( Август 2014 г. ) |
Самой ранней известной работой по непрерывной интеграции была среда Infuse, разработанная GE Kaiser, DE Perry и WM Schell. [8]
В 1994 году Грэди Буч использовал фразу «непрерывная интеграция» в объектно-ориентированном анализе и проектировании с приложениями (2-е издание) [9], чтобы объяснить, как при разработке с использованием микропроцессов «внутренние выпуски представляют собой своего рода непрерывную интеграцию системы, и существуют, чтобы заставить закрыть микропроцесс ".
В 1997 году Кент Бек и Рон Джеффрис изобрели экстремальное программирование (XP), участвуя в проекте Chrysler Comprehensive Compensation System , включая непрерывную интеграцию. [1] [ самостоятельно опубликованный источник ] Бек опубликовал в 1998 году о непрерывной интеграции, подчеркивая важность личного общения по сравнению с технологической поддержкой. [10] В 1999 году Бек более подробно остановился на своей первой полной книге по экстремальному программированию. [11] CruiseControl , один из первых инструментов CI с открытым исходным кодом, [12] [ самостоятельно опубликованный источник ] был выпущен в 2001 году.
Общие практики [ править ]
 | Этот раздел содержит инструкции, советы или практические советы . ( Май 2015 г. ) |
В этом разделе перечислены лучшие практики, предложенные различными авторами о том, как добиться непрерывной интеграции и как автоматизировать эту практику. Автоматизация сборки - это лучшая практика. [13] [14]
Непрерывная интеграция - практика частой интеграции нового или измененного кода с существующим репозиторием кода - должна происходить достаточно часто, чтобы не оставалось промежуточного окна между фиксацией и сборкой , и чтобы никакие ошибки не могли возникнуть, если разработчики их не заметят и не исправят немедленно. [1]Обычная практика - запускать эти сборки при каждой фиксации в репозитории, а не при периодически запланированной сборке. Практичность выполнения этого в среде быстрых коммитов с несколькими разработчиками такова, что обычно запускается через короткое время после каждой фиксации, а затем запускается сборка, когда либо истекает этот таймер, либо после довольно длительного интервала с момента последней сборки. . Обратите внимание, что, поскольку каждая новая фиксация сбрасывает таймер, используемый для кратковременного триггера, это тот же метод, который используется во многих алгоритмах блокировки кнопок. [15] Таким образом, события фиксации «блокируются», чтобы предотвратить ненужные сборки между сериями быстрых фиксаций. Многие автоматизированные инструменты предлагают это планирование автоматически.
Другой фактор - необходимость в системе контроля версий, поддерживающей атомарные коммиты ; т.е. все изменения разработчика можно рассматривать как одну операцию фиксации. Нет смысла пытаться собрать только половину измененных файлов.
Для достижения этих целей непрерывная интеграция основана на следующих принципах.
Ведение репозитория кода [ править ]
Эта практика рекомендует использовать систему контроля версий для исходного кода проекта. Все артефакты, необходимые для сборки проекта, следует поместить в репозиторий. В этой практике и в сообществе по контролю версий принято, что система должна быть построена из свежей проверки и не требовать дополнительных зависимостей. Сторонник экстремального программирования Мартин Фаулер также упоминает, что там, где ветвление поддерживается инструментами, его использование следует минимизировать. [16] Вместо этого, предпочтительно, чтобы изменения были интегрированы, а не для одновременного обслуживания нескольких версий программного обеспечения. Основная линия (или магистраль ) должна быть местом для рабочей версии программного обеспечения.
Автоматизировать сборку [ править ]
Одна команда должна иметь возможность построить систему. Многие инструменты сборки, такие как make , существуют уже много лет. Другие новейшие инструменты часто используются в средах непрерывной интеграции. Автоматизация сборки должна включать автоматизацию интеграции, которая часто включает развертывание в производственной среде . Во многих случаях сценарий сборки не только компилирует двоичные файлы, но также создает документацию, страницы веб-сайтов, статистику и средства распространения (например, файлы Debian DEB , Red Hat RPM или Windows MSI ).
Сделайте самотестирование сборки [ править ]
После того, как код построен, все тесты должны быть запущены, чтобы подтвердить, что он ведет себя так, как ожидают разработчики. [17]
Все придерживаются базовых показателей каждый день [ править ]
Регулярно совершая коммит, каждый коммиттер может уменьшить количество конфликтующих изменений. Проверка работы на неделю может привести к конфликту с другими функциями, и ее может быть очень трудно решить. Ранние, небольшие конфликты в области системы заставляют членов команды сообщать о вносимых ими изменениях. [18] Фиксация всех изменений не реже одного раза в день (один раз для каждой созданной функции) обычно считается частью определения непрерывной интеграции. Кроме того, обычно рекомендуется выполнять ночную сборку . [ необходима цитата ] Это нижние границы; Ожидается, что типичная частота будет намного выше.
Каждая фиксация (до базовой линии) должна быть построена [ править ]
Система должна собрать коммиты для текущей рабочей версии, чтобы убедиться, что они правильно интегрируются. Распространенной практикой является использование автоматизированной непрерывной интеграции, хотя это можно сделать вручную. Автоматическая непрерывная интеграция использует сервер или демон непрерывной интеграции для отслеживания изменений в системе контроля версий , а затем автоматически запускает процесс сборки.
Каждая фиксация исправления ошибок должна сопровождаться тестовым набором [ править ]
При исправлении ошибки рекомендуется запустить тестовый пример, который воспроизводит ошибку. Это позволяет избежать отмены исправления и повторного появления ошибки, что называется регрессией . Исследователи предложили автоматизировать эту задачу: если фиксация исправления ошибки не содержит тестового примера, его можно сгенерировать из уже существующих тестов. [19]
Продолжайте сборку [ править ]
Сборку необходимо завершить быстро, чтобы при возникновении проблемы с интеграцией ее можно было быстро выявить.
Протестируйте в клоне производственной среды [ править ]
Наличие тестовой среды может привести к сбоям в тестируемых системах при их развертывании в производственной среде, поскольку производственная среда может существенно отличаться от тестовой среды. Однако создание реплики производственной среды непомерно дорого. Вместо этого следует создать тестовую среду или отдельную предпроизводственную среду («промежуточную»), которая станет масштабируемой версией производственной среды, чтобы снизить затраты при сохранении состава и нюансов стека технологий . В этих тестовых средах виртуализация сервисов обычно используется для получения доступа по требованию к зависимостям (например, API, сторонние приложения, сервисы, мэйнфреймыи т. д.), которые находятся вне контроля команды, все еще развиваются или слишком сложны для настройки в виртуальной лаборатории тестирования.
Упростите получение последних результатов [ править ]
Обеспечение доступности сборок для заинтересованных сторон и тестировщиков может уменьшить количество доработок, необходимых при перестройке функции, которая не соответствует требованиям. Кроме того, раннее тестирование снижает вероятность того, что дефекты сохранятся до развертывания. Раннее обнаружение ошибок может сократить объем работы, необходимой для их устранения.
Все программисты должны начать свой день с обновления проекта из репозитория. Таким образом, все они будут в курсе последних событий.
Все могут увидеть результаты последней сборки [ править ]
Должно быть легко узнать, не работает ли сборка, и если да, то кто внес соответствующее изменение и что это было за изменение.
Автоматизировать развертывание [ править ]
Большинство систем CI позволяют запускать сценарии после завершения сборки. В большинстве случаев можно написать сценарий для развертывания приложения на живом тестовом сервере, на который может взглянуть каждый. Еще одним достижением в этом способе мышления является непрерывное развертывание , которое требует развертывания программного обеспечения непосредственно в производственной среде, часто с дополнительной автоматизацией для предотвращения дефектов или регрессов. [20] [21]
Затраты и выгоды [ править ]
 | Нейтральность этого раздела оспаривается . ( Май 2016 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
Этот раздел требует дополнительных ссылок для проверки . ( Май 2016 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
Непрерывная интеграция предназначена для получения таких преимуществ, как:
- Ошибки интеграции обнаруживаются на ранней стадии, и их легко отследить благодаря небольшим наборам изменений. Это экономит время и деньги на протяжении всего проекта.
- Избегает хаоса в последнюю минуту в момент выпуска, когда все пытаются проверить свои слегка несовместимые версии
- Когда модульные тесты терпят неудачу или возникает ошибка , если разработчикам необходимо вернуть кодовую базу в состояние без ошибок без отладки , теряется только небольшое количество изменений (поскольку интеграция происходит часто)
- Постоянная доступность «текущей» сборки для тестирования, демонстрации или выпуска.
- Частая проверка кода подталкивает разработчиков к созданию модульного, менее сложного кода [ необходима ссылка ]
Преимущества непрерывного автоматизированного тестирования могут включать:
- Обеспечивает дисциплину частого автоматизированного тестирования
- Мгновенная обратная связь об общесистемном влиянии локальных изменений
- Метрики программного обеспечения , полученные от автоматизированного тестирования и CI (таких как метрики для покрытия кода , сложности коды , и полноты возможностей ) разработчики сосредоточиться на разработку функциональных, качественный код, но и помогают развить импульс в команде [ править ]
Некоторые недостатки непрерывной интеграции могут включать:
- Создание автоматизированного набора тестов требует значительного объема работы, включая постоянные усилия по охвату новых функций и отслеживанию преднамеренных модификаций кода.
- Тестирование считается лучшей практикой разработки программного обеспечения само по себе, независимо от того, используется ли непрерывная интеграция или нет, а автоматизация является неотъемлемой частью проектных методологий, таких как разработка через тестирование .
- Непрерывная интеграция может выполняться без какого-либо набора тестов, но стоимость обеспечения качества для выпуска готового к выпуску продукта может быть высокой, если это нужно делать вручную и часто.
- Требуется некоторая работа по настройке системы сборки , которая может стать сложной, что затрудняет гибкое изменение. [22]
- Однако существует ряд проектов программного обеспечения непрерывной интеграции , как проприетарных, так и с открытым исходным кодом, которые можно использовать.
- Непрерывная интеграция не обязательно полезна, если объем проекта невелик или содержит непроверяемый унаследованный код.
- Добавленная стоимость зависит от качества тестов и от того, насколько тестируемый код на самом деле. [23]
- Большие группы означают, что новый код постоянно добавляется в очередь интеграции, поэтому отслеживать доставки (при сохранении качества) сложно, а создание очереди сборки может замедлить всех. [23]
- При нескольких фиксациях и слияниях в день частичный код для функции можно легко отправить, и поэтому тесты интеграции не будут выполнены, пока функция не будет завершена. [23]
- Обеспечение безопасности и критически важных разработок (например, DO-178C , ISO 26262 ) требует тщательной документации и анализа в процессе, чего трудно достичь с помощью непрерывной интеграции. Этот тип жизненного цикла часто требует выполнения дополнительных шагов до выпуска продукта, когда требуется одобрение продукта регулирующими органами.
См. Также [ править ]
- Автоматизация выпуска приложений
- Индикатор сборки
- Сравнение программного обеспечения непрерывной интеграции
- Непрерывный дизайн
- Непрерывное тестирование
- Многоступенчатая непрерывная интеграция
- Быстрая разработка приложений
Ссылки [ править ]
- ^ a b c Фаулер, Мартин (1 мая 2006 г.). «Непрерывная интеграция» . Проверено 9 января 2014 .
- ^ Буча, Грейди (1991). Объектно-ориентированный дизайн: с приложениями . Бенджамин Каммингс . п. 209. ISBN. 9780805300918. Проверено 18 августа 2014 .
- ^ Бек, К. (1999). «Принятие изменений с помощью экстремального программирования». Компьютер . 32 (10): 70–77. DOI : 10.1109 / 2.796139 . ISSN 0018-9162 .
- Перейти ↑ Duvall, Paul M. (2007). Непрерывная интеграция. Повышение качества программного обеспечения и снижение риска . Эддисон-Уэсли. ISBN 978-0-321-33638-5.
- ↑ Каннингем, Уорд (5 августа 2009 г.). «Интеграционный ад» . WikiWikiWeb . Проверено 19 сентября 2009 года .
- ^ "Что такое непрерывная интеграция?" . Amazon Web Services .
- ^ Дюрье, Томас; Абреу, Руи; Монперрус, Мартин; Bissyande, Tegawende F .; Круз, Луис (2019). «Анализ более 35 миллионов рабочих мест Трэвиса Си». 2019 IEEE Международная конференция по разработке программного обеспечения технического обслуживания и развития (ICSME) . IEEE: 291–295. arXiv : 1904.09416 . Bibcode : 2019arXiv190409416D . DOI : 10.1109 / ICSME.2019.00044 . ISBN 978-1-7281-3094-1. S2CID 203593737 .
- ^ Кайзер, GE; Perry, DE; Шелл, WM (1989). Infuse: объединение управления тестированием интеграции с управлением изменениями . Материалы тринадцатой ежегодной международной конференции по компьютерному программному обеспечению и приложениям. Орландо, Флорида. С. 552–558. DOI : 10.1109 / CMPSAC.1989.65147 .
- ^ Буча, Грейди (декабрь 1998). Объектно-ориентированный анализ и дизайн с приложениями (PDF) (2-е изд.) . Проверено 2 декабря 2014 .
- ↑ Бек, Кент (28 марта 1998 г.). «Экстремальное программирование: гуманистическая дисциплина разработки программного обеспечения» . Фундаментальные подходы к программной инженерии: первая международная конференция . 1 . Лиссабон, Португалия: Спрингер . п. 4. ISBN 9783540643036.
- ^ Бек, Кент (1999). Объяснение экстремального программирования . Эддисон-Уэсли Профессионал. п. 97 . ISBN 978-0-201-61641-5.
- ^ «Краткая история DevOps, часть III: автоматическое тестирование и непрерывная интеграция» . CircleCI . 1 февраля 2018 . Проверено 19 мая 2018 .
- ^ Brauneis, Дэвид (1 января 2010). «[OSLC] Возможная новая рабочая группа - Автоматизация» . Сообщество open-services.net (список рассылки). Архивировано из оригинала на 1 сентября 2018 года . Проверено 16 февраля 2010 года .
- ^ Тейлор, Брэдли. «Развертывание и автоматизация Rails с ShadowPuppet и Capistrano» . Rails machine ( журнал всемирной паутины ). Архивировано из оригинального 2 -го декабря 2012 года . Проверено 16 февраля 2010 года .
- ^ См., Например, «Debounce» . Ардуино . 29 июля 2015 г.
- ^ Фаулер, Мартин . «Практики» . Непрерывная интеграция (статья) . Проверено 29 ноября 2015 года .
- ^ Радиган, Дэн. «Непрерывная интеграция» . Atlassian Agile Coach .
- ^ «Непрерывная интеграция» . Мыслительные работы .
- ^ Данглот, Бенджамин; Монперрус, Мартин; Рудаметкин, Вальтер; Бодри, Бенуа (5 марта 2020 г.). «Подход и эталон для обнаружения поведенческих изменений коммитов в непрерывной интеграции». Эмпирическая программная инженерия . 25 (4): 2379–2415. arXiv : 1902.08482 . DOI : 10.1007 / s10664-019-09794-7 . ISSN 1382-3256 . S2CID 67856113 .
- ^ Риз, Эрик (30 марта 2009). «Непрерывное развертывание за 5 простых шагов» . Радар . О'Рейли . Проверено 10 января 2013 года .
- ↑ Фитц, Тимоти (10 февраля 2009 г.). «Непрерывное развертывание в IMVU: делать невозможное пятьдесят раз в день» . Wordpress . Проверено 10 января 2013 года .
- ^ Laukkanen, Ээро (2016). «Проблемы, причины и решения при внедрении непрерывной доставки - систематический обзор литературы» . Информационные и программные технологии . 82 : 55–79. DOI : 10.1016 / j.infsof.2016.10.001 .
- ^ a b c Деббиш, Адам. «Оценка проблем непрерывной интеграции в контексте разбивки требований к программному обеспечению: тематическое исследование» (PDF) .
Внешние ссылки [ править ]
- «Непрерывная интеграция» (вики) (коллективное обсуждение). C2. Цитировать журнал требует
|journal=( помощь ) - Ричардсон, Джаред. «Непрерывная интеграция: краеугольный камень большого магазина» (введение).
- Цветы, Джей. «Рецепт ремонтопригодности и повторного использования сборки» . Архивировано из оригинального 25 июня 2020 года . Проверено 28 мая 2006 года .
- Дюваль, Поль (4 декабря 2007 г.). «Застройщик работает» .
- «Жизненный цикл версии» . MediaWiki.
- «Непрерывная интеграция в облаке» (PDF) . CrossTalk. 2016 г.[ постоянная мертвая ссылка ]
- «Введение в непрерывную интеграцию» . Каталон. 2019.
- Бугаенко, Егор. «Почему непрерывная интеграция не работает»
