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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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