stringtranslate.com

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

Эскиз блок-схемы для непрерывной интеграции

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

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

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

История

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

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

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

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

Практики

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

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

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

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

Автоматизация сборки

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

Атомарные коммиты

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

Внесение изменений

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

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

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

Тестирование на местном уровне

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

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

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

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

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

Контроль версий

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

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

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

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

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

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

Совершайте часто

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

Ежедневная сборка

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

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

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

Каждый коммит по исправлению ошибки должен сопровождаться тестовым случаем.

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

Продолжайте строить быстро

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

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

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

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

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

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

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

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

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

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

Преимущества

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

Риски

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

Лучшие практики для облачных систем

Следующие методы могут повысить производительность конвейеров , особенно в системах, размещенных в облаке : [23] [24] [25]

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

Ссылки

  1. ^ abc Fowler, Martin (1 мая 2006 г.). "Continuous Integration" . Получено 9 января 2014 г. .
  2. ^ Booch, Grady (1991). Объектно-ориентированное проектирование: с приложениями. Benjamin Cummings . стр. 209. ISBN 9780805300918. Получено 18 августа 2014 г.
  3. ^ Бек, К. (1999). «Принятие изменений с помощью экстремального программирования». Компьютер . 32 (10): 70–77. doi :10.1109/2.796139. ISSN  0018-9162.
  4. ^ Kaiser, GE; Perry, DE; Schell, WM (1989). Infuse: объединение управления интеграционным тестированием с управлением изменениями . Труды тринадцатой ежегодной международной конференции по компьютерному программному обеспечению и приложениям. Орландо, Флорида. С. 552–558. CiteSeerX 10.1.1.101.3770 . doi :10.1109/CMPSAC.1989.65147. 
  5. ^ Booch, Grady (декабрь 1998 г.). Object-Oriented Analysis and Design with applications (PDF) (2-е изд.). Архивировано из оригинала (PDF) 19 августа 2019 г. Получено 2 декабря 2014 г.
  6. ^ Бек, Кент (28 марта 1998 г.). "Экстремальное программирование: гуманистическая дисциплина разработки программного обеспечения". Фундаментальные подходы к программной инженерии: Первая международная конференция . Том 1. Лиссабон, Португалия: Springer . стр. 4. ISBN 9783540643036.
  7. ^ Бек, Кент (1999). Экстремальное программирование . Addison-Wesley Professional. стр. 97. ISBN 978-0-201-61641-5.
  8. ^ «Краткая история DevOps, часть III: автоматизированное тестирование и непрерывная интеграция». CircleCI . 1 февраля 2018 г. . Получено 19 мая 2018 г. .
  9. ^ Sane, Parth (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 Coach .
  11. ^ Браунеис, Дэвид (1 января 2010 г.). «[OSLC] Возможная новая рабочая группа – Автоматизация». Сообщество open-services.net (список рассылки). Архивировано из оригинала 1 сентября 2018 г. Получено 16 февраля 2010 г.
  12. ^ Тейлор, Брэдли. «Rails Deployment and Automation with ShadowPuppet and Capistrano». Rails machine ( блог ). Архивировано из оригинала 2 декабря 2012 г. Получено 16 февраля 2010 г.
  13. ^ Дюваль, Пол М. (2007). Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска . Addison-Wesley. ISBN 978-0-321-33638-5.
  14. ↑ Каннингем, Уорд (5 августа 2009 г.). «Ад интеграции». WikiWikiWeb . Получено 19 сентября 2009 г. .
  15. ^ «Что такое непрерывная интеграция?». Amazon Web Services .
  16. ^ Фаулер, Мартин . "Практики". Непрерывная интеграция (статья) . Получено 29 ноября 2015 г.
  17. ^ Пол М. Дюваль; Стив Матьяс; Эндрю Гловер (2007). Непрерывная интеграция: улучшение качества программного обеспечения и снижение риска . Addison-Wesley Professional . ISBN 978-0-321-33638-5.
  18. ^ Райс, Эрик (30 марта 2009 г.). «Непрерывное развертывание за 5 простых шагов». Радар . O'Reilly . Получено 10 января 2013 г. .
  19. ^ Фиц, Тимоти (10 февраля 2009 г.). «Непрерывное развертывание в IMVU: Делая невозможное пятьдесят раз в день». Wordpress . Получено 10 января 2013 г.
  20. ^ Junpeng, Jiang; Zhu, Can; Zhang, Xiaofang (июль 2020 г.). «Эмпирическое исследование влияния участника кода на запах кода» (PDF) . International Journal of Performability Engineering . 16 (7): 1067–1077. doi :10.23940/ijpe.20.07.p9.10671077. S2CID  222588815.
  21. ^ Лаукканен, Ээро (2016). «Проблемы, причины и решения при принятии непрерывной доставки — систематический обзор литературы». Информационные и программные технологии . 82 : 55–79. doi : 10.1016/j.infsof.2016.10.001 .
  22. ^ abc Деббиш, Адам. «Оценка проблем непрерывной интеграции в контексте разбивки требований к программному обеспечению: пример» (PDF) .
  23. ^ Serverless Architectures on AWS . Мэннинг. ISBN 978-1617295423.
  24. ^ Pipeline as Code Continuous Delivery с Jenkins, Kubernetes и Terraform . Мэннинг. ISBN 9781638350378.
  25. ^ Непрерывная поставка надежных релизов программного обеспечения посредством автоматизации сборки, тестирования и развертывания . ISBN 9780321670229.

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