Мы небольшая фирма с несколькими командами, которые управляют своими собственными git-репозиториями. Это веб-платформа, и артефакты каждой команды используются в конце дня для ночных тестов. Мы пытаемся формализовать процесс создания версий и упаковки.
У каждой команды есть мастер ветвь, где они занимаются повседневной разработкой. Члены группы обеспечения качества хотят, чтобы артефакты от изменений их команды были развернуты на испытательном стенде, где все компоненты объединяются шеф-поваром. Артефакты - это архивы, но я бы хотел преобразовать их в RPM, чтобы мы могли правильно продумать и продумать версии.
Процесс выпуска включает в себя отключение ветви выпуска от ветви разработки (в большинстве случаев master) каждого репозитория git. Это затем дается гарантии качества, которые проводят тесты и подписывают набор артефактов.
Например, это типичный git-репозиторий со связанными ветками релиза:
0-0-0-0-0-0-0-0-0-0 (master)
| |
0 0
(rel-1) |
0
(rel-2)
Я застрял, пытаясь выяснить схему выполнения версий пакетов из веток разработки. Мы не хотим чрезмерно маркировать основную ветвь каждого репо и ограничивать теги только выпусками ветвей. Но мы должны иметь возможность запрашивать развернутые пакеты на тестовых машинах, используя стандартную семантику yum / rpm. Как будут выглядеть версии для разработки, если в основной ветке нет тегов? Я понимаю, что это git describeможет дать мне полезное представление о версии сборки, но это хорошо работает, когда отмечены различные точки выпуска в ветви.
РЕДАКТИРОВАТЬ1: В ответ на ответ @ Urban48
Я подумал, что должен объяснить наш процесс выпуска немного подробнее. Для целей этого обсуждения давайте предположим, что у нас есть ветка masterво всех репозиториях. masterОтрасль считается веткой разработки и развертыванием на автоматизированный CI-CD включена среда QA. Именно здесь выполняется подмножество ночных тестов для обеспечения стабильности мастера. Мы смотрим на этот список работ, прежде чем вырезать ветку релиза. Наши ветки выпуска недолговечны. Скажем, после вырезания ветки выпуска (из стабильного мастера) выполняется полная регрессия, исправления вносятся и внедряются в производство. Это займет около недели, чтобы сделать. Мы выпускаем почти каждые две недели для производства.
Наши ветви функций всегда вырезаны из master и проходят определенное тестирование разработчиками перед слиянием с master, после чего они проходят проверку стабильности CI-CD.
Исправления производятся в ветвях исправлений (вырезанных из веток релиза) и внедряются с минимальным влиянием тестирования в производство.
Наша стратегия управления версиями для веток релиза и исправления следует принципам semver. Отпустить ветви во ходе цикла QA через версии , как v2.0.0-rc1, v2.0.0-rc2и , наконец , после QA знака-офф стала v2.0.0.
Мы иногда делаем точечные выпуски для небольших функций, которые объединяются, чтобы выпустить ветки (а затем освоить), где становятся версии v2.1.0. И исправления предполагают v2.1.1шаблон.
Вопрос, однако, не в версии этих веток. Я бы предпочел не менять эту схему управления версиями вообще. Единственное изменение происходит для развития отрасли, т.е. мастер. Как я могу надежно указать в среде CI-CD, какая версия существует по сравнению с предыдущим выпуском в производство. В идеале это можно сделать с помощью смарт-тегов git, но предпочтение отдается тому, что не чрезмерно помечает главную ветвь.
rcсуффиксу? Это будет диктовать major.minorверсию для разработки. rcи номер сборки может быть получен только на основании этого. Также rcна мастере нет смысла, потому что мы никогда не отпускаем от мастера. Мы помечаем наших кандидатов на выпуск сегодня в ветвях релиза как часть цикла
rcсуффикс.
