Частые построения
В идеале, следует строить приложение один раз в день. Конечно, размеры некоторых проектов настолько велики, что ежедневные построения не оставляют достаточно времени для его полного тестирования. Для таких больших и сложных проектов необходимо разработать схему, по которой построения будут выполняться так часто, как это возможно.
При построении продукта следует строить как отладочную, так и выпускную версии одновременно. Как будет показано позже в этой главе, отладочные построения имеют решающее значение. Прерывание процесса построения нужно трактовать как ошибку. Если разработчики регистрируют код, который не откомпилирован, они должны заплатить некоторый вид штрафа за право ошибиться, например, в форме доставки пончиков и публичного признания в преступлении. Если в команде нет специального инженера, ответственного за построение версии продукта, то можно наказать виновника, сделав его ответственным за процедуры построения, пока не придет черед следующего нарушителя.
Наилучшей практикой для ежедневных построений можно считать уведомление команды через электронную почту об окончании этого процесса. С учетом того, что построение автоматически происходит по ночам, первое сообщение, которое каждый член команды может отыскать утром, — это указание на то, потерпел ли этот процесс неудачу; если это так, то команда может предпринимать немедленные действия, чтобы исправить ситуацию.
Чтобы избежать проблем с построением продукта, каждый член команды должен иметь одни и те же версии всех инструментов и частей системы построения. Как я упомянул ранее, чтобы усилить эту практику, некоторые команды любят хранить систему построения в подсистеме управления версией. Если у членов команды работают различные версии инструментов, включая уровни пакетов обслуживания, то вы получите море ошибок в построенном продукте. Если нет веской причины, чтобы кто-то использовал иную версию компилятора, никакой разработчик не должен выполнять его модернизацию (upgrade) самовольно.
Ваша система построения продукта будет извлекать самые последние главные исходные файлы (master sources) из системы управления версией каждый раз, когда будет выполняться процесс построения (в идеале, разработчики должны также получать эти данные каждый день).
Нет ничего хуже, чем проводить время, пытаясь решить неприятную проблему только для того, чтобы выяснить, что она связана со старшей версией файла на машине разработчика. Другое преимущество частого получения исходных данных разработчиками состоит в том, что оно позволяет осуществлять непрерывное построение. Благодаря частому извлечению, любая проблема с главным построением (master build) продукта автоматически становится проблемой для локального построения (local build) каждого разработчика. Когда прерываются ежедневные построения, то раздражаются менеджеры, а разработчики не любят, когда прерывается их локальное построение. Зная, что прерывание главного построения означает прерывание построения всех индивидуальных разработчиков, каждый вынужден ограничиться чистым кодом в главном источнике.
Общий вопрос отладки
Когда следует заморозить модернизацию (upgrade) компилятора и других инструментов?
Как только завершена разработка ведущих свойств продукта (что также известно как разработка версии beta 1), вы определенно не должны модернизировать никакие инструменты. Изменяя код, нельзя позволить себе риск новой схемы оптимизации компилятора, независимо от того, насколько хорошо она обдумана. Ко времени, когда получена версия beta 1, уже выполнено некоторое существенное тестирование, и в случае изменения инструментов вы будете вынуждены повторно начать тестирование — с нуля.
