Многоступенчатая непрерывная интеграция - это метод разработки программного обеспечения , предназначенный для достижения высокоинтегрированной параллельной разработки при уменьшении объема проблем интеграции. [1]
Теория [ править ]
Многоступенчатая непрерывная интеграция использует преимущества базовой унифицирующей модели разработки программного обеспечения: программное обеспечение поэтапно переходит из состояния незрелости в состояние зрелости, и работа разбивается на логические единицы, выполняемые взаимозависимыми группами, которые объединяют различные части вместе. через некоторое время. То, что меняется от магазина к магазину, - это количество этапов, количество и размер команд, а также структура взаимозависимостей команд.
Рекомендуемые практики [ править ]
Многоступенчатая непрерывная интеграция - это расширение непрерывной интеграции , при этом предполагается, что вы уже следуете этим рекомендуемым практикам.
Чем крупнее и / или сложнее проект, тем выше вероятность того, что он станет нестабильным. Количество предупреждений и неработающих сборок увеличивается по мере роста проекта. Прогресс уменьшается, и основная линия становится все более нестабильной. Риск сбоя сборки возрастает экспоненциально по мере роста количества и местоположения разработчиков. [2]
Рекомендуемая практика №1 [ править ]
Каждый разработчик работает над своей задачей. По мере внесения изменений выполняется непрерывная интеграция с ветвью этой команды. Если это не удается, то этот разработчик (возможно, с помощью своих товарищей по команде) исправляет ветку. Когда возникает проблема, это затрагивает только эту команду, а не все усилия по разработке. Это похоже на то, как остановка линии работает на современном бережливом производстве. Если кто-то на линии тянет за шнур "остановить линию", это влияет только на ее сегмент, а не на всю линию.
Примечательно, что в последние годы модель ветвления «тема» или «функция» приобрела популярность по сравнению с моделью ветвления на основе команды. См., Например, популярную модель ветвления Git-Flow [3]
Часто команда решает перейти ко второму этапу: интеграции с основной линией. На этом этапе команда делает то же самое, что и отдельный человек в случае основной разработки. В ветке команды должны быть объединены все изменения из основной ветки (эквивалент обновления рабочей области), должна быть успешная сборка и все тесты должны пройти. Интеграция с основной линией будет проще, чем обычно, потому что в ней будут только предварительно интегрированные функции, а не функции в процессе. Затем изменения команды объединяются в основную ветку, что запускает цикл сборки и тестирования на основной ветке. Если это пройдет, команда вернется к первому этапу, когда отдельные разработчики работают над своими задачами. В противном случае команда работает над тем, чтобы основная линия снова заработала,как если бы они были человеком, работающим на основной линии.
Изменения распространяются максимально быстро, останавливаясь только при возникновении проблемы. В идеале изменения вносятся в основную область интеграции так же часто, как и при основной разработке. Разница в том, что меньше проблем попадает в основную зону интеграции. Многоступенчатая непрерывная интеграция позволяет осуществлять высокую степень интеграции параллельно, значительно сокращая при этом объем проблем интеграции. [4]
Рекомендуемая практика №2 [ править ]
Для многоэтапной непрерывной интеграции у каждой команды должно быть свое отделение.
Преимущества [ править ]
Многоступенчатая непрерывная интеграция имеет много преимуществ: [ необходима цитата ]
- Когда модульные тесты терпят неудачу или обнаруживается ошибка, разработчики могут вернуть кодовую базу обратно в состояние без ошибок , не тратя время на отладку ;
- Проблемы интеграции выявляются и исправляются непрерывно - никаких перерывов в последнюю минуту перед датами выпуска;
- Раннее предупреждение о сломанном / несовместимом коде;
- Раннее предупреждение о противоречивых изменениях;
- Мгновенное модульное тестирование всех изменений;
- Постоянная доступность «текущей» сборки для тестирования, демонстрации или выпуска;
- Непосредственное влияние проверки неполного или неработающего кода побуждает разработчиков учиться работать более последовательно с более короткими циклами обратной связи.
Инструменты [ править ]
Инструменты, поддерживающие многоэтапную непрерывную интеграцию, включают:
- AccuRev [5] - Инструмент контроля версий и ALM
- Electric Cloud [6] - инструмент для создания, тестирования и развертывания, предназначенный для автоматизации жизненного цикла производства программного обеспечения.
- AnthillPro - инструмент для сборки, зависимостей, выпуска [7]
- Rational Team Concert [8] ALM-Платформа
См. Также [ править ]
- Гибкая разработка программного обеспечения
- Автоматизация сборки
- Непрерывный дизайн
- Непрерывная интеграция
- Разработка через тестирование
- Управление жизненным циклом приложений
Ссылки [ править ]
- ^ http://www.ddj.com/development-tools/212201506 Многоступенчатая непрерывная интеграция, дата обращения 25 февраля 2009 г., Пул, Дэймон, 02 декабря 2008 г., Dr. Dobb's, опубликовано TechWeb
- ^ http://damonpoole.blogspot.com/2008/01/advanced-multi-stage-continous.html Расширенная многоэтапная интеграция, дата обращения 19 марта 2009 г., Пул, Дэймон, 17 января 2009 г. Мысли о гибкой разработке
- ^ http://nvie.com/posts/a-successful-git-branching-model/
- ^ http://www.cmcrossroads.com/content/view/12685/135/ [ постоянная мертвая ссылка ] Крупномасштабная непрерывная интеграция, Пул, Дэймон, 19 января 2009 г. CMCrossroads Опубликовано CMC Media
- ^ http://www.accurev.com/press-releases/030408-accurev-electriccloud.html Архивировано 20 июля 2008 г.на сайте Wayback Machine AccuRev и Electric Cloud Partner для улучшения многоступенчатой непрерывной интеграции и передовых методов масштабируемой гибкой разработки, дата доступа 2009 г. -03-19
- ^ http://www.accurev.com/press-releases/030408-accurev-electriccloud.html Архивировано 20 июля 2008 г.на сайте Wayback Machine AccuRev и Electric Cloud Partner для улучшения многоступенчатой непрерывной интеграции и передовых методов масштабируемой гибкой разработки, дата доступа 2009 г. -03-19
- ^ http://www.anthillpro.com/html/resources/build-pain-relief/team-based-streams.html Руководство по созданию безболезненного: командные потоки
- ^ http://jazz.net/
