Блог

Теги в SVN дешевы. Достаточно ли они дешевы, чтобы позволить нам помечать каждую успешную сборку, которая появляется из нашего CI box (TeamCity, если это имеет какое-либо значение)?

Мой ответ — НЕТ. Это не зависит от SVN, это просто зависит от хорошей практики.

Сборки CI не должны увеличивать номера сборки или версий — это просто проверка работоспособности всего, что создается (эй, это может не запускаться). Нет абсолютно никакого смысла помечать сборку CI.

Редактировать:

наш отдел контроля качества выбирает следующую доступную сборку из окна CI

Ваш отдел контроля качества не должен касаться сборки CI, вместо этого они должны работать со сборками качества выпуска, которые часто имеют больше возможностей для них, чем сборки CI (т. Е. Номера версий были вставлены там, где это уместно, компиляция была выполнена в режиме выпуска вместо отладки и т.д.). Помните, что сборки CI могут компилироваться, но они могут быть кучей мусора, в зависимости от того, что было возвращено в исходный репозиторий.
Похоже, то, что вы называете сборкой CI, следует называть просто сборкой, поскольку это единственная, которую вы делаете. Собрать хороший набор сборок — это небольшая работа, но она того стоит, существует ряд руководств и технических документов по этому поводу, потратьте некоторое время и ознакомьтесь с этим, а затем давайте пощечину вашему отделу контроля качества каждый раз, когда они произносят слова «Сборка на CI» (поскольку эти сборки должны быть только для использования разработчиками).

Дальнейшее редактирование:

несколько человек прокомментировали «почему сборка CI не может соответствовать качеству выпуска?». Я постараюсь ответить на это кратко, не превращая это в обсуждение, неподходящее для SO. Позвольте мне сначала сказать, что, конечно, сборка CI может быть качественной для выпуска. Если вы сможете добиться этого, то у вас будет больше возможностей, наградите себя медалью. Если вы относитесь к этой категории, то я бы предположил, что вы в небольшой команде с медленно меняющейся кодовой базой.

Цитирую Википедию:

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

И процитируем Мартина Фаулера:

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

Ни в одном из них не говорится, что сборка CI не должна соответствовать качеству релиза. Но ни один из них не говорит, что это должно быть.

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

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

_{Я надеюсь, это объясняет мой комментарий о том, что команды контроля качества не работают со сборками CI. Любое дальнейшее обсуждение действительно должно проходить на programmers.stackexchange.com или в другом месте.}

Поскольку Subversion, по сути, имеет встроенный тег в глобальном номере редакции для каждого коммита, в этом нет необходимости.

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