Насколько важно быстрое исправление ночной сборки?

Question

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

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

Answer 1

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

Answer 2

Очевидно, что этих разработчиков нужно вернуть в форму.

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

Каждый должен стать владельцем кодовой базы и взять на себя ответственность.

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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