В последнее время я написал несколько серий статей, посвященных различным аспектам управления процессом разработки программного обеспечения. Мы научились использовать 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 (домашний сайт httр://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 (домашний сайт проекта httр://www.visualsvn.com/server/). Фактически VisualSVN – это старый добрый веб-сервер apache с набором модулей-плагинов dav и svn. После того как вы скачали и установили VisualSVN, то получаете в свое распоряжение простую в использовании графическую панель управления (рис. 1). Воспользовавшись меню “Create new Repository”, вы создадите новый репозиторий (давайте создадим репозиторий с именем demo1). Расположен репозиторий будет в подкаталоге “Repositories” относительно того каталога, в который вы установили VisualSVN. Завершающим шагом настройки репозитория будет создание списка учетных записей пользователей, которые будут иметь доступ к репозиторию. По умолчанию VisualSVN будет ожидать подключений на порту 8443, однако это можно переопределить, если в панели управления VisualSVN выделить элемент “Visual SVN Server” и вызвать через контекстное меню диалоговое окошко с настройками сервера “Properties”.
Итак, если теперь открыть браузер и ввести адрес вида сайт или httр://localhost:8080/svn/, то вы увидите веб-страничку со списком всех зарегистрированных репозиториев. Второй шаг демонстрации предполагает, что я создал maven-проект, который затем нужно импортировать внутрь VisualSVN-репозитория. Для этого я обратился к серии статей “ Наводим порядок в разработке ПО вместе с maven” и скопировал оттуда следующий файл pom.xml:
Как видите, это обычный maven-проект, состоящий из одного модуля, со стандартным расположением каталогов. А из модулей-плагинов я настроил только один модуль компиляции, указав, что проект нужно собирать с версией java, равной 1.5. Позже, по мере того как мы будем учиться работать с teamcity, мы будем возвращаться к этому файлу pom.xml и вносить в него правки, так, чтобы maven брал часть данных, нужных для правильной сборки проекта, из настроек билд-конфигурации teamcity. Третий шаг примера – импорт maven-проекта внутрь SVN. Опять-таки, чтобы не загружаться ненужным материалом, я предлагаю воспользоваться одним из лучших графических клиентов для SVN - TortoiseSVN (домашний сайт httр://www.tortoisesvn.org/ ). После установки tortoisesvn и перезагрузки компьютера у вас появится в контекстном меню windows-проводника новые пункты меню, связанные с работой с SVN (опять-таки, если вы новичок в SVN, то советую обратиться к моим ранним статьям). Теперь, предполагая, что в первом шаге вы создали репозиторий с именем demo1 и указали, что репозиторий нужно создать с использованием стандартной и рекомендуемой схемой каталогов trunk, branches и tags, я захожу в каталог “tcitydemo” с maven-проектом и выбираю в контекстном меню windows пункт “ TortoiseSVN ->>> Import”. Примечание: перед импортом очистите каталог target, так как в нем будут размещаться временные файлы, которые не нужны в svn-репозитории. Затем в появившемся диалоговом окне импорта проекта я указываю адрес репозитория (httр://localhost:8080/svn/demo1/trunk/tcitydemo1/) и, опционально, комментарий к импортируемому проекту. Для проверки того, что проект был корректно импортирован в svn-репозиторий, я сначала удалил изначальный каталог tcitydemo1, а затем выполнил команду извлечения проекта из svn-репозитория “контекстное меню windows ->>> SVN Checkout”. После того как я указал в текстовом поле адреса SVN-сервера путь httр://localhost:8080/svn/demo1/trunk/tcitydemo1/ и указал каталог, куда нужно извлечь содержимое svn-репозитория, то у меня на компьютере появилась копия каталога tcitydemo1. На этом я буду считать завершенными все подготовительные шаги по созданию проекта и теперь перехожу к настройке teamcity.
Первым шагом после того, как я установил teamcity, я зашел в панель управления службами windows и запустил две службы, составляющих teamcity: web server и build agent. Теперь можно открыть в браузере адрес httр://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, и мы перейдем к непосредственно созданию проекта и связанных с ним билд-конфигураций.
black-zorro@tut.by black-zorro.com
Компьютерная газета. Статья была опубликована в номере 25 за 2009 год в рубрике программирование
Давайте пройдем по основным шагам настройки teamcity для java проекта, управляемого с помощью maven. Небольшое отступление: на самом деле teamcity не является жестко завязанной на только java и только maven: teamcity агенты умеют обращаться с .net, java и ruby проектами. В особо “тяжелых ситуациях” вы можете запустить произвольное консольное приложение и анализировать результат его работы. Начну я с того, что покажу, как установить и настроить сервер для svn-репозитория. Затем я создам небольшой java-проект, управляемый maven, и импортирую его в svn. Дело в том, что демонстрировать teamcity на “домашней” конфигурации, без отдельного cvs/svn репозитория – это значит сознательно выбросить половину вкусностей, которые есть в teamcity. С другой стороны, раз серия статей именно про teamcity, то я не могу делать большое отступление, посвященное установке и работе с cvs/svn. Здесь я могу только порекомендовать обратиться к написанным мною весной прошлого года четырем статьям из серии “Системы управления версиями для программистов, и не только”. А сегодня я познакомлю вас с очень простым в установке и настройке SVN- сервером VisualSVN (домашний сайт проекта httр://www.visualsvn.com/server/). Фактически VisualSVN – это старый добрый веб-сервер apache с набором модулей-плагинов dav и svn. После того как вы скачали и установили VisualSVN, то получаете в свое распоряжение простую в использовании графическую панель управления (рис. 1). Воспользовавшись меню “Create new Repository”, вы создадите новый репозиторий (давайте создадим репозиторий с именем demo1). Расположен репозиторий будет в подкаталоге “Repositories” относительно того каталога, в который вы установили VisualSVN. Завершающим шагом настройки репозитория будет создание списка учетных записей пользователей, которые будут иметь доступ к репозиторию. По умолчанию VisualSVN будет ожидать подключений на порту 8443, однако это можно переопределить, если в панели управления VisualSVN выделить элемент “Visual SVN Server” и вызвать через контекстное меню диалоговое окошко с настройками сервера “Properties”.
Первым шагом после того, как я установил teamcity, я зашел в панель управления службами windows и запустил две службы, составляющих teamcity: web server и build agent. Теперь можно открыть в браузере адрес httр://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”.