Многоступенчатая непрерывная интеграция - Multi-stage continuous integration - Wikipedia

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

Теория

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

Рекомендуемые практики

Многоступенчатая непрерывная интеграция - это расширение непрерывная интеграция, предполагается, что вы уже соблюдаете эти рекомендуемые методы.

Чем крупнее и / или сложнее проект, тем выше вероятность того, что он станет нестабильным. Количество предупреждений и неработающих сборок увеличивается по мере роста проекта. Прогресс уменьшается, и основная линия становится все более нестабильной. Риск сбоя сборки возрастает экспоненциально по мере роста количества и местоположения разработчиков.[2]

Рекомендуемая практика # 1

Каждый разработчик работает над своей задачей. По мере внесения изменений выполняется непрерывная интеграция с ветвью этой команды. Если это не удается, то этот разработчик (возможно, с помощью своих товарищей по команде) исправляет ветку. Когда возникает проблема, это затрагивает только эту команду, а не все усилия по разработке. Это похоже на то, как остановка линии работает на современном бережливом производстве. Если кто-то на линии тянет за шнур "остановить линию", это влияет только на ее сегмент, а не на всю линию.

Примечательно, что в последние годы модель ветвления «тема» или «функция» приобрела популярность по сравнению с моделью ветвления на основе команды. См., Например, популярную модель ветвления Git-Flow [3]

Часто команда решает перейти ко второму этапу: интеграции с основной линией. На этом этапе команда делает то же самое, что и отдельный человек в случае основной разработки. В ветке команды должны быть объединены все изменения из основной ветки (эквивалент обновления рабочей области), должна быть успешная сборка и все тесты должны пройти. Интеграция с основной веткой будет проще, чем обычно, потому что в ней будут только предварительно интегрированные функции, а не функции в процессе. Затем изменения команды объединяются в основную ветку, что запускает цикл сборки и тестирования на основной ветке. Если это пройдет, команда вернется к первому этапу, когда отдельные разработчики работают над своими задачами. В противном случае команда работает над тем, чтобы заставить основную ветку снова работать, как если бы они были отдельным человеком, работающим над основной веткой.

Изменения распространяются максимально быстро, останавливаясь только при возникновении проблемы. В идеале изменения вносятся в основную область интеграции так же часто, как и при основной разработке. Разница в том, что меньше проблем попадает в основную зону интеграции. Многоступенчатая непрерывная интеграция позволяет выполнять высокую степень интеграции параллельно, значительно сокращая при этом объем проблем интеграции.[4]

Рекомендуемая практика # 2

Для многоэтапной непрерывной интеграции у каждой команды должно быть свое отделение.

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

Многоступенчатая непрерывная интеграция имеет множество преимуществ:[нужна цитата ]

  • Когда модульные тесты терпят неудачу или обнаруживается ошибка, разработчики могут вернуть кодовую базу обратно в состояние без ошибок, не теряя времени. отладка;
  • Проблемы интеграции выявляются и исправляются непрерывно - никаких перерывов в последнюю минуту перед датами выпуска;
  • Раннее предупреждение о сломанном / несовместимом коде;
  • Раннее предупреждение о противоречивых изменениях;
  • Мгновенное модульное тестирование всех изменений;
  • Постоянная доступность «текущей» сборки для тестирования, демонстрации или выпуска;
  • Непосредственное влияние проверки неполного или неработающего кода побуждает разработчиков учиться работать более последовательно с более короткими циклами обратной связи.

Инструменты

Инструменты, поддерживающие многоэтапную непрерывную интеграцию, включают:

  • AccuRev[5] - Контроль версий и ALM инструмент
  • Электрическое облако[6] - Средство разработки, тестирования и развертывания, предназначенное для автоматизации жизненного цикла производства программного обеспечения.
  • AnthillPro - Инструмент сборки, зависимости, выпуска [7]
  • Концерт Rational Team[8] ALM-Платформа

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

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

  1. ^ http://www.ddj.com/development-tools/212201506 Многоступенчатая непрерывная интеграция, дата обращения 25 февраля 2009 г., Пул, Дэймон, 02 декабря 2008 г., Dr. Dobb's, опубликовано TechWeb
  2. ^ http://damonpoole.blogspot.com/2008/01/advanced-multi-stage-continous.html Расширенная многоэтапная интеграция, дата обращения 19 марта 2009 г., Пул, Дэймон, 17 января 2009 г. Мысли о гибкой разработке
  3. ^ http://nvie.com/posts/a-successful-git-branching-model/
  4. ^ http://www.cmcrossroads.com/content/view/12685/135/[постоянная мертвая ссылка ] Крупномасштабная непрерывная интеграция, Пул, Дэймон, 2009-01-19 CMCrossroads Опубликовано CMC Media
  5. ^ http://www.accurev.com/press-releases/030408-accurev-electriccloud.html В архиве 2008-07-20 на Wayback Machine Партнер AccuRev и Electric Cloud по развитию многоступенчатой ​​непрерывной интеграции и передовых методов масштабируемой гибкой разработки, дата обращения 19 марта 2009 г.
  6. ^ http://www.accurev.com/press-releases/030408-accurev-electriccloud.html В архиве 2008-07-20 на Wayback Machine Партнер AccuRev и Electric Cloud по развитию многоступенчатой ​​непрерывной интеграции и передовых методов масштабируемой гибкой разработки, дата обращения 19 марта 2009 г.
  7. ^ http://www.anthillpro.com/html/resources/build-pain-relief/team-based-streams.html Руководство по созданию безболезненных: командные потоки
  8. ^ http://jazz.net/