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

Непрерывная интеграция ( CI ) — это практика частой интеграции изменений исходного кода и обеспечения работоспособности интегрированной кодовой базы.

Обычно разработчики объединяют изменения в интеграционную ветку , а автоматизированная система собирает и тестирует программную систему . ^[1] Часто автоматизированный процесс запускается при каждом коммите или по расписанию, например один раз в день.

Грэди Буч впервые предложил термин CI в 1991 году . ^[2] хотя он и не выступал за интеграцию несколько раз в день, но позже CI стал включать этот аспект. ^[3]

История [ править ]

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

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

В 1997 году Кент Бек и Рон Джеффрис изобрели экстремальное программирование (XP) во время работы над проектом комплексной системы вознаграждения Chrysler , включая непрерывную интеграцию. ^[1]^{[ самостоятельный источник ]} Бек опубликовал статью о непрерывной интеграции в 1998 году, подчеркнув важность личного общения над технологической поддержкой. ^[6] В 1999 году Бек подробно рассказал об этом в своей первой полной книге «Экстремальное программирование». ^[7] CruiseControl , один из первых инструментов CI с открытым исходным кодом. ^[8]^{[ самостоятельный источник ]} был выпущен в 2001 году.

В 2010 году Тимоти Фитц опубликовал статью, в которой подробно описывалось, как команда инженеров IMVU создала и использовала первую практическую систему CI. Хотя его пост изначально был встречен со скептицизмом, он быстро прижился и нашел широкое распространение. ^[9] в рамках бережливой методологии разработки программного обеспечения , также основанной на IMVU.

Практики [ править ]

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

Обычно сервер часто строится из области интеграции; т.е. после каждого коммита или периодически, например, раз в день. Сервер может выполнять проверки контроля качества , такие как запуск модульных тестов. ^[10] и собирать показатели качества программного обеспечения с помощью таких процессов, как статический анализ и тестирование производительности.

Связанные практики [ править ]

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

Автоматизация сборки [ править ]

Автоматизация сборки — лучшая практика. ^[11]^[12]

Атомные коммиты [ править ]

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

Внесение изменений [ править ]

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

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

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

Тестирование локально [ править ]

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

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

Непрерывная доставка и непрерывное развертывание [ править ]

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

Непрерывная доставка и непрерывное развертывание часто выполняются совместно с CI и вместе образуют конвейер CI/CD.

Контроль версий [ править ]

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

Мартин Фаулер рекомендует всем разработчикам использовать одну и ту же ветку интеграции. ^[16]

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

Инструменты автоматизации сборки автоматизируют сборку.

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

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

Совершайте часто [ править ]

Разработчики могут сократить усилия по разрешению конфликтующих изменений, часто синхронизируя изменения друг с другом; хотя бы ежедневно. Проверка результатов работы за неделю может привести к конфликту как по вероятности возникновения, так и по сложности разрешения. Относительно небольшие конфликты разрешать значительно легче, чем более крупные. Интеграция (фиксация) изменений хотя бы раз в день считается хорошей практикой, а лучше — чаще. ^[17]

Ежедневная сборка [ править ]

строить ежедневно , если не чаще. Обычно рекомендуется ^{[ нужна цитата ]}

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

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

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

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

Делайте сборку быстрой [ править ]

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

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

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

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

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

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

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

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

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

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

Преимущества [ править ]

Преимущества CI включают в себя:

Облегчает обнаружение ошибок раньше
Уменьшает усилия по поиску причины ошибок; если тест CI не пройден, то изменения, произошедшие с момента последней хорошей сборки, содержат вызывающие изменения; если выполнять сборку после каждого изменения, то причиной является ровно одно изменение ^[1]
Избегает хаоса, связанного с интеграцией множества изменений
При неудачном тесте или обнаружении ошибки возврат кодовой базы в хорошее состояние приводит к меньшему количеству потерянных изменений.
Частая доступность заведомо исправной сборки для тестирования, демонстрации и выпуска.
Частая фиксация кода способствует созданию модульного и менее сложного кода. ^[20]
Быстрая обратная связь о влиянии изменений кода на всю систему
Поддерживает сбор показателей программного обеспечения , таких как покрытие кода и сложность кода .

Риски [ править ]

Риски CI включают в себя:

Настройка системы сборки требует усилий ^[21]
Написание и поддержка набора автоматизированных тестов требует усилий.
Добавленная стоимость зависит от качества тестов ^[22]
Высокая задержка сборки (нахождение в очереди) ограничивает ценность ^[22]
Подразумевается, что неполный код не следует интегрировать, что противоречит предпочтительной практике некоторых разработчиков. ^[22]
Обеспечение безопасности и критически важных разработок (например, DO-178C , ISO 26262 ) требуют документирования и проверки, чего может быть трудно достичь.

См. также [ править ]

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

Ссылки [ править ]

^ Перейти обратно: ^а ^б ^с Фаулер, Мартин (1 мая 2006 г.). «Непрерывная интеграция» . Проверено 9 января 2014 г.
^ Буч, Грейди (1991). Объектно-ориентированное проектирование: с приложениями . Бенджамин Каммингс . п. 209. ИСБН 9780805300918 . Проверено 18 августа 2014 г.
^ Бек, К. (1999). «Принятие перемен с помощью экстремального программирования». Компьютер . 32 (10): 70–77. дои : 10.1109/2.796139 . ISSN 0018-9162 .
^ Кайзер, GE; Перри, Делавэр; Шелл, WM (1989). Infuse: объединение управления интеграционным тестированием с управлением изменениями . Материалы тринадцатой ежегодной международной конференции по компьютерному программному обеспечению и приложениям. Орландо, Флорида. стр. 552–558. CiteSeerX 10.1.1.101.3770 . дои : 10.1109/CMPSAC.1989.65147 .
^ Буч, Грейди (декабрь 1998 г.). Объектно-ориентированный анализ и проектирование с приложениями (PDF) (2-е изд.). Архивировано из оригинала (PDF) 19 августа 2019 года . Проверено 2 декабря 2014 г.
^ Бек, Кент (28 марта 1998 г.). «Экстремальное программирование: гуманистическая дисциплина разработки программного обеспечения» . Фундаментальные подходы к программной инженерии: Первая международная конференция . Том. 1. Лиссабон, Португалия: Спрингер . п. 4. ISBN 9783540643036 .
^ Бек, Кент (1999). Объяснение экстремального программирования . Аддисон-Уэсли Профессионал. п. 97 . ISBN 978-0-201-61641-5 .
^ «Краткая история DevOps, часть III: автоматизированное тестирование и непрерывная интеграция» . КругCI . 1 февраля 2018 года . Проверено 19 мая 2018 г.
^ Сане, Парт (2021 г.), «Краткий обзор современных практик разработки программного обеспечения в области непрерывной интеграции и автоматического тестирования доступности» , Шестая международная конференция по беспроводной связи, обработке сигналов и сетям (WiSPNET) , 2021 г., стр. 130–134, arXiv : 2103.00097 , doi : 10.1109/WiSPNET51692.2021.9419464 , ISBN 978-1-6654-4086-8 , S2CID 232076320
^ Рэдиган, Дэн. «Непрерывная интеграция» . Atlassian Agile-коуч .
^ Браунейс, Дэвид (1 января 2010 г.). «[OSLC] Возможна новая рабочая группа – Автоматизация» . Сообщество open-services.net (список рассылки). Архивировано из оригинала 1 сентября 2018 года . Проверено 16 февраля 2010 г.
^ Тейлор, Брэдли. «Развертывание и автоматизация Rails с помощью ShadowPuppet и Capistrano» . Машина Rails ( блог ). Архивировано из оригинала 2 декабря 2012 года . Проверено 16 февраля 2010 г.
^ Дюваль, Пол М. (2007). Непрерывная интеграция. Улучшение качества программного обеспечения и снижение рисков . Аддисон-Уэсли. ISBN 978-0-321-33638-5 .
^ Каннингем, Уорд (5 августа 2009 г.). «Интеграционный ад» . ВикиВикиВеб . Проверено 19 сентября 2009 г.
^ «Что такое непрерывная интеграция?» . Веб-сервисы Amazon .
^ Фаулер, Мартин . «Практики» . Непрерывная интеграция (статья) . Проверено 29 ноября 2015 г.
^ Пол М. Дюваль; Стив Матьяс; Эндрю Гловер (2007). Непрерывная интеграция: повышение качества программного обеспечения и снижение рисков . Аддисон-Уэсли Профессионал . ISBN 978-0-321-33638-5 .
^ Райс, Эрик (30 марта 2009 г.). «Непрерывное развертывание за 5 простых шагов» . Радар . О'Рейли . Проверено 10 января 2013 г.
^ Фитц, Тимоти (10 февраля 2009 г.). «Непрерывное развертывание в IMVU: делать невозможное пятьдесят раз в день» . Вордпресс . Проверено 10 января 2013 г.
^ Цзюньпэн, Цзян; Чжу, Джан; Чжан, Сяофан (июль 2020 г.). «Эмпирическое исследование влияния участника кода на запах кода» (PDF) . Международный журнал инженерной производительности . 16 (7): 1067–1077. дои : 10.23940/ijpe.20.07.p9.10671077 . S2CID 222588815 .
^ Лаукканен, Ээро (2016). «Проблемы, причины и решения при внедрении непрерывной доставки — систематический обзор литературы» . Информационные и программные технологии . 82 : 55–79. дои : 10.1016/j.infsof.2016.10.001 .
^ Перейти обратно: ^а ^б ^с Деббиш, Адам. «Оценка проблем непрерывной интеграции в контексте разбивки требований к программному обеспечению: практический пример» (PDF) .

Внешние ссылки [ править ]

«Непрерывная интеграция» (вики) (коллегиальное обсуждение). С2. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
Ричардсон, Джаред. «Непрерывная интеграция: краеугольный камень отличного магазина» (введение).
Цветы, Джей. «Рецепт ремонтопригодности и возможности повторного использования сборки» . Архивировано из оригинала 25 июня 2020 года . Проверено 28 мая 2006 г.
Дюваль, Поль (4 декабря 2007 г.). «Разработчик работает» . ИБМ .
«Жизненный цикл версии» . МедиаВики. Июнь 2024.

[martinfowler-1] Перейти обратно: ^а ^б ^с Фаулер, Мартин (1 мая 2006 г.). «Непрерывная интеграция» . Проверено 9 января 2014 г.

[2] Буч, Грейди (1991). Объектно-ориентированное проектирование: с приложениями . Бенджамин Каммингс . п. 209. ИСБН 9780805300918 . Проверено 18 августа 2014 г.

[3] Бек, К. (1999). «Принятие перемен с помощью экстремального программирования». Компьютер . 32 (10): 70–77. дои : 10.1109/2.796139 . ISSN 0018-9162 .

[4] Кайзер, GE; Перри, Делавэр; Шелл, WM (1989). Infuse: объединение управления интеграционным тестированием с управлением изменениями . Материалы тринадцатой ежегодной международной конференции по компьютерному программному обеспечению и приложениям. Орландо, Флорида. стр. 552–558. CiteSeerX 10.1.1.101.3770 . дои : 10.1109/CMPSAC.1989.65147 .

[5] Буч, Грейди (декабрь 1998 г.). Объектно-ориентированный анализ и проектирование с приложениями (PDF) (2-е изд.). Архивировано из оригинала (PDF) 19 августа 2019 года . Проверено 2 декабря 2014 г.

[6] Бек, Кент (28 марта 1998 г.). «Экстремальное программирование: гуманистическая дисциплина разработки программного обеспечения» . Фундаментальные подходы к программной инженерии: Первая международная конференция . Том. 1. Лиссабон, Португалия: Спрингер . п. 4. ISBN 9783540643036 .

[Beck,_Extreme_Programming_Explained-7] Бек, Кент (1999). Объяснение экстремального программирования . Аддисон-Уэсли Профессионал. п. 97 . ISBN 978-0-201-61641-5 .

[8] «Краткая история DevOps, часть III: автоматизированное тестирование и непрерывная интеграция» . КругCI . 1 февраля 2018 года . Проверено 19 мая 2018 г.

[9] Сане, Парт (2021 г.), «Краткий обзор современных практик разработки программного обеспечения в области непрерывной интеграции и автоматического тестирования доступности» , Шестая международная конференция по беспроводной связи, обработке сигналов и сетям (WiSPNET) , 2021 г., стр. 130–134, arXiv : 2103.00097 , doi : 10.1109/WiSPNET51692.2021.9419464 , ISBN 978-1-6654-4086-8 , S2CID 232076320

[10] Рэдиган, Дэн. «Непрерывная интеграция» . Atlassian Agile-коуч .

[Brauneis,_[OSLC]_Possible_new_Working_Group_-_Automation-11] Браунейс, Дэвид (1 января 2010 г.). «[OSLC] Возможна новая рабочая группа – Автоматизация» . Сообщество open-services.net (список рассылки). Архивировано из оригинала 1 сентября 2018 года . Проверено 16 февраля 2010 г.

[Taylor,_Rails_Deployment_and_Automation_with_ShadowPuppet_and_Capistrano-12] Тейлор, Брэдли. «Развертывание и автоматизация Rails с помощью ShadowPuppet и Capistrano» . Машина Rails ( блог ). Архивировано из оригинала 2 декабря 2012 года . Проверено 16 февраля 2010 г.

[13] Дюваль, Пол М. (2007). Непрерывная интеграция. Улучшение качества программного обеспечения и снижение рисков . Аддисон-Уэсли. ISBN 978-0-321-33638-5 .

[Cunningham,_Integration_Hell-14] Каннингем, Уорд (5 августа 2009 г.). «Интеграционный ад» . ВикиВикиВеб . Проверено 19 сентября 2009 г.

[15] «Что такое непрерывная интеграция?» . Веб-сервисы Amazon .

[Fowler,_Continuous_Integration_practices-16] Фаулер, Мартин . «Практики» . Непрерывная интеграция (статья) . Проверено 29 ноября 2015 г.

[17] Пол М. Дюваль; Стив Матьяс; Эндрю Гловер (2007). Непрерывная интеграция: повышение качества программного обеспечения и снижение рисков . Аддисон-Уэсли Профессионал . ISBN 978-0-321-33638-5 .

[18] Райс, Эрик (30 марта 2009 г.). «Непрерывное развертывание за 5 простых шагов» . Радар . О'Рейли . Проверено 10 января 2013 г.

[19] Фитц, Тимоти (10 февраля 2009 г.). «Непрерывное развертывание в IMVU: делать невозможное пятьдесят раз в день» . Вордпресс . Проверено 10 января 2013 г.

[20] Цзюньпэн, Цзян; Чжу, Джан; Чжан, Сяофан (июль 2020 г.). «Эмпирическое исследование влияния участника кода на запах кода» (PDF) . Международный журнал инженерной производительности . 16 (7): 1067–1077. дои : 10.23940/ijpe.20.07.p9.10671077 . S2CID 222588815 .

[21] Лаукканен, Ээро (2016). «Проблемы, причины и решения при внедрении непрерывной доставки — систематический обзор литературы» . Информационные и программные технологии . 82 : 55–79. дои : 10.1016/j.infsof.2016.10.001 .

[:1-22] Перейти обратно: ^а ^б ^с Деббиш, Адам. «Оценка проблем непрерывной интеграции в контексте разбивки требований к программному обеспечению: практический пример» (PDF) .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]