Повторное Выполнение Заданий Bamboo При Фиксации

Представьте себе следующую настройку: план сборки имеет набор заданий (J), каждое из которых строит модуль (M). Там же находится последняя успешная сборка для всех из них. (ВХ)

J1->M1->BM1-X
J2->M2->BM2-Y
J3->M3->BM3-Z

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

Теперь представьте, что изменения произошли только в одном из репозиториев, скажем, в M1. Мы знаем, что Bamboo выполняет задания параллельно.

• Вопросы:
• будет ли Bamboo полностью перезапускать сборки J2 и J3, даже если обнаружит, что в репозиториях M2 и M3 нет изменений?

Если да (я так думаю, судя по тестовой настройке, но не уверен), какова цель этого? (по крайней мере, с точки зрения логики Bamboo)

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

Хорошее эмпирическое правило — иметь один репозиторий кода, связанный с одним планом сборки, который создает один независимый модуль.

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

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

Именно здесь вы захотите использовать дополнительные возможности оркестрации вашего инструмента CI.

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

Проверьте код -> Сборка/компиляция/юнит-тест -> Развертывание в среде CI -> Поднимите полдюжины браузеров и убедитесь, что все они по-прежнему работают правильно.

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

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

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

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