Построение предыдущего выпуска с использованием исходного Build Pipeline на момент выпуска

Question

Мы следуем модели gitflow в нашем проекте, используя Azure DevOps Services. У меня есть конвейер на основе редактора classi c, который создает ветку Dev и Release / R1.0.

Я собираюсь установить конвейер на основе редактора classi c, который будет собирать мой выпуск R.10 из ветка master после слияния ветки Release / R1.0 в конце выпуска. Допустим, этот конвейер сборки на основе редактора classi c - это MyProduct-R1.0

. После выпуска я буду отмечать основную ветвь и удаляю ветку Release / R1.0 согласно модели GitFlow. Тем не менее, я сохраню конвейер сборки MyProduct-R1.0

Мой вопрос таков: предположим, после выпуска R1.0, как только основная ветвь продвинулась вперед, и я хочу сделать основную ветвь сборки на R1 .0 тег, как мне использовать конвейер MyProduct-R1.0, который использовался для первоначального построения релиза R1.0?

Я знаю, что это, возможно, запутанный вопрос, но я старался изо всех сил, чтобы попробуйте.

Спасибо,

Обновление 2: я думаю, что мой вопрос больше касается спецификации веток для моего конвейера выпуска MyProduct-R1.0. Я не могу дать мастера, так как мастер будет развиваться после выпуска R1.0. Я не могу дать Release / R1.0, так как эта ветка будет удалена после Release согласно модели gitflow. Итак, какие спецификации веток я должен предоставить для моего конвейера?

Answer 1

Использовать сборки YAML. Механизма для этого нет в сборках JSON («редактор classi c»), поскольку сборки JSON имеют версии отдельно от исходного кода.

Answer 2

Я думаю, вот что достигнет того, чего я добиваюсь. После того, как я сделаю свой релиз и помечу его как R1.0, я всегда смогу позже использовать свой конвейер для создания того же исходного кода в основной ветке для R1.0, используя либо его тег, либо коммит.

Обратите внимание, что это показывает, что Dev - моя ветвь по умолчанию для этого конвейера, поскольку это еще не конвейер Release, который я изображаю ниже. Я еще не создал его.

Я что-то упустил?

Answer 3

Как сказал Даниил, YAML - лучший путь. Обрабатывает это изящно, поскольку определение Build соответствует ветке.

В прошлом для GUI сборок, когда я имел дело с дрейфом определения сборки, вместо создания новых определений сборки я использовал условные шаги , привязанные к создаваемой ветви, но может быть больно go возвращать и обновлять \ поддерживать.