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

Question

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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