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

Ответ 1

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

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

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

Я не могу придумать никаких причин не проводить непрерывное тестирование интеграции. Думаю, я предполагаю, что "непрерывная интеграция" включает тестирование. Просто потому, что он компилируется, это не значит, что он работает.

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

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

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

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

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

Ответ 2

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

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

Добавьте в заявку на сборку на каждом коммите, и требования начинают казаться невероятными. Возможные варианты: медленная обратная связь или удаление некоторых тестов.

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

При запуске требуется некоторое время, чтобы настроить все.

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

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

Ответ 6

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