Study & DevО программировании и не только

Управление сборкой проектов вместе с teamcity. Часть 1

В последнее время я написал несколько серий статей посвященных различным аспектам управления процессом разработки программного обеспечения. Мы научились использовать maven для унифицированного представления проекта, а для хранения перечня всех заданий, возникающих в ходе разработки, мы использовали mantis. Сегодня пришло время рассказать еще об одной важной сфере в профессиональной разработке программного обеспечения – создание специализированного сервера, автоматизирующего задачу сборки проекта в единое целое. Так мы рассмотрим методики интеграции этого билд-сервера в существующую инфраструктуру предприятия (svn-репозитории).

Рассказ об teamcity будет логическим продолжением рассказа об maven. Давайте кратко вспомним то, какие задачи решает maven, и чего нам в нем не хватало. Maven – это, прежде всего, инструмент декларативного описания (внутри файла pom.xml) структуры проекта и всех его составляющих: модулей, зависимостей, плагинов. Благодаря четко сформулированному жизненному циклу проекта и гибкой архитектуре, построенной на идее плагинов, привязанных к определенным фазам жизненного цикла, мы могли с помощью maven записать практически любой сценарий сборки проекта. Благодаря наличию средств (тех же плагинов) для автоматического тестирования приложения (junit, jmeter, soapui) мы внедряли в процесс сборки проекта еще и оценку его качества. И все это было хорошо, но только до тех пор, пока разработкой проекта занимается небольшая команда разработчиков, где каждый знает, хотя бы в общих чертах, чем занимаются другие члены команды. По мере роста количества разработчиков растут и накладные расходы на организацию их взаимодействия, теперь нужно четко регламентировать процесс взаимодействия между отдельными командами их участниками. К примеру, после того как менеджер проекта выдает задания программистам, они приступают к работе, и зачастую выполняют свою часть работы, не имея представления о том, как их работа повлияет на работу остальных программистов. Упрощенно, процесс выглядит так: утром программист забирает из svn актуальную версию проекта, затем берет задание из mantis, работает над кодом, и в конце рабочего дня, результаты работы сохраняются обратно в cvs/svn репозиторий. Конечно, перед тем как выполнять commit наш разработчик запустил часть автоматизированных тестов для того, чтобы проверить качество своей работы и таким образом в cvs не окажется заведомо нерабочего кода. Но вот момент: никто не гарантирует того, что выполненные правки не окажут косвенного влияния на чей-то еще код и не поломают приложение. Практически не реально, чтобы перед сохранением результатов своей работы выполнить полную проверку всей существующей на текущий момент функциональности. Во-первых, это занимает массу времени, во-вторых, прогонка тестов может требовать специальных условий, которых может не быть на машинах рядовых девелоперов, и, в-третьих, тестирование – не самая простая наука и заниматься ей должны специалисты, т.е. отдел управления качеством. Значит наша цель в том, чтобы максимально облегчить работу тестеров. С одной стороны, мы делаем это, когда внедряем различные инструменты автоматического или полуавтоматического тестирования. Но остается простой до безобразия вопрос: откуда возьмется та версия разрабатываемого продукта, которую нужно тестировать? Кто должен выполнить ее сборку и как определить то, какие функции вошли в этот новый билд? Лучше всего внедрить следующий цикл разработки: в течение рабочего дня программисты решают выданные задания и сохраняют изменения в cvs. Вечером, перед тем как все уходят домой, на специально выделенной машине запускается процесс сборки проекта (билда) на основании последних правок в cvs/svn репозитории. Каждый билд получает порядковый номер, и поступает на вход “машине автоматического тестирования”. Эта “тестирующая машина” – всего лишь набор записанных сценариев автоматизированного тестирования приложения, которые могут выполняться достаточно длительное время и без присмотра человека – поэтому мы можем запустить их на ночь. Утром, придя на работу, тестеры видят, что последняя сборка прошла все предварительные тесты, а значит нужно проверить остальную функциональность и написать тесты для всех новых функций, реализованных за прошлый день. Если же сборка провалила автоматические тесты, то тестеры могут завести баг на исправление ошибки с четким указанием того для какой версии билда была утеряна функциональность. Когда баг или feature “закрывается” и для нее ставится в mantis статус “проверено и закрыто”, то также указывается то, начиная с какого номера билда реализованная функциональность должна быть в проекте. Благодаря тому, что для каждого билда ведется перечень всех правок cvs/svn правок, которые вошли в него, то можно четко определить, кто виноват в “запорченном” билде. В отдельных ситуациях цикл “сборка – тесты – баги” может быть более коротким и проходить несколько раз за день, либо используется техника с предварительными правками в cvs/svn. В последнем случае, меняется местами порядок “сохранить изменения в cvs/svn” и “собрать билд и протестировать его”. Т.е. большие правки выполняются в предварительный cvs/svn репозиторий, и только после того как цикл “сборка проекта и тесты” был успешно пройден, то правки переносятся из “предварительного” cvs-репозитория в “итоговый” репозиторий. Сегодняшняя статья начнет рассказ об одном из самых популярных продуктов семейства “Build management and continuous integration” – teamcity.

Разработкой teamcity (домашний сайт http://www.jetbrains.net/confluence/display/TCD4) занимается компания JetBrains. Та же компания создала известные и заслужившие уважение удобным интерфейсом и богатым функционалом инструменты для программирования: idea, reshaper, rubymine. Teamcity условно состоит из двух частей: веб-сервер и билд-агент. Так, после того как вы скачаете и установите себе на компьютер teamcity, то в списке зарегистрированных служб windows появятся два новых пункта: “TeamCity Web Server” и “TeamCity Build Agent Service”. Первая их них представляет собой веб-сервер (tomcat 6), на котором размещен веб-интерфейс для teamcity. С помощью этого интерфейса вы можете создавать конфигурации билдов, запускать и останавливать их, наблюдать за прогрессом операций и отслеживать составляющие билд правки из cvs/svn-репозитория и многое-многое другое. Но, и это важно, сам процесс сборки проекта не является зоной ответственности для “TeamCity Web Server”: за сборку проекта отвечает “TeamCity Build Agent Service”. Конфигурация “один веб-сервер и один билд-агент” является самой простой. Гораздо чаще применятеся конфигурация “один веб-сервер и отдельный билд-агент для каждой билд-конфигурации”. Т.е. teamcity фактически может быть распределена на нескольких компьютерах в сети. Один из компьютеров, на котором размещен “TeamCity Web Server”, играет роль дирижера, управляющего работой остальных машин с билд-агентами. Каждый раз, когда кто-нибудь инициирует билд, то “TeamCity Web Server” связывается с билд-агентами и узнает, кто из них может выполнить билд (обладает техническими возможностями). А затем билд ставится в очередь выполнения для того агента, который сейчас свободен и не занят другой работой.

Сразу же закроем вопросы относительно лицензирования и платности teamcity. Есть две лицензии teamcity - Professional Server и Enterprise Server. Первая из них является бесплатной и имеет следующие количественные ограничения: Professional Server не может обслуживать более трех билд-агентов, не может управлять более чем 20 билд-конфигурациями и на сервере не может быть зарегистрировано более 20 учетных записей. Количество учетных записей никак не связано с программистами, выполняющими правки в svn-репозитории, или численностью отдела QA/QM. Просто каждый пользователь, который может заходить в teamcity, наблюдать за ходом выполнения билдов и управлять ими, должен иметь учетную запись в рамках teamcity. Если же вы купили лицензию на Enterprise Server, то все упомянутые выше ограничения для вас не действуют, и вы можете создать любое количество билд-конфигураций, учетных записей и управлять любым числом билд-агентов. Также можно отдельно покупать лицензии на билд-агенты. К слову, если вы занимаетесь разработкой open source приложений, то, обратившись в jetbrains, можно свободно получить лицензию на Enterprise Server.

Давайте пройдем по основным шагам настройки teamcity для java проекта, управляемого с помощью maven. Небольшое отступление: на самом деле teamcity не является жестко завязанной на только java и только maven: teamcity агенты умеют обращаться с .net, java и ruby проектами. В особо “тяжелых ситуациях” вы можете запустить произвольное консольное приложение и анализировать результат его работы. Начну я с того, что покажу как установить и настроить сервер для svn-репозитория. Затем я создам небольшой java-проект, управляемый maven, и импортирую его в svn. Дело в том, что демонстрировать teamcity на “домашней” конфигурации, без отдельного cvs/svn репозитория – это значит сознательно выбросить половину вкусностей, которые есть в teamcity. С другой стороны, раз серия статей именно про teamcity, то я не могу делать большое отступление, посвященное установке и работе с cvs/svn. Здесь я могу только порекомендовать обратиться к опубликованным мною же весной прошлого года четырем статьям из серии “Системы управления версиями для программистов и не только”. А сегодня я познакомлю вас с очень простым в установке и настройке SVN-сервером VisualSVN (домашний сайт проекта http://www.visualsvn.com/server/). Фактически VisualSVN – это старый добрый веб-сервер apache с набором модулей-плагинов dav и svn. После того как вы скачали и установили VisualSVN, то получаете в свое распоряжение простую в использовании графическую панель управления (рис. 1).



Воспользовавшись меню “Create new Repository”, вы создадите новый репозиторий (давайте создадим репозиторий с именем demo1). Расположен репозиторий будет в подкаталоге “Repositories”, относительно того каталога, в который вы установили VisualSVN. Завершающим шагом настройки репозитория – будет создать список учетных записей пользователей, которые будут иметь доступ к репозиторию. По-умолчанию VisualSVN будет ожидать подключений на порту 8443, однако это можно переопределить, если в панели управления VisualSVN выделить элемент “Visual SVN Server” и вызвать через контекстное меню диалоговое окошко с настройками сервера “Properties”.

Итак, если теперь открыть браузер и ввести адрес вида https://localhost:8443/svn/ или http://localhost:8080/svn/, то вы увидите веб-страничку со списком всех зарегистрированных репозиториев. Второй шаг демонстрации предполагает, что я создал maven проект, который затем нужно импортировать внутрь VisualSVN-репозитория. Для этого я обратился к серии статей “ Наводим порядок в разработке ПО вместе с maven” и скопировал оттуда следующий файл pom.xml:
Как видите, это обычный maven-проект состоящий из одного модуля, со стандартным расположением каталогов. А из модулей-плагинов я настроил только один модуль компиляции, указав, что проект нужно собирать с версией java равной 1.5. Позже, по мере того как мы будем учиться работать с teamcity, мы будем возвращаться назад к этому файлу pom.xml и вносить в него правки, так чтобы maven брал часть данных нужных для правильной сборки проекта из настроек билд-конфигурации teamcity. Третий шаг примера – импорт maven проекта внутрь SVN. Опять таки, чтобы не загружаться не нужным материалом я предлагаю воспользоваться одним из лучших графических клиентов для SVN - TortoiseSVN (домашний сайт http://www.tortoisesvn.org/). После установки tortoisesvn и перезагрузки компьютера у вас появится в контекстном меню windows проводника новые пункты меню связанные с работой с SVN (опять таки, если вы новичок в SVN, то советую обратиться к моим ранним статьям). Теперь предполагая, что в первом шаге вы создали репозиторий с именем demo1 и указали, что репозиторий нужно создать с использованием стандартной и рекомендуемой схемой каталогов trunk, branches и tags, я захожу в каталог “tcitydemo” с maven проектом и выбираю в контекстном меню windows пункт “ TortoiseSVN -> Import”. Примечание: перед импортом очистите каталог target, т.к. в нем будут размещаться временные файлы, которые не нужны в SVN-репозитории. Затем, в появившемся диалоговом окне импорта проекта я указываю адрес репозитория (http://localhost:8080/svn/demo1/trunk/tcitydemo1/) и, опционально, комментарий к импортируемому проекту. Для проверки того, что проект был корректно импортирован в SVN-репозиторий, я сначала удалил изначальный каталог tcitydemo1, а затем выполнил команду извлечения проекта из SVN-репозитория “контекстное меню windows -> SVN Checkout”. После того как я указал в текстовом поле адреса SVN-сервера путь http://localhost:8080/svn/demo1/trunk/tcitydemo1/ и указал каталог, куда нужно извлечь содержимое svn-репозитория, то у меня на компьютере появилась копия каталога tcitydemo1. На этом я буду считать завершенными все подготовительные шаги по созданию проекта и теперь перехожу к настройке teamcity.

Первым шагом после того, как я установил teamcity, то я зашел в панель управления службами windows и запустил две службы, составляющих teamcity: web server и build agent. Теперь можно открыть в браузере адрес http://localhost:9090 (номер порта указывается при установке teamcity) и на первой страничке teamcity сразу же попросит нас создать учетную запись администратора. После того как учетная запись администратора была создана, и мы вошли внутрь teamcity, то увидим интерфейс в духе спартанского минимализма с шестью закладками: “Projects”, “My Changes”, “Agents”, “Build Queue”, “Administration” и “My Settings & Tools”. Основное внимание на вкладку “Agents”. На ней находится перечень обнаруженных teamcity компьютеров с установленными билд-агентами. Изначально, в перечне будет только один агент, установленный вместе с teamcity (имя агента по-умолчанию совпадает с именем компьютера). Теперь предположим, что вы хотите разнести по различным машинам билд-агент и веб-сервер teamcity или вы хотите зарегистрировать несколько управляемых build-агентов. На вкладке “Agents” вы видите ссылки на загрузку инсталляционных файлов билд-агентов. Это может быть либо классический MS Windows Installer, либо инсталлятор в виде исполняемого файла Java Web Start (при работе с linux). В любом случае, после того как инсталлятор агента вы загрузили и выполнили его, то вас попросят указать каталог, куда будет установлен агент. Советую учесть, что в этом же каталоге будет выполняться и, собственно, сборка проекта, так что нужно достаточное количество места. Затем появится диалоговое окно, в котором нужно указать параметры коммуникации агента с веб-сервером teamcity (см. рис. 2).



Из основных настроек нужно задать номер порта, на котором будет размещен билд-агент (ownPort) и адрес веб-сервера teamcity (serverUrl). После завершения установки агента и его запуска, в интерфейсе вебс-вервера teamcity должны появиться все настроенные агенты. Все зарегистрированные и работоспособные сервера находится в таблице “Connected agents” (см. рис. 3).



Если же какой-то агент в текущий момент времени не может общаться с teamcity веб-сервером, то он попадает внутрь списка “Disconnected agents”. Каждый из билд-серверов может быть отключен на какое-то время и включен обратно, также мы можем отзывать с билд-серверов статус “авторизован”. В любом случае помните, на то, что лицензия Professional Server позволяет работать не более чем с тремя авторизованными и активными билд-агентами. Там же на вкладке с билд-агентами вы можете просмотреть статистику их работы, если откроете вкладки “Matrix” и “Statistics”.

В следующий раз я продолжу рассказ об teamcity и мы перейдем к непосредственно созданию проекта и связанных с ним билд-конфигураций.

« Mantis. Охотник на BUG-и. Часть 2

Управление сборкой проектов вместе с teamcity. Часть 2 »