Ruby

индекс
128,98

Интеграция с TeamCity

В процессе разработки проекта на Ruby 1.9 нам потребовалось использовать систему непрерывной интеграции.

CruiseControl.rb в своё время не подошёл из-за несовместимости с Ruby 1.9, в результате мы остановились на бесплатной TeamCity Professional под Linux.

Начальная настройка тривиальна, потребует лишь распаковки дистрибутивов TeamCity и JRE, а также настройки переменной JRE_HOME.

Прямо из коробки мы можем получить запуск тестов Test::Unit, RSpec, с оценкой покрытия rcov.

Но нам потребовалось большее, например, использовать кастомные тесты.

Рассмотрим тривиальный пример — тесты на компилируемость (например, исходного кода, файлов в формате YAML etc.).

image



Естественным способом для запуска наших тестов будет использование Rake. Вот пример задачи для типичного Rails-приложения:

  1. module TeamCity
  2.   class Messaging
  3.     class << self
  4.       def teamcity?
  5.         defined?(Rake::TeamCityApplication)
  6.       end
  7.       def method_missing(symbol, *args)
  8.         Rake::TeamCityApplication.send_msg(
  9.           Rake::TeamCityApplication.tc_message_factory.send(symbol, *args)
  10.         ) if teamcity?
  11.       end
  12.     end
  13.   end
  14. end
  15. desc 'Compiles all sources'
  16. task :compile do
  17.   include TeamCity
  18.   sources = FileList.new('**/*.rb').exclude(/restful\-authentication\/generators\//).to_a
  19.   Messaging.create_tests_count(sources.size)
  20.   sources.each do |filename|
  21.     Messaging.create_test_started("Compiling #{filename}")
  22.     result = system("ruby -c #{filename}")
  23.     unless result
  24.       Messaging.create_test_failed("Compiling #{filename}", "Error compiling #{filename}", '')
  25.     else
  26.       Messaging.create_test_finished("Compiling #{filename}", 0)
  27.     end
  28.   end
  29. end


Теперь создаём проект TeamCity с целью rake compile и вуаля, всё работает;)
______________________
Текст подготовлен в Хабра Редакторе от © SoftCoder.ru
+20
31 августа 2009, 18:32
11

комментарии (22)

+4
mpetrunin #
А расскажите, пожалуйста, что такое система непрерывной интеграции и для чего она нужна
+6
akzhan #
В ншем случае в реальном времени после каждого коммита в транк сервер TeamCity собирает все изменения, выкатывает их на чистое пространство, создаёт базу данных с нуля, формирует конфигурационные файлы, и далее выполняет
* компиляцию исходных текстов;
* выполнение тестов RSpec;

Скоро на него ляжет также и выполнение функциональных тестов.

Результаты выполнения в случае неудачи или первого успеха рассылаются по почте и через Jabber.

Таким образом часто находятся неочевидные ошибки (например, неработоспособность миграций при db:migrate:reset).

Кроме того, TeamCity позволяет также тестировать набор изменений от разработчика ещё до коммита (pretested commit).
+1
mpetrunin #
Спасибо
0
silar #
Уж если пошли такие вопросы:)
То используете ли вы CI для обновления рабочего сервера?
Т.е. на тестовом сервере в БД у Вас только тестовые данные. А как вы вносите изменения в продакшн?
Спасибо!
+1
akzhan #
Capistrano, Puppet.
0
lexxscorp #
Рельсы 2.3 на руби 1.9 использовали?
0
SMiX #
А у вас с этим проблемы? Я с мая использую. И в последний месяц безо всяких костылей.
0
NaTTs #
2.3.2 используем, полет нормальный.
2.3.3 рушались.
–1
Over #
А почему для этих же задач вы не используете autospec? В чем выгода?
0
SMiX #
Как я понял, главный плюс этой вещи в том, что оно сбрасывает базу и поднимает её, тем самым проверяя ещё и правильность написания миграций
+1
Over #
autospec умеет то же самое
+1
NaTTs #
Вы путаете эти штуки.
Autospec запустить на сервере под отдельной рабочей копией репозитория, конечно, можно, но давайте вместе продумаем, что еще нужно, чтобы это решение заработало:
  • post-receive hook для репозитория, чтобы обновлялась серверная рабочая копия, на которой крутится autospec.
  • Кастом форматтер для того, чтобы autospec выдавал какой-нибудь скажем html, который можно отправить по почте.
  • Результат выполнения autospec надо будет куда-то как-то отправлять. Как? Я с ходу не помню решения. Не знаю, есть ли возможность использовать хуки в autospec. Ну в любом случае, можно пропатчить, благо это Ruby :)


Вообще-то, выше — это теоретические издержки. На самом деле Autotest (autospec) — это инструментарий разработчика для неприрывного тестирования / прогонки спецификаций во время написания кода, а TeamCity — инструмент для неприрывной интеграции, то есть он гоняет тесты не на отдельно взятый измененный файл, а на всю систему, на свежеустановленную в заданном окружении систему, все доступные тесты, не только RSpec.

Парсер лох, списку хана.
0
Over #
Autotest можно настроить под нужные тесты не сложнее, чем код из поста. Другое дело, что им удобно работать только в development.

Я правильно понял, что это инструмент для прогонки тестов в окружении, приближенному или равному production? И в этом весь смысл?
0
NaTTs #
Под нужные тесты, заметили? Не под прочие процедуры. А rake db:migrate:reset для начала кто сделает?

Смысл в том, что можно и левой рукой правое ухо. Я не сторонник TeamCity и такой подход практикую впервые, однако, поверьте, для цели всегда держать в репозитории заведомо разворачиваемый на production код — это лучший вариант.

Кстати, вы правы, да, выходит цель — прогонять тест на совместимость с продакшен окружением.
0
akzhan #
Кроме спеков, есть метрики типа rcov etc.

Есть много гитик.
0
chukovskij #
1. Если я не ошибаюсь, autotest гоняет изменившиеся тесты, а вообще хорошо было бы гонять все тесты на любой commit/push.
2. К тому же допустим, что кто-нибудь из команды сломал тесты и закоммителся, тогда после обновления сорцов из системы контроля версий autotest вам покажет, что у вас все сломано, но кто именно сломал нужно будет разбираться.
3. Опять же проблема в том, что у разных разработчиков разный environment, у одного на линуксе все работает, а у соседа с виндой все свалится.

ТеamCity позволяет решить эти три проблемы, а также многие другие. В первом случае будут прогоняться все тесты на проект, так же можно настроить, чтобы deployment выполнялся автоматически в зависимости от результата прогона тестов. Во втором случае вам прийдет нотификация по email/jabber/… или вы зайдете на билдсервер и увидите что данные тесты повали Вася 2 билда назад, сделав такие-то изменения. После чего можете назначить его ответственным за упавший билд и он/другие члены команды об этом сразу узнают. В 3-м случае вы настраиваете несколько разных environment и TeamCity прогонит тесты на всех них. Еще вам доступна статистика по прогону тестов/билдов, поэтому вы можете обнаружить «мигающие» тесты или те, которые долго работают.

Также в скором будущем планируется добавить «pretested commit» для git. При такой модели работы ваша IDE вместо полноценного коммита отправляет diff на сервер, далее TeamCity прогоняет тесты и только в случае успеха происходить реальный коммит. Пока эта фича доступна для svn/perforce при использовании Idea/Eclipse c TeamCity плагином.
Вообще понятие непрерывной интерграции шире, чем прогон тестов на коммит. Оно в общем описывает непрерывное поддержание целостности продуктов/компонент системы при непрерывно изменении ее частей. Например, у вас один билд может генерировать артефакты(библиотеки, плагины, документацию), которые потребуются для другого билда, в таком случае вам может потребоваться, чтобы артефакты и основной билд создавались с одной ревизии сорцов репозитория, или артефакты строились из одного бранча, а основной билд использовал сорцы из trunk.
0
akzhan #
Что реально у вас сделано неправильно — нет утилиты командной строки для pretested commit.

Дело в том, что Eclipse весьма неудобен, как и любая другая Java-IDE (периодические тормоза, и постоянные глюки).

Была бы утилита командной строки, то любой разработчик смог бы воспользоваться вашей фичей, либо вручную, либо встроив в свою любимую IDE (vim, Komodo Edit, Notepad++ etc.)
0
chukovskij #
Спасибо за предложение, мы думаем об этом. В последнем EAP есть command line утилита для remote run (http://www.jetbrains.net/confluence/display/TW/Darjeeling+EAP+Release+Notes+(build+10307) ). Отличается от «pretested commit» тем что итоговый коммит она не делает, т.е. просто сервер запускае т перснональный билд с вашими изменениями. Фича сейчас находится в экспериментальном состоянии и мы не уверены, что она кому-нибудь будет нужна, следовательно возможно выкинем с релиза 5.0. Возможно можно пойти другим путем, например, сделать маленькую бесплатную IDE на базе idea которая будет уметь только работать с VCS + поддерживать teamcity плагин.
0
akzhan #
Pretested commit — одна из ключевых возможностей TeamCity.

А ориентация на лишь некоторые IDE крайне неудобна. Например, в нашей команде никто не использует Eclipse или Rubymine, используются только: TextMate, vim, ActiveState Komodo Edit, Notepad++.

Вообще, использовать Java GUI — тяжко из-за особенностей их сборщика мусора. Подвисать периодически на несколько секунд — некошерно.

Нужна именно CLI-утилита, которую можно будет синтегрировать с чем угодно.

Я даже готов буду по факту её наличия написать статью об этом :)
0
akzhan #
Ушёл смотреть её )

На её основании удасться сделать нормальный pretested commit, если не ошибаюсь.

Разработчики обычно у нас просто работают удаленно по SSH, и коммиты обычно проводят из командной строки, а не из какой-либо IDE.
0
chukovskij #
> На её основании удасться сделать нормальный pretested commit, если не ошибаюсь.

Мы были бы рады какому-нибудь feedback на эту тему. Если народ начнет пользоваться этой утилитой, то мы ее не выкинем к релизу =), более того будем готовы что-нибудь улучшить. Поделится мыслями лучше на форуме Teamcity (http://www.jetbrains.net/devnet/community/teamcity/teamcity?view=discussions)

> Вообще, использовать Java GUI — тяжко из-за особенностей их сборщика мусора.
> Подвисать периодически на несколько секунд — некошерно

ИМХО это скорее общее заблуждение. Подвисание может происходить по разным причинам, а сборки мусора обычно довольно быстры и незаметны. Скорее, если программе нужно больше памяти, чем вы ей отвели (или завелся memory leak), тогда сборщик мустора дает о себе знать. Жава приложения не съедают всю доступную оперативную память, а используют только в пределах некоторого размера, установленного в настройках программы. Также, если программа в UI нитке выполняет что-то тяжелое, то GUI тоже перестает отвечать, но это общая проблема и не имеет отношения к JVM. В IDE обычно тормоза связанны с работой по обновлением AST деревьев, кешей + отягчается синхронизациями между различными threads, которые работают параллельно в фоне и что-нибудь анализируют. Если отключить всю работу с AST деревьями, то ничего тормозить не должно. Лично мое мнение, что IDE c умным анализом кода сложнее устроены чем простые редакторы, поэтому требует больше памяти, процессорного времени и в них потенциально больше perfomance багов, и в общем лучше посылать разработчикам snapshots для анализа ситуации.
0
mecommayou #
Было бы здорово если бы вы поделились накопленным опытом еще раз.

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