Продвижение нескольких модулей (интеграция → веха) в плющом

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

К сожалению, я не нашел окончательного руководства по управлению циклом dev → test → deploy. Вот некоторые вещи, которые я хочу достичь:

(Учитывая, что разработчики обычно работают во многих модулях в локальной рабочей области)

Dev может локально публиковать изменения в модуле, чтобы другие модули в рабочей области могли получать обновленные артефакты.
Dev может назначить версию "готов к развертыванию для тестирования" с помощью одной команды.
Тестер может обозначить версию как "готовую для prod" с помощью одной команды.
Dev может перестроить любую версию из источника, и соответствующие зависимости будут правильно подобраны (например, повторяющиеся сборки).

Некоторые вещи, о которых я довольно ясно представляю, следующие:

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

Вот что я боюсь:

Как продвигать интеграционные сборки

Скажем, что эти модули проверены в моей рабочей области:

Теперь я доволен модулем a и решил опубликовать веху с использованием проверенных версий в моей рабочей области. Что должно произойти в репо:

e-1.0-RC1 публикуется
d-1.1-RC2 публикуется, ссылаясь на e-1.0-RC1 как зависимость
c-2.0-RC1 публикуется, ссылаясь на d-1.1-RC2 как зависимость
b-3.3-RC1 публикуется, ссылаясь на e-1.0-RC1 как зависимость
Наконец, a-7.1-RC2 публикуется, ссылаясь на c-2.0-RC1 и b-3.3-RC1 как зависимости.

Если я попытаюсь сделать это самостоятельно, я бы, вероятно, в конечном итоге выполнил какое-то управление рабочим пространством, найду и заменил ivy.xml и т.д. Прежде чем открыть эту возможность червей, я хотел бы получить некоторые мнения. Какой лучший способ справиться с этим?

Ответ 1

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

Используя ваш пример:

e-1.0-RC1 публикуется со статусом integration
d-1.1-RC2 публикуется со статусом integration, ссылаясь на e-1.0-RC1 как зависимость
c-2.0-RC1 публикуется со статусом integration, ссылаясь на d-1.1-RC2 как зависимость
b-3.3-RC1 публикуется со статусом integration, ссылаясь на e-1.0-RC1 как зависимость
a-7.1-RC2 публикуется со статусом integration, ссылаясь на c-2.0-RC1 и b-3.3-RC1 в качестве зависимостей.
Наконец, вы решили продвигать a-7.1-RC2 в статус milestone, поэтому вы делаете отказоустойчивую доставку (использовать атрибут delivertarget). Это будет рекурсивно вызывать delivertarget для каждой зависимости, которая имеет статус ниже milestone и опубликовать ее с статусом milestone.

Самое приятное в этом - это то, что вам не нужно (или не хотеть), чтобы каждый проект проверял в вашей рабочей области, просто a. Это также означает, что гораздо проще создать конвейер развертывания и иметь ваш сервер CI:

запустите модульные тесты для a,
build a,
опубликуйте a как integration,
развернуть a в среду тестирования системы,
выполните некоторые системные тесты
продвигать a от integration до milestone (что способствует его зависимостям)
развернуть a в среду тестирования приемочных испытаний,
выполнить некоторые тесты приёма
продвигать a от milestone до release (что способствует его зависимостям)
развернуть a для производства (или загрузить его на сайт загрузки)

Ни разу конвейеру не нужно обращаться к зависимым проектам, и поскольку рекурсивная доставка является общей, когда вы добавляете или удаляете зависимости (через ваши файлы ivy.xml), вам не нужно ничего менять в своем конвейере.

Я отметил этот ответ как вики сообщества. Кто-нибудь еще хочет расширять его или исправлять все, что у меня получилось?

Как продвигать интеграционные сборки

Ответ 1

Ответ 2