Потому что, если другие люди проверит ваши неработающие изменения, они не смогут работать, а если и сделают, то будут делать это менее эффективно.
Это также означает, что вы неправильно тестируете свои изменения перед фиксацией, что является ключевым моментом в CI.
От Мартина Фаулера http://martinfowler.com/articles/continuousIntegration.html
Весь смысл работы с CI заключается в том. что вы всегда разрабатываете на известной стабильной базе. Нет ничего плохого в том. если основная сборка сломается, хотя если это происходит постоянно постоянно, это говорит о том, что люди недостаточно достаточно осторожны в обновлении и локальной сборки перед коммитом. Когда основная сборка все же ломается, однако, важно, чтобы это было быстро исправили.
Будьте очень осторожны, называя «нарушение сборки» плохим. Это то, что требует немедленного внимания, но это также вполне нормальная и ожидаемая часть цикла разработки. Вот почему непрерывная интеграция так полезна - она сразу сообщает вам, когда сборка сломана, и какой набор изменений вызвал это. Это поможет вам быстро вернуться на правильный путь.
Если ваша культура наказывает «нарушение построения», то вы рискуете создать токсичную рабочую среду. Опять же, считайте это чем-то, что требует немедленного внимания, но не называйте это «плохим».
Потому что, если другие люди проверят изменения, они не смогут работать... Это изображение защищено авторским правом Geek & Poke под лицензией Creative Commons
Нарушение сборки имеет тяжелые последствия для графика проекта (и кровяного давления членов команды) => Другие разработчики, получившие последнюю версию, больше не смогут собрать свои собственные изменения, что задержит их выполнение => Непрерывная интеграция будет нарушена, что означает, что формальное тестирование может быть отложено
Многие инструменты контроля версий (например, TFS) могут предотвратить проверку кода, который не компилируется или не проходит модульные тесты или тесты анализа кода.
Если вы сломаете сборку, как это случилось со мной вчера. Когда ваши товарищи по команде пытаются использовать исходный код. Он не будет собираться. Поэтому им будет трудно тестировать работу, которую они делают. Это становится тем хуже, чем больше ваша команда.
Конечно, весь смысл непрерывной интеграции заключается в раннем выявлении проблем. Ежедневные или более частые проверки необходимы, чтобы уменьшить конфликты до управляемого размера.
Вы должны получить актуальную копию репозитория и собрать локально. Это покажет вам, не нарушит ли предлагаемая вами проверка сборки. Вы решите все проблемы, а затем выполните регистрацию.
Таким образом, проблемы интеграции будут локальными и легко устранимыми.
Как только сборки начинают ломаться, люди начинают неохотно получать последние изменения, и вы начинаете смертельную спираль к интеграции изменений Большого Взрыва.
Я не думаю, что нарушение сборки - это обязательно плохо, пока в репозитории есть известная, рабочая ветка или метка. Тем не менее, создайте свою собственную ветку в репозитории, если вы знаете, что ваш код сломает сборку сегодня, но вы исправите его на следующей неделе. Тогда позже вы сможете слиться обратно в ствол.
Потому что это означает, что кто-то сделал что-то плохое (или, по крайней мере, некоторые изменения вступили в конфликт), и вы больше не можете собирать и развертывать свою систему.
Нарушение сборки означает, что вы поместили в общий репозиторий код, который либо (а) не компилируется, либо (б) не работает (не проходит модульные тесты). Любой другой, кто разрабатывает из этого общего хранилища, будет вынужден иметь дело со сломанным кодом, который вы зафиксировали, пока он не будет исправлен. Это приведет к снижению производительности всей команды.