Когда я начал создавать сервер непрерывной интеграции, я наткнулся на выражение "Неплохо, чтобы сломать сборку [кода]". Закончив этот проект, я пришел к выводу, что
Итак, мой вопрос в духе №2: почему нарушает сборку плохой вещи?
Потому что, если другие люди проверяют ваши нарушенные изменения, они не смогут работать, или если они это сделают, они сделают это менее эффективно.
Это также означает, что вы не должным образом проверяете свои изменения перед фиксацией, что является ключевым в CI.
Будьте очень осторожны при маркировке "Breaking the Build" как плохой. Это то, что требует немедленного внимания, но это также очень нормальная и ожидаемая часть цикла разработки. Вот почему Непрерывная интеграция настолько полезна - она сразу сообщает вам, когда сборка нарушена, и какой набор изменений вызвал ее. Это поможет вам быстро вернуться в исходное положение.
Если ваша культура наказывает "Разрушение строения", вам угрожает культивирование токсичной рабочей среды. Опять же, считайте, что это то, что требует немедленного внимания, но не называйте его "плохим".
От Мартина Фаулера http://martinfowler.com/articles/continuousIntegration.html
Весь смысл работы с CI что вы всегда развиваетесь на известной стабильной базой. Это не плохо вещь для построения магистрали, чтобы сломаться, хотя, если это происходит время говорит, что люди не достаточно тщательно об обновлении и создавая локально до фиксации. когда построение магистрали действительно ломается, однако важно, чтобы фиксированный быстро.
Потому что, если другие люди проверяют изменения, они не смогут работать...
Этот образ защищен авторским правом Geek and Poke под Лицензия Creative Commons
Он сломал сборку, как это случилось вчера. Когда ваши товарищи по команде пытаются использовать исходный код. Он не будет строить. Поэтому они будут пытаться проверить работу, которую они выполняют. Это становится все хуже, чем ваша команда.
Конечно, цель непрерывной интеграции - выявить проблемы на ранней стадии. Ежедневные или более частые проверки необходимы для уменьшения конфликтов до управляемых размеров.
Вы должны получить последнюю копию репозитория и создать локально. Это скажет вам, будет ли предложенная вами проверка нарушит сборку. Вы разрешаете любые проблемы, а затем регистрируетесь.
Таким образом, проблемы интеграции сохраняются локально и легко исправляются.
После того, как начнется взлом, люди не хотят получать последние изменения, и вы начинаете смертельную спираль к интеграции изменений в Big Bang.
Нарушение сборки имеет серьезные последствия для графика проекта (и артериального давления товарищей по команде) = > Другие разработчики, которые затем получают последнюю версию, больше не могут создавать собственные изменения, задерживая их = > Непрерывная интеграция сломается, что означает, что формальное тестирование может быть отложено
Многие средства управления версиями (например, TFS) могут запретить разработчикам проверять код, который не компилирует и не передает тесты анализа кода или кода.
Я не думаю, что нарушение сборки обязательно плохое, если в репозитории есть хорошо известная рабочая ветвь или тег. Тем не менее, создайте свою собственную ветку в репозитории, если вы знаете, что ваш код сегодня перестраивает сборку, но вы исправите ее на следующей неделе. Затем вы можете объединиться обратно в багажник.
Потому что это означает, что кто-то сделал что-то плохое (или, по крайней мере, некоторые изменения столкнулись), и вы больше не можете создавать и развертывать свою систему.
Нарушение сборки означает, что вы передали код в общий репозиторий, который либо (а) не компилируется, либо (б) не работает (сбой модульных тестов). Любой, кто развивается из этого общего хранилища, будет иметь дело с сломанным кодом, который вы совершили, до тех пор, пока он не будет исправлен. Это приведет к потере производительности для всей команды.