Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
А расскажите, пожалуйста, что такое система непрерывной интеграции и для чего она нужна
В ншем случае в реальном времени после каждого коммита в транк сервер TeamCity собирает все изменения, выкатывает их на чистое пространство, создаёт базу данных с нуля, формирует конфигурационные файлы, и далее выполняет
* компиляцию исходных текстов;
* выполнение тестов RSpec;
Скоро на него ляжет также и выполнение функциональных тестов.
Результаты выполнения в случае неудачи или первого успеха рассылаются по почте и через Jabber.
Таким образом часто находятся неочевидные ошибки (например, неработоспособность миграций при db:migrate:reset).
Кроме того, TeamCity позволяет также тестировать набор изменений от разработчика ещё до коммита (pretested commit).
* компиляцию исходных текстов;
* выполнение тестов RSpec;
Скоро на него ляжет также и выполнение функциональных тестов.
Результаты выполнения в случае неудачи или первого успеха рассылаются по почте и через Jabber.
Таким образом часто находятся неочевидные ошибки (например, неработоспособность миграций при db:migrate:reset).
Кроме того, TeamCity позволяет также тестировать набор изменений от разработчика ещё до коммита (pretested commit).
А почему для этих же задач вы не используете autospec? В чем выгода?
Как я понял, главный плюс этой вещи в том, что оно сбрасывает базу и поднимает её, тем самым проверяя ещё и правильность написания миграций
Вы путаете эти штуки.
Autospec запустить на сервере под отдельной рабочей копией репозитория, конечно, можно, но давайте вместе продумаем, что еще нужно, чтобы это решение заработало:
Вообще-то, выше — это теоретические издержки. На самом деле Autotest (autospec) — это инструментарий разработчика для неприрывного тестирования / прогонки спецификаций во время написания кода, а TeamCity — инструмент для неприрывной интеграции, то есть он гоняет тесты не на отдельно взятый измененный файл, а на всю систему, на свежеустановленную в заданном окружении систему, все доступные тесты, не только RSpec.
Парсер лох, списку хана.
Autospec запустить на сервере под отдельной рабочей копией репозитория, конечно, можно, но давайте вместе продумаем, что еще нужно, чтобы это решение заработало:
- post-receive hook для репозитория, чтобы обновлялась серверная рабочая копия, на которой крутится autospec.
- Кастом форматтер для того, чтобы autospec выдавал какой-нибудь скажем html, который можно отправить по почте.
- Результат выполнения autospec надо будет куда-то как-то отправлять. Как? Я с ходу не помню решения. Не знаю, есть ли возможность использовать хуки в autospec. Ну в любом случае, можно пропатчить, благо это Ruby :)
Вообще-то, выше — это теоретические издержки. На самом деле Autotest (autospec) — это инструментарий разработчика для неприрывного тестирования / прогонки спецификаций во время написания кода, а TeamCity — инструмент для неприрывной интеграции, то есть он гоняет тесты не на отдельно взятый измененный файл, а на всю систему, на свежеустановленную в заданном окружении систему, все доступные тесты, не только RSpec.
Парсер лох, списку хана.
Autotest можно настроить под нужные тесты не сложнее, чем код из поста. Другое дело, что им удобно работать только в development.
Я правильно понял, что это инструмент для прогонки тестов в окружении, приближенному или равному production? И в этом весь смысл?
Я правильно понял, что это инструмент для прогонки тестов в окружении, приближенному или равному production? И в этом весь смысл?
Под нужные тесты, заметили? Не под прочие процедуры. А rake db:migrate:reset для начала кто сделает?
Смысл в том, что можно и левой рукой правое ухо. Я не сторонник TeamCity и такой подход практикую впервые, однако, поверьте, для цели всегда держать в репозитории заведомо разворачиваемый на production код — это лучший вариант.
Кстати, вы правы, да, выходит цель — прогонять тест на совместимость с продакшен окружением.
Смысл в том, что можно и левой рукой правое ухо. Я не сторонник TeamCity и такой подход практикую впервые, однако, поверьте, для цели всегда держать в репозитории заведомо разворачиваемый на production код — это лучший вариант.
Кстати, вы правы, да, выходит цель — прогонять тест на совместимость с продакшен окружением.
Кроме спеков, есть метрики типа rcov etc.
Есть много гитик.
Есть много гитик.
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.
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.
Что реально у вас сделано неправильно — нет утилиты командной строки для pretested commit.
Дело в том, что Eclipse весьма неудобен, как и любая другая Java-IDE (периодические тормоза, и постоянные глюки).
Была бы утилита командной строки, то любой разработчик смог бы воспользоваться вашей фичей, либо вручную, либо встроив в свою любимую IDE (vim, Komodo Edit, Notepad++ etc.)
Дело в том, что Eclipse весьма неудобен, как и любая другая Java-IDE (периодические тормоза, и постоянные глюки).
Была бы утилита командной строки, то любой разработчик смог бы воспользоваться вашей фичей, либо вручную, либо встроив в свою любимую IDE (vim, Komodo Edit, Notepad++ etc.)
Спасибо за предложение, мы думаем об этом. В последнем 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 плагин.
Pretested commit — одна из ключевых возможностей TeamCity.
А ориентация на лишь некоторые IDE крайне неудобна. Например, в нашей команде никто не использует Eclipse или Rubymine, используются только: TextMate, vim, ActiveState Komodo Edit, Notepad++.
Вообще, использовать Java GUI — тяжко из-за особенностей их сборщика мусора. Подвисать периодически на несколько секунд — некошерно.
Нужна именно CLI-утилита, которую можно будет синтегрировать с чем угодно.
Я даже готов буду по факту её наличия написать статью об этом :)
А ориентация на лишь некоторые IDE крайне неудобна. Например, в нашей команде никто не использует Eclipse или Rubymine, используются только: TextMate, vim, ActiveState Komodo Edit, Notepad++.
Вообще, использовать Java GUI — тяжко из-за особенностей их сборщика мусора. Подвисать периодически на несколько секунд — некошерно.
Нужна именно CLI-утилита, которую можно будет синтегрировать с чем угодно.
Я даже готов буду по факту её наличия написать статью об этом :)
Ушёл смотреть её )
На её основании удасться сделать нормальный pretested commit, если не ошибаюсь.
Разработчики обычно у нас просто работают удаленно по SSH, и коммиты обычно проводят из командной строки, а не из какой-либо IDE.
На её основании удасться сделать нормальный pretested commit, если не ошибаюсь.
Разработчики обычно у нас просто работают удаленно по SSH, и коммиты обычно проводят из командной строки, а не из какой-либо IDE.
> На её основании удасться сделать нормальный 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 для анализа ситуации.
Мы были бы рады какому-нибудь 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 для анализа ситуации.
Было бы здорово если бы вы поделились накопленным опытом еще раз.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интеграция с TeamCity