Стратегия по маркировке в управлении источником из систем непрерывной интеграции

Question

Это вопрос о том, как мы должны использовать тегирование из системы непрерывной интеграции.

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

Результат сборки может быть один из следующих: * встроенные системы безотказную (не хватает дискового пространства на машине построения или аналогичный) * встроенный отказ * тест-провал * успех

Теперь большой вопрос в том, было бы хорошей идеей или не хранить эту информацию внутри SCM (обычно git или mercurial).

Использование тегов, чтобы отметить это, кажется, как хорошая идея, позволяя вам делать такие вещи, как:

1. записи тег build=1234 по пересмотру
2. двигаться тег last-success к текущей сборке, если это успех
3. переместить метку last-build до последней сборки (который не прошел испытания)
4. добавить тег build_url=http://buildsystem.example.com/job/1234
5. может быть другими изменениями?

Теперь мне также интересно, как спамить историю SCM с помощью обновлений тегов из системы сборки.

Это правильный подход? - У меня все еще есть некоторые проблемы, связанные с размещением слишком большого количества информации в SCM и наличием слишком большого количества уведомлений по электронной почте в качестве побочного эффекта.

Answer 1

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

1. Решение, которое вы упомянули - отметьте код в SCM с номером сборки (с указанием меток - это очевидный способ сделать это)
2. Противоположность - сохранить номер версии из SCM внутри пакета, созданного вашей сборкой (например, сборка выплевывает небольшой текстовый файл, содержащий номер ревизии SCM, который входит в пакет).

Я бы сказал, что оба этих решения работают достаточно хорошо, и лучший из них зависит от того, как вы собираетесь использовать эту информацию. Например, если ваша мотивация такова, что при отладке проблемы в производственной системе вы можете легко проверить соответствующий исходный код для этой версии программного обеспечения, тогда подход (2) хорошо работает, так как легко просмотреть номер версии SCM на вашей производственной системе и проверить код для этой ревизии. Однако у вас также есть ряд веских причин для выбора варианта (1), указанного в вашем вопросе, поэтому я бы пошел на это.

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

Претензии к тому, чтобы ваши сборки были прослежены до исходного кода!