Какие аргументы против использования непрерывной интеграции?

Question

Я могу придумать множество веских причин для его использования; однако, каковы его недостатки?

(кроме покупки другого сервера)

Каковы некоторые преимущества использования ежедневной сборки вместо нее?

Answer 1

(Стоит отметить, что под «непрерывной интеграцией» я имею в виду автоматизированную интеграцию с автоматизированным процессом сборки и автоматически запускает тесты и автоматически обнаруживает сбой каждого элемента.

Стоит также отметить, что «непрерывная интеграция» означает только транковый или тестовый сервер. Это не означает «проталкивать каждое изменение в прямом эфире».

Существует множество способов неправильной непрерывной интеграции.)

---

Не могу придумать ни одной причины, чтобы не проводить непрерывное интеграционное тестирование. Я предполагаю, что предполагаю, что «непрерывная интеграция» включает тестирование. То, что он компилируется, не означает, что он работает.

Если ваша сборка и / или тесты занимают много времени, то непрерывная интеграция может дорого обойтись. В этом случае, запустите тесты, очевидно связанные с вашим изменением, до принятия (инструменты анализа покрытия, такие как Devel :: CoverX :: Covered могут помочь определить, какие тесты идут с каким кодом), проведите интеграционное тестирование после коммит, использующий что-то вроде SVN :: Notify , и предупреждает разработчиков, если это не удается Архивируйте результаты теста, используя что-то вроде Smolder . Это позволяет разработчикам работать быстро, не тратя время на просмотр тестовых комплектов, но все же рано обнаруживая ошибки.

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

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

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

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

Answer 2

Не думаю, что в этом есть какие-либо недостатки. Но, ради аргумента, вот статья Эрика Миника об UrbanCode («Речь идет о тестах, а не сборках».) Он критикует инструменты, основанные на Мартина Фаулера работа говорит, что они не дают достаточно времени для испытаний.

"Чтобы быть по-настоящему успешным в CI, Фаулер утверждает, что сборка должна быть самотестируемой и что эти тесты включают в себя как модульное, так и сквозное тестирование. В то же время сборка должна быть очень быстрой. - в идеале - менее десяти минут - потому что он должен запускаться при каждом коммите. Если имеется значительное количество сквозных тестов, их выполнение во время сборки при сохранении всего процесса менее десяти минут нереально.
< br /> Добавьте требования к сборке для каждого коммита, и требования начнут казаться невероятными. Возможны варианты с более медленной обратной связью или удалением некоторых тестов. "

Answer 3

У Джеймса Шора была отличная серия записей в блоге об опасностях думать, что использование инструмента CI, такого как CruiseControl, означает, что вы выполняете непрерывную интеграцию:

• Почему мне не нравится CruiseControl
• Непрерывная интеграция - это отношение, а не инструмент
• Непрерывная интеграция по доллару в день

Одной из опасностей при настройке CI-сервера является смещение целей, считая, что важно «поддерживать прохождение сборки», а не «гарантировать, что у нас высококачественное программное обеспечение». Таким образом, люди перестают беспокоиться о том, сколько времени потребуется для проведения испытаний. Затем им нужно слишком много времени, чтобы запустить их все перед регистрацией. Тогда сборка продолжает ломаться. Тогда сборка всегда нарушена. Поэтому люди комментируют тесты, чтобы пройти сборку. И качество программного обеспечения падает, но эй, сборка проходит ...

Answer 4

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

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

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

Answer 5

При запуске все настраивается.

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

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

Answer 6

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