Блог

Название не самое лучшее, я согласен, пожалуйста, прочитайте подробнее, чтобы понять, что я имею в виду…

У меня есть проект/репозиторий, который имеет следующие свойства:

• Сообщения о фиксации следуют за обычными фиксациями
• Результат вышесказанного: в репозитории нет ни одного места с номером версии. Версии рассчитываются автоматически на основе истории фиксаций.
• История прошлых «релизов» — это в основном история тегов git (когда выпуск завершен и 1.2.3 появляется версия, помечается соответствующая фиксация).
• CI «прост»/интегрирован с Github, каждое слияние/нажатие для управления запускает полный конвейер, включая deploy / release часть (который создает новую версию, нажимает тег, короче говоря, «выпускает»)
• У меня нет способов (или, я думаю, что у меня нет способов, или я не хочу) вручную активировать CI для освобождения от самого CI. Каждый триггер должен исходить из git/github.

Хотя в целом это работает довольно хорошо, моя проблема в том, что обычно репо является постоянным и не получает реальных новых коммитов, однако в некоторые активные дни у меня может быть 2-3-4-10 новых запросов на объединение.

При текущем подходе 10 объединенных запросов на вытягивание приведут к 10 выпускам с 10 увеличениями версий. Но я бы предпочел сначала объединить все 10, а затем сделать один релиз и увеличить одну версию.

Любой совет, как я могу этого добиться, какова была бы современная рекомендация здесь?

Одна из моих мыслей состояла в том, чтобы иметь какую pre-release -либо develop ветвь или, где я могу сначала объединить PRS, и только когда придет время выпускать, слиться develop master . Но это выглядит немного громоздко и на самом деле не облегчает жизнь участникам (им нужно ориентироваться на разработку, затем мне нужно создать PR от разработки до освоения и т. Д.)

Обновить:

• Я считаю, что ответ должен быть независимым от CI. Неважно, какая именно система CI находится здесь, важно то, что я не хочу идти в CI для запуска заданий, все взаимодействия должны происходить через репозиторий. Веб-крючки/соединение между репо и CI, конечно, доступно и работает.
• Конечно, сказав «простой» CI, я не имел в виду, что его конфигурация исправлена. Конечно, я могу обновить его любым способом, каким захочу, никаких проблем с этим (запускайте разные события из репозитория, в разных ветвях и т. Д.)

Существует множество способов достичь того, чего вы хотите.

Одна идея, о которой вы уже сами упоминали:

Одна из моих мыслей состояла в том, чтобы создать какую-нибудь ветвь подготовки к выпуску или разработке, в которой я мог бы сначала объединить PR, и только когда придет время выпускать, объединить разработку для освоения.

Это подход, который, безусловно, требует наименьших усилий. Все остальное потребует от вас изменения конвейера. Если вас это устраивает, вот несколько идей, которые нетрудно реализовать, учитывая вашу нынешнюю структуру:

• Измените конвейер так, чтобы он выпускался не при каждом изменении в master ветке, а при каждом изменении в release ветке. Таким образом, все разработчики по-прежнему смогут ориентироваться master , и вы сможете затем раздавить все коммиты и представить их release . Этот подход прост, но в зависимости от проекта может привести к проблемам и/или путанице в отношении структуры git.
• Измените конвейер так, чтобы он не выпускался при каждом изменении в master ветви, а при каждом новом перемещаемом теге. Таким образом, вы можете собрать все коммиты в master ветке, и как только вы решите, что она готова к выпуску, просто нажмите тег git вручную. Если вы хотите сделать еще один шаг вперед, настройте конвейер таким образом, чтобы он автоматически создавал тег git только в том случае, если вы (или другие доверенные лица) подписали сообщение о фиксации, содержащее что-то вроде version bump to vX.Y.Z . Этот подход является более современным и обеспечивает гораздо большую гибкость, но требует большего количества изменений в конвейере, чем предыдущий (имейте в виду, что изменение конвейера-это одноразовое усилие).