Непрерывная интеграция против ночных построек

Чтение этого сообщения оставило меня интересным; ночные построения всегда лучше для ситуации, чем непрерывная интеграция? Консенсус ответов кажется довольно однобоким в пользу непрерывной интеграции, является ли это евангелизмом или нет причин для использования ночных сборок, когда непрерывная интеграция является вариантом?

Ответы

Ответ 1

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

С другой стороны, если ваш режим CI включает только запуск подмножества всех доступных тестов, например, потому что некоторые из ваших тестов занимают много времени, и вы можете использовать ночные часы дополнительно для запуска allсильные > тесты. Это позволит вам поймать множество ошибок на раннем этапе, и если вы не сможете их поймать рано, вы можете хотя бы поймать их на ночь.

Я не знаю, хотя, если это технически все еще CI, поскольку вы делаете только "частичную" сборку каждый раз, игнорируя некоторые из тестов.

Ответ 2

В нашей организации ночные сборки и сборки CI имеют две разные цели. CI build - это сборка "последнего кода", в которой модульные тесты запускаются против последней проверки, как и следовало ожидать. Мы также запускаем несколько кодовых метрик в сборке CI.

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

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

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

Ответ 3

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

  • Для этого требуется много ресурсов, которые могут быть недоступны.
  • Время выполнения занимает 4 часа.

Ответ 4

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

Например, если процесс сборки занимает 5 часов, то на самом деле нет причин делать сборку при регистрации.

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

Ответ 5

Если у вас есть хороший надежный процесс CI, "ночной" все еще полезно.

  • Как уже упоминалось, "ночная" сборка может выполнять исчерпывающие тесты и, возможно, некоторые высокоуровневые системные тесты. В конце концов.
  • Концепция "ночной" сборки легко понятна всем в организации. Если у вас возникли проблемы с передачей CI для других групп (например, группа QA, которая не имеет того же дескриптора Agile, что и группа Dev), "ночная" - это мощная и простая концепция.
  • Если ваш ночной ресурс представляет собой отдельный набор ресурсов, его можно управлять отдельно и использовать для резки "золотых" изображений с некоторыми претензиями на целостность программного обеспечения. Например, разработчик пишет код, некоторую доверенную систему сборки, которую разработчик не может трогать, строит ее, QA тестирует сборку золота и подписывает ее. В такой ситуации ночная сборка функционирует как система создания производства.

Просто мысли.

Ответ 6

Это зависит от цели и длины каждой вашей сборки. В принципе, вы должны определить, что вы пытаетесь извлечь из CI, и решить, стоит ли тратить ресурсы на выполнение нескольких сборок.

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

Сначала мы использовали его, чтобы убедиться, что в репозитории и, следовательно, у разработчиков всегда была версия скомпилированного кода. Немногие вещи хуже для членов команды, чем для того, чтобы управлять другим человеком, нарушенным изменениями, путем комментирования, раскола, возврата и слияния, поскольку один человек проверял код ошибки. Для этого у нас была сборка, которая выполнялась мгновенно без тестов или другой проверки, поэтому мы знали как можно скорее, если код был безопасен для обновления. Построения обычно занимали около десяти минут, и машина, вероятно, работала около 50% в обычный рабочий день. Никакая документация не была создана здесь, просто тихий проход или громкая сирена.

Во-вторых, мы хотели как можно скорее узнать, были ли нарушены какие-либо правила. Чем быстрее вы обнаружите нарушение правила, тем легче его исправить. Для этой цели у нас была отдельная машина, на которой была выполнена полная сборка и проверка кода. Эта машина работала 12-14 часов в день непрерывно в обычный рабочий день. Был отправлен статус электронной почты сборки, описывающий неработающие модульные тесты, соответствие кода и т.д.

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

Ответ 7

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

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

Ответ 8

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

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

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

Я думаю, что одним из основных отличий для ночной сборки являются системные тесты.