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