Войти
В разработке программного обеспечения нейтральная сборка - это сборка программного обеспечения, который отражает текущее состояние исходного кода, проверенного разработчиками в системе управления версиями исходного кода и выполненного в нейтральной среде (среда, не используемая для разработки).
A ночная сборка - нейтральная сборка, которая выполняется автоматически. Обычно это происходит, когда никто не будет работать в офисе, поэтому во время сборки не было изменений в исходном коде. Результаты сборки проверяются прибывающими программистами, которые обычно уделяют первоочередное внимание тому, чтобы последние изменения исходного кода не нарушили процесс сборки или функциональность программного обеспечения. Ночные сборки также гарантируют, что инструменты сборки не сломались из-за обновлений системы, и поэтому часто запускаются независимо от того, изменился ли исходный код или нет.
Напротив, среды непрерывной интеграции автоматически перестраивают проект всякий раз, когда вносятся изменения - часто несколько раз в день - и обеспечивают более немедленную обратную связь; однако они не обязательно включают ночные сборки. В результате обновления компилятора и инструментов могут нарушить способность легко компилировать старые проекты без предупреждения. Тем не менее, методы CI считаются более современным подходом. Задания CI часто выполняются на изолированных виртуальных машинах и обычно включают автоматическое тестирование.
Когда кто-то говорит, что разработчик «сломал сборку», они фактически говорят, что разработчик проверил код, который вполне мог быть скомпилирован (и, надеюсь, также правильно) в их учетной записи, но не компилируется (и следовательно, не может быть запущен) в чужой учетной записи. Обычно это происходит из-за дополнительных специфических для разработчика изменений, которые либо не были зарегистрированы, либо (в случае переменных среды и т. Д.) Были модификациями систем, не находящихся под контролем версий. Один из наиболее распространенных случаев - это не забыть вернуть все измененные файлы, но забыть добавить вновь созданные файлы в репозиторий. Если другие разработчики проверяют новый код, не зная о проблеме, их работа может остановиться, пока они ждут, пока проблема не будет исправлена (или попытаются исправить ее самостоятельно, что может быть еще более проблематичным, если несколько разработчиков попытаться исправить проблему одновременно). Это, естественно, может привести к значительной потере производительности.
Нейтральные сборки важны для разработки программного обеспечения процессов, работающих при высоких нагрузках с короткими расписаниями (см. экстремальное программирование, запуск ). Их отсутствие означает, что любая сборка, которую необходимо создать для отдела обеспечения качества программного обеспечения, будет использовать код, который может находиться в процессе основных модификаций, и поэтому его лучше не включать в сборку, предназначенную для независимых проверка - особенно сборка, оцениваемая на предмет возможного выпуска.
Некоторые препятствия для надежного нейтрального процесса сборки:
В следующем списке приведены некоторые примеры программного обеспечения, которое общедоступно в ночное время и / или или нейтральные сборки.
