QA Automation, часть 1: CI сервер наше все
| January 10, 2012 | Posted by Andrey Rebrov under Практики, Статьи |
Часть первая
[Вводную часть можно прочитать здесь.]
Продолжаю серию постов про автоматизацию QA. Сегодня поговорим о CI серверах и как их можно необычно использовать. Рассмотрение пойдет больше под java-углом, но, думаю, может быть без проблем применено для любого языка. В статье я рассмотрю популярные сегодня CI сервера, их возможности по настройке и расширяемости и покажу какие плюшки можно получить от их грамотного использования. Поехали.
Итак, на сегодняшний день на рынке CI серверов для java-разработки есть следующие сервисы:
- TeamCity
- CruiseControl
- Apache Continuum
- Jenkins (он же Hudson)
Пройдемся по очереди по каждому из этих серверов.
TeamCity это продукт ребят из JetBrains, что уже говорит само себя, чего стоит только их IntelliJ IDEA. Сразу из коробки идет поддержка трех языков (Java, .NET, Ruby), само собой maven/ant + gradles, способна запускаться под Mac/Linux/Windows (хотя в свое время у меня были проблемы с запуском под винду). Есть два издания: бесплатное (20 конфигураций сборки и 3 агента) и платная (можно взять пробную лицензию на 60 дней). На данный момент уже сделано около 50 разнообразных плагинов, все лежат в одном месте и просто ставятся. Основные фишки:
- удаленная сборка и тестовый коммит (можно протестить локальную версию проекта из IDE);
- группировка тестов по уровню важности/риска;
- встроенная аналитика кода (Sonar становится не нужен);
- удобная работа с собранными артефактами на протяжении всей истории сборок;
- интеграция с amazon ec2;
- любители git/mercurial могут собирать прямо на своих ветках;
- и так далее.
Переходим к CruiseControl. В свое время убил достаточно много времени воюя с первой версией этого сервера, так что впечатления от него были не очень. Прошло время, вышла вторая версия, которая стала изрядно лучше. UI изменился в лучшую сторону – появился удобный и рабочий dashboard. Есть поддержка .NET (CruiseControl.NET) и ruby (CruiseControl.rb). Плюсов я как-то особых не нашел, но есть минусы:
- через веб-интерфейс сложно добавить / просмотреть / … и еще что-то сделать с проектом;
- плохая интеграция с тестовыми инструментами;
- проблемы с расширениями (хотя таки есть расширение для работы с php).
Мое мнение – представляет собой чисто академический интерес.
Переходим к Continuum. Так же продукт известного производителя – Apache, а это значит нас ждет отличная интеграция с maven. Кроме того приложение имеет приятный веб-интерфейс, через который можно создавать и управлять проектом. Так же к плюсам относятся простота установки и настройки. Имеет стандартный набор функционала – распределенный билды, разные типы оповещений, поддержка разных видов репозиториев. Из коробки работает только с java, да и плагинов я больно не видел. В общем, если вам нужен надежный инструмент – обратите внимание на Continuum, минимум головной боли при установке/настройке, максимум пользы потом.
И мы наконец добрались до Jenkins. На текущий момент, на мой взгляд, это один из лучших CI серверов для java-разработчиков. Что в нем есть. Берем все что есть в Continuum и добавляем следующее:
- очень большая аудитория и активное сообщество;
- гигантское количество плагинов (более 400);
- простая расширяемость под любой язык (Python? – нет проблем!);
- интеграция с невероятным количеством ПО (как насчет управления со своего iPhone?);
- предельно простая установка в один клик под ряд платформ;
- более чем удобный веб-интерфейс, через который можно настроить проект как только душа пожелает.
В качестве паузы предлагаю посмотреть на эту матрицу сравнения различных CI-серверов.
Продолжаем. Я так позитивно расписываю Jenkinsне потому что у нас это корпоративный стандарт, но и потому, что благодаря нему, мне удалось автоматизировать ряд штук, да и в принципе улучшить ряд вещей. Сразу советую прочитать вот этот документ, в нем содержатся 7 советом по оптимизации Jenkins, пригодится.
Пара общих советов:
- советую поставить HTML publisher plugin, сможете публиковать собственные отчеты;
- Sonar plugin ставим однозначно – нам не нужен запах в коде;
- если есть возможность синтегрироваться с багтрекером, делайте это.
Начнем с простого. Как настроить проект, я рассказывать не буду, об этом можно почитать вот тут, только дам советы и расскажу о паре трюков:
- можно настроить выполнение сборки не только на конкретном узле, но и на группе узлов через regexp;
- пользуйтесь сборкой по расписанию, чтобы сборка была доступна в нужные моменты (например, перед stand-up meeting);
- всегда выкачивайте полностью версию продукта и чистите репозиторий maven или любой другой среды, это сбережет вам массу времени;
- для каждого проекта лучше иметь свою версию maven репозитория, иначе будут зависимости;
- весь анализ кода оставьте на долю Sonar, так что смело ставьте галочку его использовать;
- не бойтесь иметь много задач на разные ветки и разные конфигурации сборок, вам это поможет, когда появится необходимость, что-то быстро протестировать или проверить.
А теперь, для чего еще можно использовать Jenkins:
- собрать версию приложения для установки;
- установить приложение на нужный сервер;
- запустить selenium тесты;
- получить актуальную информацию а базе данных и ее схему;
- получить актуальную UML-диаграмму.
1. Сборка приложения. Это делаем обязательно в тех случаях, когда нужно отдавать приложение кому-то. Неважно, в каком виде собирается итоговая версия: war, exe, файлы для копирования на диск, процесс полностью загоняем в Hudson. Если готовую сборку нужно кому-то отдать, то лучше использовать что-то наподобие ftp uploader plugin, который еще и зальет все что нужно, куда угодно. В частности, он может заливать на нужный Application Server, так что мы плавно подошли к пункту…
2. Установка приложения. Вот тут могут возникнуть сложности. Если у вас небольшая компания, то все будет выглядеть просто:
- собрали приложение;
- скопировали на сервер;
- запустили сервер;
- выполнили нужные скрипты из консоли если нужно.
А вот если вы работаете, например, в банке, то могут возникнуть сложности. В частности наша команда столкнулась с тем, что на сервера можно установить приложение только через специальный веб-сервис, который тем не менее имел веб api и все уткнулось только лишь в написание нужных скриптов. Если вам не повезло, то вам остается только поднять у себя копию серверов и использовать простой механизм установки на них. Бывает.
3. Запуск selenium тестов. Подробно разберу в следующих постах, пока что только скажу – используйте maven, а так же заведите страницу в вашем приложение, куда вынесите следующие параметры:
- базы, на которых работает приложение;
- параметры сборки (время, сервер, входящий конфиг);
- переменные окружения.
Пригодится.
4. Схема базы данных. На днях натолкнулся на книжку Java Power Tools и нашел в ней пару интересных вещей. Первая – Schema Spy, обалденный инструмент который строит полную схему отношений вашей базы данных, а так же показывает массу полезной информации о таблицах. Сразу же приведу пример – он должен произвести впечатление =). Как прикручиваем это к Jenkins:
- в качестве процесса сборки вставляем строку запуска Schema Spy “java -jar …” не забыв указать, где у нас лежит он сам, драйвер базы данных и Graphviz, который построит нам замечательные схемы, на выходе имеем папку с index.html;
- в качестве html отчета данной сборки указываем как раз наш index.html;
- profit!
Как использовать. Мы встроили в вики на страницу со списком серверов, где стоит наше приложение по две ссылки на каждый сервер: первая – запускает обновление отчета (занимает около 2 – 3 минут), вторая – ведет на сам этот отчет. Удобно, базисты рады.
5. Рисование UML. В той же книге описан еще и UML Graph. Что он умеет:
- рисование только диаграмм классов;
- встраивание полученных диаграмм в JavaDoc;
- cвязка с maven.
Использовать просто – подробный алгоритм есть тут.
Таким образом на выходе после всех сборок мы будем иметь набор отчетов:
- успешность сборки;
- документация к сборке;
- сборка, залитая на сервер;
- дистрибутив.
Автоматизируйте и будет вам счастье!
В следующей части будет рассказ о Webdriver + TestNG и много буков.
Pingback: QA Automation, часть вводная | AgileRussia()