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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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