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

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

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

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

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

Вот некоторые вещи, о которых я совершенно ясно:

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

Вот с чем я борюсь:

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

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

Таблица зависимостей модулей

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

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


deployment version-control ivy ant
person oksayt    schedule 23.06.2011    source источник

Ответы (2)


arrow_upward
5
arrow_downward

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

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

  • 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) вам не нужно ничего менять в вашем конвейере.

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

person Community    schedule 08.09.2011

arrow_upward
0
arrow_downward

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

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

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

person Erock 634    schedule 19.09.2013