Насколько важно оперативно исправлять ночную сборку?

Question

У нас есть автоматизированный сервер сборки, который собирает наш код каждую ночь, что для нас полезно, поскольку не каждый в нашей команде может построить все дерево исходного кода.В последнее время некоторые члены команды стали более небрежно относиться к быстрому исправлению ошибок сборки;иногда недели проходят без успешной сборки.Я даже услышал, как один разработчик сказал: «Сборка уже сломана, сейчас самое время добавить [некоторые нарушительные изменения]». Поскольку я работаю над кодом самым дальним вниз по течению, я обычно работаю с частями дерева, которые крайне не синхронизированы с хранилищем исходного кода, что затрудняет тестирование изменений перед тем, как я их отправляю.

Мне кажется, что мы теряем большую часть преимуществ ночной сборки, поскольку она постоянно ломается.Я далеко от истины, или исправление сборки должно быть более приоритетным?

Answer 1

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

Answer 2

Этих разработчиков явно нужно вернуть в форму.

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

Каждый должен взять на себя ответственность за кодовую базу.

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

Answer 3

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

Answer 4

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

Наш стандарт заключается в том, чтобы все модульные и функциональные тесты запускались «зелеными» на нейтральном блоке интеграции после фиксации.Конечно, разработка через тестирование подходит для нашей ситуации, но может не подойти для вашей.Если вы даже не можете создать проект, возможно, в предыдущих коммитах скрываются неприятные сюрпризы.

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

Answer 5

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

Если команда недостаточно мотивирована, чтобы продолжать наращивать ночные сборы, то менеджеры должны обеспечивать соблюдение/поощрять это.