Непрерывная интеграция против ночных сборок - PullRequest
14 голосов
/ 06 января 2009

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

Ответы [ 8 ]

17 голосов
/ 06 января 2009

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

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

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

10 голосов
/ 06 января 2009

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

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

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

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

5 голосов
/ 06 января 2009

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

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

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

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

Просто некоторые мысли.

3 голосов
/ 06 января 2009

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

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

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

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

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

3 голосов
/ 06 января 2009

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

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

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

2 голосов
/ 27 августа 2009

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

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

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

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

2 голосов
/ 07 января 2009

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

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

...