Статьи

Непрерывная интеграция — это взлом!

Декабрь 21, 2018

удивлены, мало-Boy1 « Непрерывная интеграция — это взлом!» сказал мой друг Бен Рэди много лет назад во время дискуссии о CI, организованной Stelligent . В то время я был недоверчив! Как смеет кто-то подвергать сомнению ценность КИ, особенно когда мы только что закончили писать книгу об этом! Более того, наша книга была номинирована на престижную премию Джолта ; действительно, на следующий день наша книга CI выиграла это !

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

С другой стороны, если тесты, которые, возможно, являются наиболее существенным доказательством правильной интеграции, выполняются непрерывно , то нет времени ожидания для выявления проблем! Позиция Бена не вызывает удивления (особенно если вы его знаете), поскольку он продолжал играть главную роль в Infinitest и соавторе « Непрерывное тестирование»: с Ruby, Rails и JavaScript . С тех пор я осознал мудрость Бена и стал большим поклонником непрерывного тестирования.

41JUvNnTetL__AC_SR98,95_ Более проактивным средством обеспечения того, чтобы все было хорошо с базой кода, является постоянный запуск ваших тестов во время работы. На самом деле, еще более совершенный процесс — запуск любых тестов для измененного кода. То есть, если установлено соответствие между тестируемым кодом и соответствующим тестом, то, когда этот код изменяется, самый быстрый, возможно, самый эффективный способ убедиться, что код не нарушен, — это запустить его тест (ы).

Один из эффективных способов установить соответствие — это назвать тесты после того, как код, который они проверяют, продолжит использовать test моникер. Например, объект Account должен иметь соответствующий тест с именем AccountTest (или AccountSpec и т. Д.). Каждый раз, когда объект Account изменяется, тогда запускается AccountTest .

Непрерывное тестирование является признанной практикой в ​​мире Ruby. Отличная структура, которая облегчает это, называется Guard . Вкратце, Guard — это фреймворк для наблюдения за файловой системой и отправки уведомления о каком-либо событии (например, об изменении). С помощью Guard вы можете определить конкретные шаблоны сопоставления файлов и соответствующие действия, которые нужно предпринять при запуске события. Возможно, вы видите, что эта связь облегчает непрерывное выполнение тестов.

На самом деле в Java нет инфраструктуры или инструмента следствия (кроме Infinittest и других инструментов IDE). Тем не менее, вы можете использовать Guard для постоянного тестирования Java- проекта. Я писал о том, как сделать это с Android более двух лет назад, и около 6 месяцев назад я подключился к плагину Guard для Gradle, который называется Guard :: Gradle .

Чтобы использовать Guard :: Gradle, вам нужно установить Ruby . Для тех, кто на OSX , у вас уже есть Ruby. После установки Ruby установка Guard :: Gradle не может быть более простой: просто откройте терминал в нужном проекте Gradle и введите:

Простая установка!

1
$ curl https://raw.githubusercontent.com/bricker/guard-gradle/master/etc/installer

Приведенная выше команда загрузит скрипт и выполнит его. Этот скрипт будет:

  • Установите Ruby’s Bundler
  • Установите плагин Guard :: Gradle
  • Создайте Guardfile умолчанию
  • Создать скрипт запуска Guard, дублированный guard.sh

Поэтому, после того как вы запустите guard.sh выше команду, просто запустите guard.sh чтобы запустить Guard :: Gradle! Каждый раз, когда вы изменяете файл в дереве исходных текстов, соответствующий тест будет выполняться с помощью задачи test Gradle.

Guardfile умолчанию предполагает стандартную настройку проекта Gradle с исходным кодом, расположенным в src/main . На самом деле, если вам интересно, взгляните на сгенерированный Guardfile и вы увидите:

По умолчанию Guard :: Gradle Guardfile

1
2
3
guard :gradle do
  watch(%r{^src/main/(.+)\.*$}) { |m| m[1].split('.')[0].split('/')[-1] }
end

516KKWTBt1L__AC_SR98,95_ Эта команда watch проверяет каталог src/main и пытается выполнить тест соответствующего файла. Если тест не найден, все тесты запускаются. Так или иначе, если изменение произойдет, вы пройдете некоторое количество тестов . который якобы обновляет ваш локальный каталог со всеми вышестоящими изменениями ). Следовательно, если вышестоящие изменения нарушили вашу локальную ветку, вы узнаете об этом немедленно. Больше не нужно помнить, чтобы «запустить тесты» — они всегда работают.

Конечно, Непрерывная интеграция — это не взлом. Но тогда Бен сделал пророческое замечание: если вы хотите быстро потерпеть неудачу и сократить время на обнаружение сбоев, почему бы не сделать это у источника? Почему бы не знать сразу, пока вы работаете, а не через некоторое время после того, как вы ушли? Предполагая, что у вашего проекта есть тесты , тогда Continuous Testing является ответом. Непрерывное тестирование — это проактивная инь к реактивной ян инь.

Проверьте Guard: Gradle сегодня и сразу узнайте, когда вы сделали решающее изменение! Теперь это то, что каждый может копать, верно?

Ссылка: Непрерывная интеграция — это взлом! от нашего партнера JCG Эндрю Гловера в блоге The Disco Blog .
34
Share: