Мой ответ - НЕТ.Это не специфично для SVN, это просто хорошая практика.
сборки CI не должны увеличивать номера сборки или версии - они просто проверяют, что все сборки (эй, это можетне запустить хотя).Нет абсолютно никакого смысла маркировать сборку CI.
Редактировать:
наш отдел контроля качества выбирает следующую доступную сборку из поля CI
Ваш отдел QA не должен касаться сборки CI, вместо этого он должен работать с выпуском качественных сборок, которые часто с ними делают больше, чем сборки CI (т.е. номера версий были вставленыгде это уместно, компиляция выполнялась в режиме Release вместо Debug и т. д.).Помните, что сборки CI могут компилироваться, но они могут представлять собой кучу мусора, в зависимости от того, что было зарегистрировано в исходном хранилище.
Звучит так, что вы называете CI build , простоназовитесь сборкой , так как это единственное, что вы делаете.Собрать хороший набор сборок - это немного работы, но это того стоит. Есть множество уроков и технических документов по этому поводу, потратьте некоторое время и прочитайте об этом, а затем предоставьте свой отдел контроля качества.каждый раз, когда они произносят слова "CI build" (так как эти сборки должны использоваться только для разработчиков).
Дальнейшее редактирование:
пара человек прокомментировала "почему сборка CI не может быть качественной версией релиза?" .Я постараюсь ответить на это кратко, не превращая это в дискуссию, непригодную для SO.Прежде всего позвольте мне сказать, что, конечно, сборка CI может быть качественным релизом.Если ты сможешь достичь этого, тогда получи больше сил, награди себя медалью.Если вы находитесь в этой категории, то я думаю, что вы в маленькой команде с медленно меняющейся кодовой базой.
Цитировать Википедия :
Обычная практика - запускать эти сборки при каждой фиксации в репозитории, а не при периодической сборке.Практичность выполнения этого в среде быстрых фиксаций для нескольких разработчиков такова, что обычно запускают короткий таймер после каждой фиксации, а затем запускают сборку, когда истекает этот таймер, или по истечении более длительного интервала с момента последней сборки.
И процитировать Мартин Фаулер :
Непрерывная интеграция - это практика разработки программного обеспечения, при которой члены команды интегрируют своиработать часто, как правило, каждый человек интегрируется по крайней мере ежедневно - что приводит к нескольким интеграциям в день.Каждая интеграция проверяется автоматизированной сборкой (включая тестирование) для максимально быстрого выявления ошибок интеграции.
Ни один из них не говорит, что сборка CI не должна качество выпуска. Но ни один из них не говорит, что так и должно быть.
При работе в команде разумного размера, работающей с одной и той же ветвью, быстро становится непрактичным достигать качества выпуска с каждым КИстроить.Сборки CI всегда начинаются через небольшой промежуток времени после регистрации, нет никакой гарантии, что участник команды действительно завершил регистрацию или что кто-то еще не запустился, когда этот таймер останавливается и сборка начинается.
Еще одна мысль, которую следует иметь в виду, заключается в том, что при работе в более крупной команде обычной практикой является создание CI-сборок в ветви разработки, в то время как качественные сборки Release / QA выполняются из ветки Release или QA.Это позволяет команде разработчиков продолжать реализацию функций, не загрязняя сборки, которые будет тестировать QA - когда функции завершены, они объединяются с веткой, из которой команда QA берет свои сборки.
Я надеюсь, что это объясняет мой комментарий о командах QA, не работающих со сборками CI.Любое дальнейшее обсуждение должно проводиться на programmers.stackexchange.com или где-либо еще.