Безопасно ли использовать инкрементную перестройку для генерации сборки релиза в Visual C ++?

Question

У меня иногда возникают проблемы с добавочной перестройкой на Visual C ++ (в настоящее время 2003). Некоторые зависимости, кажется, не проверены правильно, а некоторые файлы не создаются, когда они должны. Я полагаю, что эти проблемы возникают из-за временного подхода к постепенному перестроению.

Я не считаю это большой проблемой при сборке отладочной сборки на моем столе, однако для распространяемой сборки это проблема.

Безопасно ли использовать инкрементную сборку для сервера сборки или требуется полная сборка?

Answer 1

Я бы сказал, что вам следует избегать вопроса «это безопасно». Это просто не стоит изучать.

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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