С непрерывной интеграцией, почему тесты запускаются после совершения, а не раньше?

Question

Хотя у меня есть только репозиторий github, который я нажимаю (в одиночку), я часто забываю запускать тесты или забывать о передаче всех соответствующих файлов или полагаться на объекты, находящиеся на моей локальной машине. Это приводит к разрыву сборки, но они обнаруживаются только Travis-CI после ошибочной фиксации. Я знаю, что TeamCity имеет средство тестирования pre-commit (которое использует используемую среду IDE), но мой вопрос касается текущего использования непрерывной интеграции, а не для какой-либо одной реализации. Мой вопрос

Почему не меняется протестированы на чистую сборку машины - такие, как те, которые использует Travis-CI для пост фиксации tesing - , прежде чем этих изменения совершаются?

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

Answer 1

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

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

Answer 2

Сервер CI не совпадает с системой управления версиями. Сервер CI также проверяет код из репозитория. И поэтому код уже был зафиксирован, когда он тестируется на сервере CI.

Более обширные тесты могут проводиться периодически, а не во время проверки на то, что является текущей версией кода во время тестирования. Подумайте о мультиплатформенных тестах или тестах нагрузки.

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

Answer 3

Я предварить мой ответ с подробностями, что я бегу на GitHub и Дженкинс.

Зачем разработчику приходится выполнять все тесты локально до совершения. Особенно в парадигме Git, которая не является требованием. Что, если, например, для выполнения всех тестов требуется 15-30 минут. Вы действительно хотите, чтобы ваши разработчики или вы лично сидели, ожидая, что тесты будут выполняться локально до вашего фиксации и нажмите ваши изменения?

Наш процесс, как правило, выглядит следующим образом:

1. Внести изменения в местное отделение.
2. Запустите все новые тесты, которые вы создали.
3. Commit изменяется на локальную ветвь.
4. Надавите локальные изменения удаленно на GitHub и создайте запрос на pull.
5. Имейте процесс сборки, чтобы получить изменения и выполнить модульные тесты.
6. Если тесты не удались, затем исправьте их в локальной ветви и нажмите их локально.
7. Получить код изменения, рассмотренный в запросе на тяну.
8. После одобрения и всех проверок, нажмите на мастер.
9. Повторить все юнит-тесты.
10. Нажмите артефакт в хранилище.
11. Нажимайте изменения в среде (например, DEV, QA) и выполните любые интеграционные/функциональные тесты, которые основаны на полной среде.
    • Если у вас есть облако, то вы можете нажать ваши изменения в новый узел, и только после того, как все тесты окружающей среды проходят перенаправит VIP на новый узел (ы)
12. Repeat 11 до тех пор, пока протолкнули все предустановленные среды.
13. Если вы практикуете непрерывное развертывание, то все ваши изменения доходят до PROD, если все испытания, проверки и т. Д. Проходят.

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

Вы можете выполнять тесты локально, если это необходимо, но это не должно быть нормой.

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