Ответ 1

Предпосылки:

Я предполагаю, что это помещения, в которых обсуждается решение.

1. В настоящее время номер версии хранится в исходном файле, отслеживаемом git, но вы в порядке, чтобы избавиться от него.
2. Никто не управляет номером версии вручную и не запускает процедуру выпуска, которая включает в себя: (a) увеличение номера версии, (b) сборка из исходного кода и (c) сохранение результата сборки где-либо. Они заботятся CI, и ДОЛЖНЫ оставаться такими.

Решение:

1. Вместо записи в исходный файл и создания нового коммита CI просто помечает конкретный коммит, прошедший проверку CI, а затем передает этот тег в удаленное репо.
2. Сценарий сборки должен прочитать тег текущей фиксации HEAD и использовать его в качестве номера версии для публикации выпуска.
3. При желании вы можете использовать git filter-branch для перезаписи существующей истории git repo, пометить коммиты предыдущих выпусков для согласованности, удалить и прекратить отслеживание исходного файла номера версии, а затем избавиться от этих коммитов CI.

Ответ 2

Распространено хранить номер версии в исходном коде, в этом нет ничего плохого.

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

Обычные сборки: запускаются ежедневно или даже после каждой фиксации, могут включать статический анализ кода и автоматические тесты, проверять, может ли код быть собран вообще. Обычные сборки не должны менять номер версии.

Публикация релиза: может быть вызвана только явным ручным действием менеджера релиза.
Действие триггера может быть помечать коммит новым номером версии, новым слиянием с веткой релиза или просто коммитом, который изменяет номер версии, хранящийся в специальном файле (например, pom.xml). Обратитесь к git flow, например.
Публикация релизов назначает новый номер версии (автоматически или вручную), фиксирует его в исходном коде при необходимости, создает бинарный пакет с новой версией и загружает его в репозиторий бинарных пакетов (например, Nexus, devpi, локальный репозиторий APT, Docker). реестр и тд).

Развертывание релиза: другое инициируемое вручную действие, которое берет готовый двоичный пакет из репозитория пакетов и устанавливает его в целевую среду (dev, QA/UAT/staging, часть производства для канареечных развертываний или во всю производственную среду).

Ответ 3

Я думаю, что вы должны использовать Git Flow. И создайте основную ветвь и развивающую ветвь. Каждый раз, когда CI проверяет разработку, номер версии остается неизменным. Каждый раз, когда вы создаете релиз, например, слияние превращается в мастер, вы можете увеличить номер версии на CI.

Или я что-то упустил, но в моем мнении нет причины увеличивать номер версии при каждом запуске ci.

Так что в целом вам лучше подумать, когда "выпустить" изменения в новой версии !!

Ответ 4

Если проект хранится в git-репо для производственного использования, просто используйте любой вариант git describe плавающий на вашей лодке, нет необходимости хранить его в отслеживаемом файле, потому что результат идентифицирует конкретную историю, и вы сразу же получите эту историю.

Если источник поставляется отдельно, вы можете использовать git archive и атрибут export-subst чтобы встроить практически все, что вы хотите, в экспортированный источник.

Ответ 5

PS: Быть новым пользователем не может добавлять комментарии.

поддержать и расширить этот ответ @VibrantVivek.

Для непрерывной интеграции, мечение дюрантного назад очень важно и будет ли держать вас в коде или просто любым другим мерзавца образом, после каждого успешного CI должен быть соответствующий тег/версии.

И если у вас есть теги/версии CI, которые не противоречат коммитам, то тут действительно что-то не так.

И +1 для Мартина Фаулера, вот еще одна ссылка для более подробной статьи (более или менее того же человека) https://www.thoughtworks.com/continuous-integration (рекомендуем прочитать, пожалуйста)

Ответ 6

На ваш первый вопрос:

Как мы можем избежать "бесполезных" коммитов CI, которые просто увеличивают номер версии?

Пожалуйста, продолжайте интеграцию (CI) - это практика разработки, которая проверяет каждую check-in с помощью автоматической сборки, позволяя командам обнаруживать проблемы на ранних этапах.

Сказав это, хотел бы сформулировать здесь:

• Из практики: каждый коммит должен основываться на машине интеграции

• Как это сделать: сервер CI контролирует хранилище и проверяет изменения, когда они происходят

Проще говоря, CI-сервер должен улучшать версию только и только при наличии нового коммита и, таким образом, обеспечивать, чтобы каждый коммит кода был доступным.

Похоже из OP, что в вашем регионе больше (как вы сказали) "бесполезных" commits с CI server.

Основываясь на вашем механизме CI, я надеюсь, что вы должны/должны быть в состоянии контролировать его, почти есть способы справиться с каждым инструментом, который мы используем. (Например: webhooks в bitbucket, плагин версии и т.д.).

Итак, убедившись, что только после нового коммита у нас есть новая версия.

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

Многие организации выполняют регулярные сборки по расписанию, например, каждую ночь. Это не то же самое, что непрерывная сборка, и ее недостаточно для непрерывной интеграции. Суть непрерывной интеграции заключается в том, чтобы как можно быстрее находить проблемы. Ночные сборки означают, что ошибки лежат незамеченными целый день, прежде чем их обнаружат. Как только они находятся в системе так долго, их поиск и удаление занимает много времени.

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

Несмотря на это, если вы все еще не можете понять, как можно избежать "useless" commits номера версии, я бы предложил добавить еще один вопрос с подробным описанием того, как работает ваш механизм CI и почему это сложно в данных условиях. Бьюсь об заклад, должно быть решение. Также посмотрите на GithubFlowVsGitFlow.

источник: белая книга Мартина Фаулера о КИ

Как избежать сохранения номера версии в исходном коде?

По этому поводу хотелось бы расширить @void ответ, как там сказано:

It is a common practice to keep a version number in the source code, there is nothing wrong in that.

Существуют проекты, которые должны знать точную version развернутую (по некоторым важным причинам xy) в таких сценариях, они сохраняют версию в исходном коде и HTTP GET API для извлечения из развернутого кода (один из способов сделать это), чтобы узнать версию, развернутую в настоящее время в X сервер.

Однако в большей степени это касается требований. Предположим, что для другого проекта такой ситуации нет, тогда рекомендуемый способ сохранить version - использовать хеши /tagging commit каждой успешной сборке CI.

Вы можете получить более подробную информацию здесь:

Надеюсь это поможет.