Выпуск сборки против ночной сборки

Типичное решение состоит в том, чтобы на сервере сборки работала сборка CI (Continuous Integration): она будет анализировать исходный код, делать сборку (при отладке) и запускать тесты, измерять охват тестов и т. Д.

Теперь другой тип сборки, обычно известный как «Ночная сборка»: выполняйте медленные вещи, такие как создание документов кода, создание пакета установки, развертывание в тестовой среде, запуск автоматических тестов (тестирование или приемка) в тестовой среде и т. Д.

Теперь вопрос:

• Лучше ли иметь третью отдельную «сборку релиза» в качестве сборки релиза?
• Или сделать «Ночную сборку» в режиме релиза и использовать его как релиз?

Что вы используете в своей компании?

(Сборка релиза также должна добавить какой-то тег для контроля версий потенциальной версии продукта.)

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

Разница между релизом и ночной сборкой:

• ночная сборка запускается автоматически, ну, каждую ночь, тогда как сборка релиза должна выполняться вручную в определенные моменты времени
• Релиз build должен в идеале пометить / разветвить исходный код и, возможно, развернуть артефакт (ы) сборки в центральном репозитории (например, при использовании Maven)

Эти различия на практике представляют собой несколько дополнительных опций в большинстве систем управления сборкой, которые я знаю. Чтобы свести к минимуму вероятность человеческих ошибок, их можно сохранить, например, в пакетном файле / файле сценария, который принимает только необходимые параметры (и проверяет их).

Ну, я бы хотел, чтобы сборка релиза была максимально приближена к ночной! В идеале точно так же, но с тегом.

Дело в том, что если ваш релиз и ночная сборка не совпадают, есть вероятность, что все, что отличается, может замаскировать проблему (или сделать отслеживание одного гораздо сложнее).

У меня был бы один процесс сборки, который бы собирал все при каждой регистрации, выполняемой службой CI. Это будет как отладочная, так и выпускная сборки.

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

Одна вещь, которую я хотел бы сделать, это переключить ночную сборку в режим выпуска, а не в режим отладки. В случае каркасов журналирования, таких как log4net, заменяющих System.Diagnostics.Debug, основными различиями между режимами Release и Debug являются время жизни объектов и оптимизация кода.

Если вы на самом деле не собираетесь подключать отладчик к вашей ночной сборке, я бы посоветовал сделать это тоже.

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