Многоэтапная непрерывная интеграция
Многоэтапная непрерывная интеграция — это метод разработки программного обеспечения, предназначенный для достижения высокоинтегрированной параллельной разработки при одновременном уменьшении объема проблем интеграции. [1]
Теория
[ редактировать ]Многоэтапная непрерывная интеграция использует преимущества базового объединяющего шаблона разработки программного обеспечения: программное обеспечение поэтапно переходит от состояния незрелости к состоянию зрелости, а работа разбивается на логические единицы, выполняемые взаимозависимыми командами, которые интегрируют различные части вместе. через некоторое время. Что меняется от цеха к цеху, так это количество этапов, количество и размер команд, а также структура взаимозависимостей команд.
Рекомендуемые практики
[ редактировать ]Многоэтапная непрерывная интеграция — это расширение непрерывной интеграции . Оно предполагает, что вы уже следуете рекомендуемым практикам.
Чем крупнее и/или сложнее проект, тем выше вероятность того, что проект станет нестабильным. Количество предупреждений и сломанных сборок увеличивается по мере роста проекта. Прогресс снижается, и основная линия становится все более нестабильной. Риск сбоя сборки возрастает экспоненциально по мере роста числа и местонахождения разработчиков. [2]
Рекомендуемая практика №1
[ редактировать ]Каждый разработчик работает над своей задачей. По мере внесения изменений выполняется непрерывная интеграция с веткой этой команды. Если это не удается, то этот разработчик (возможно, с помощью своих товарищей по команде) исправляет ветку. Когда возникает проблема, затрагивается только эта команда, а не все усилия по разработке. Это похоже на то, как работает остановка линии на современном бережливом производстве. Если кто-то на линии тянет за шнур «остановить линию», это влияет только на часть линии, а не на всю линию.
Примечательно, что в последние годы модель ветки «тема» или «функции» стала более популярной по сравнению с моделью ветки, основанной на команде. См., например, популярную модель ветвления Git-Flow. [3]
Часто команда решает перейти ко второму этапу: интеграции с основной веткой. На этом этапе команда делает то же самое, что и отдельный человек в случае основной разработки. В ветке команды должны быть объединены все изменения из основной ветки (эквивалент обновления рабочей области), должна быть успешная сборка и все тесты должны быть пройдены. Интеграция с основной веткой будет проще, чем обычно, поскольку в ней будут присутствовать только предварительно интегрированные функции, а не функции, находящиеся в стадии разработки. Затем изменения команды объединяются в основную ветку, что запускает цикл сборки и тестирования в основной ветке. Если это пройдет, команда вернется к первому этапу, где отдельные разработчики работают над своими собственными задачами. В противном случае команда работает над тем, чтобы основная ветка снова заработала, как если бы они были отдельными людьми, работающими над основной веткой.
Изменения распространяются настолько быстро, насколько это возможно, останавливаясь только при возникновении проблемы. В идеале изменения в основную область интеграции попадают так же часто, как и при основной разработке. Разница в том, что меньше проблем доходит до основной зоны интеграции. Многоэтапная непрерывная интеграция позволяет обеспечить высокую степень интеграции параллельно, значительно уменьшая при этом объем интеграционных проблем. [4]
Рекомендуемая практика № 2
[ редактировать ]Для многоэтапной непрерывной интеграции каждая команда должна иметь свой филиал.
Преимущества
[ редактировать ]Многоэтапная непрерывная интеграция имеет множество преимуществ: [ нужна ссылка ]
- Если модульные тесты завершаются неудачей или обнаруживается ошибка, разработчики могут вернуть кодовую базу обратно в состояние, свободное от ошибок, не тратя время на отладку ;
- Проблемы интеграции выявляются и устраняются постоянно — никаких перерывов в последнюю минуту перед датой выпуска;
- Раннее предупреждение о неработающем/несовместимом коде;
- Раннее предупреждение о противоречивых изменениях;
- Немедленное модульное тестирование всех изменений;
- Постоянная доступность «текущей» сборки для тестирования, демонстрации или выпуска;
- Непосредственный эффект от проверки неполного или поврежденного кода служит стимулом для разработчиков учиться работать более поэтапно с более короткими циклами обратной связи.
Инструменты
[ редактировать ]Инструменты, поддерживающие многоэтапную непрерывную интеграцию, включают:
- АккуРев [5] контроля версий и ALM. - Инструмент
- Электрическое облако [5] — Инструмент создания, тестирования и развертывания инфраструктуры, предназначенный для автоматизации жизненного цикла производства программного обеспечения.
- AnthillPro — инструмент сборки, зависимости и выпуска [6]
- Концерт команды Rational [7] АЛМ-Платформа
См. также
[ редактировать ]- Гибкая разработка программного обеспечения
- Автоматизация сборки
- Непрерывный дизайн
- Непрерывная интеграция
- Разработка через тестирование
- Управление жизненным циклом приложений
Ссылки
[ редактировать ]- ^ Многоэтапная непрерывная интеграция, дата доступа 25 февраля 2009 г., Пул, Дэймон, 2 декабря 2008 г., доктор Доббс, опубликовано TechWeb.
- ^ Расширенная многоэтапная интеграция , дата доступа 19 марта 2009 г., Пул, Дэймон, 17 января 2009 г. Мысли о гибкой разработке .
- ^ «Успешная модель ветвления Git» .
- ^ Крупномасштабная непрерывная интеграция , Пул, Дэймон, 19 января 2009 г., CMCrossroads, опубликовано CMC Media. [ постоянная мертвая ссылка ]
- ^ Перейти обратно: а б AccuRev и Electric Cloud сотрудничают для продвижения многоэтапной непрерывной интеграции и передовых методов масштабируемой гибкой разработки , дата доступа: 19 марта 2009 г. Архивировано 20 июля 2008 г. на Wayback Machine.
- ^ Руководство по сборке без боли: командные потоки
- ^ «Джаз.нет» . Джаз.нет .