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

Question

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

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

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

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

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

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

Вот что я пытаюсь решить:

Как проmote интеграционные сборки

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

Теперь я доволен модулем 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, найду и заменим и т.д.черви, я хотел бы получить некоторые мнения.Какой лучший способ справиться с этим?

Answer 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,
• сборка a,
• опубликовать a как integration,
• развертывание a в среде System Test,
• запустить несколько системных тестов
• повышать a с integration до milestone (что продвигает его зависимости)
• развертывание a в среде приемочных испытаний,
• выполнить некоторые приемочные испытания
• повышать a с milestone до release (что продвигает его зависимости)
• развернуть a в производство (или загрузить его на сайт загрузки)

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

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

Answer 2

Как вы справляетесь?:

• продвигать от этапа к выпуску (что продвигает его зависимости)

Я планировал выполнить извлечение и публикацию,Есть ли лучший способ?