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

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

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

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

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

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

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

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

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

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

Module dependency chart

Теперь я доволен модулем 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), вам не нужно ничего менять в своем конвейере.

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

Ответ 2

Как вы делаете линию?:

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

Я планировал делать извлечения и публикации. Есть ли лучший способ?