Инструменты инфраструктурной поддержки для Agile проекта на Java

    Ни для кого не секрет, что для слаженной работы команды, особенно в проектах управляемых по методологии Agile, важен эффективный обмен информацией между участниками. Для того, чтобы информационные потоки не разрушались под влиянием человеческого фактора, стандартные процедуры по управлению информацией автоматизируются. В данной статье рассмотрен пример технической инфраструктуры, использующейся сотрудниками компании ООО «Креатив Медиа» при разработке Web-проектов на платформе Java, например, в проекте социальной сети Campus.ru.

    В первой части данного обзора я перечислю используемые нами инструменты, а во второй – кратко опишу смысл их интеграции друг с другом.
    Итак, мы используем:
    Eclipse Ganymede for Java Developers – IDE для разработки.
    • Плагины для Eclipse:
    o Run-Jetty-Run плагин для отладочного запуска Web-приложения в локальном контейнере Jetty внутри Eclipse.
    o TestNG плагин для запусков автоматизированных юнит-тестов.
    o Aptana Studio для удобной работы с HTML, CSS, JavaScript
    o MDT для рисования UML-диаграмм
    o Subclipse плагин для интеграции с системой версионного контроля кода Subversion.
    o Mylyn плагин для интеграции с системой баг-трекинга Redmine.
    o M2 плагин для интеграции с системой сборки Maven.
    Maven 2 система контроля зависимостей модулей, сборки и развертывания проекта.
    Nexus локальный сервер Maven репозитория. Используется для хранения локальных артефактов Maven, и как прокси-сервер для локального хранения удаленных артефактов Maven. Значительно сокращает время загрузки удаленных артефактов всеми членами команды, и предохраняет от недоступности внешних репозиториев.
    Subversion система версионного контроля исходного кода проекта. Работа с исходным кодом организована в соответствии с Agile-методологией (подробнее см. здесь www.infoq.com/articles/agile-version-control).
    Team City система Continuous Integration для автоматических сборок проекта и запуска автоматических тестов, после каждого изменения кода в Subversion.
    Redmine система управления задачами и дефектами в проекте. Также имеет встроенную Wiki, которую мы активно используем для документирования важных архитектурных решений, требований и прочей полезной информации. Поскольку мы используем методологию Scrum, то очень полезным оказался плагин для Redmine, рисующий Burndown-диаграмму.
    JMeter инструмент для автоматизированного нагрузочного тестирования приложений.
    Selenium IDE инструмент для автоматизированного функционального тестирования приложений.
    • Email, ICQ, Skype, телефоны

    Данный набор продуктов позволяет проекту в меньшей степени зависить от человеческого фактора, и позволяет обеспечивать качество кода проекта на должном уровне. Как показано ниже на рисунке, большинство продуктов интегрированы друг с другом, обеспечивая еще бОльшую эффективность этого инфраструктурного решения.
    Интеграция продуктов друг с другом позволяет добиться желаемого результата за меньшее число действий и ничего при этом не забыть, а именно:
    • С помощью плагина M2, операции по обновлению библиотек, сборке и развертыванию приложения можно выполнять не покидая среду разработки.
    • Плагин Subclipse позволяет осуществлять управление исходным кодом в Subversion также не покидая среду разработки.
    • При внесении изменений в код, хранящийся в Subversion, плагин Mylyn может автоматически переводить задачи в Redmine в нужный статус, на основании введенного в плагине Subclipse комментария. Про интеграцию Subversive и Mylyn см. документацию
    • В свою очередь, плагин Burndown для Redmine автоматически строит burndown диаграмму, на основании информации о закрытых в Redmine задачах.
    • После внесения изменений в Subversion, приложение Team City автоматически запускает сборочные скрипты Maven, которые осуществляют сборку, развертывание продукта на тестовом сервере, и его автоматизированное тестирование с помощью утилит TestNG и Selenium. По результатам этих действий все члены команды получают уведомление по email.

    image

    Для обеспечения адекватности тестирования, на тестовом сервере воспроизведена конфигурация промышленных серверов посредством настройки нескольких виртуальных машин VmWare.

    Важно упомянуть о сохранности данных. На сервере, где развернуты Subversion, Redmine, Nexus и Team City, все данные хранятся на зеркалируемых дисках (Raid 1), а также два раза в сутки информация архивируется и копируется в NAS.
    Для предоставления возможности удаленной работы, удаленный доступ ко всей инфраструктуре возможен через OpenVPN.
    Данная инфраструктура уже доказала свою эффективность, однако, мы не останавливаемся на достигнутом, и ищем новые пути совершенствования. Например, сейчас поглядываем в сторону системы версионного контроля GIT в надежде, что мерджинг бранчей в ней будет более дружелюбным.

    А закончить обзор хочется философской мыслью: какими бы совершенными инструментами Вы не пользовались, они не спасут проект, потому что, как известно, кадры решают всё. Во-первых — проекту нужна профессиональная команда, во-вторых – эффективая методология и поставленные процессы, а уже в-третьих – удобные инструменты, автоматизирующие эти процессы, и делающие профессиональную команду Эффективной Профессиональной Командой.

    Спасибо за внимание! Будет замечательно, если кто-нибудь тоже поделится своим опытом в данной области
    Creative Media
    Компания
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 31

      0
      А кроме как Burndown, что здесь еще agile специфичного?
        0
        Организация кода в SVN, например.
          0
          Можно сказать, что любой из приведнных компонентов легко заменяется альтернативным без ущерба. А вообще очень типичный наборчик и не для agile. Даже для «водопада» вполне водходящий
            0
            В целом — да, согласен с Вами.
              0
              Вообще говоря не набором единым определяется agile :) От того, что он подойдет для водопада, хуже явно не будет :)
              0
              Поделитесь, пожалуйста, информацией про альтернативы. Очень заинтересовала меня эта тема.
                +3
                Например:
                Eclipse — IntelijIDEA
                Redmine — заменяется Trac или другой (JIRA, Bugzilla, Mantis, etc) приличной системой багтрекинга (можно с отдельной Wiki, а ее выбрать отдельно)
                Maven 2, M2, Nexus — IvyDE, Ivy, IvySvnResolver (Кстати экономия на инфраструктурных единицах)
                TeamCity — CruiseControl, Hudson, etc
                Subversion, etc — любая система контроля версий (в частности для agile, мне кажется наиболее подходящей DVCS)
                TestNG — JUnit
          0
          > Про интеграцию Subversive и Mylyn см. документацию
          Так все-таки Subversive или Subclipse?:)
            0
            Последнее время — Subclipse :)
              0
              А почему именно она?
            0
            для такого подхода к использованию системы контроля версий git будет удобнее
              +2
              Мы использовали очень похожую схему, поэтому предлагаю несколько улучшений:
              1. Артефакты в должны попадать в Nexus после сборки в TeamCity, после того как прошли юнит-тесты и функциональные тесты в независимом окружении, а не на машине разработчика, как нарисовано у вас на диаграмме. В Вашей диаграмме получается, что в репозиторий Maven могут попасть библотеки, которые содержат классы, которые не были добавлены в Subversion(что явно расстроит ваших колег). Кроме того TeamCity может корректно проставить версию вашему jar файлу, который будет добавлен в репозиторий Nexus, а иначе версионирование Ваших библиотек недетерменировано.

              2. Хорошим решением является интерграция баг-трекера с системой контроля версий, это позовляется закрывать задачи в багтрекере, просто коммитом с правильным комментарием — номером issue. Не уверен насчет возможностей Redmine, но если баг-треккер поддерживает управление релизами, то можно привязывать к релизу в багтреккере привызывать определенный бранч — для багфиксов, этим решается проблема документации, к какому релизу привязана какая ветка. (Соглашения соглашениями, а если есть простая возможность получить документирование проекта — имхо, нужно пользоваться)

              3. Если у вас тестирование(функциональное и нагрузочное), и правда, автоматизированно, то по результатам сборки, результаты этих тестов, неплохо бы получать, как минимум, в виде артефактов в TeamCity, а лучше в баг-треккере/вики, потому что тогда у вас вся документация по закрытым багам и результатам тестов будет привязана к конкретной сборке/релизу

              4. <юмор>ну и если уж у Вас Scrum, то неплохо бы стрелочку между разработчиком и тестером нарисовать, все таки коммуникации в agile превыше всего</юмор>

              P.S. За Redmine спасибо — не знал о таком продукте.
                0
                Спасибо, учтем!
                  0
                  Поделитесь, пожалуйста, опытом, как красиво интегрировать TeamCity-SVN-JIRA так, чтобы номер тега в SVN при успешной сборке билда становился бы сразу «видным» в JIRA в виде отдельного поля «build version». Идея в том, чтобы закрывать таски с JIRA с указанием номера сборки, в которой этот таск (баг) был закрыт. Нужно для тестировщиков. Если есть альтернативные мысли как связать сборки и таски, буду рад Вашим мыслям.
                  0
                  Огромное спасибо за статью. Очень хочется наладить работу в проекте, участником которого я являюсь. Буду очень благодарен за ссылки на полезные материалы.
                  0
                  Как вариант, большая часть плагинов заменяется функциональностью Cruise Control.
                  Не увидел статического анализа кода, например PMD.
                    0
                    Согласен.
                    Team City тоже умеет делать анализ кода.
                    0
                    Хотелось бы услышать о системе документирования кода. Конечно, код должен документировать сам себя. Но все же желательно иметь какой-нибудь инструмент, который будет обеспечивать автоматической формирование документации, на основе хорошо написанного кода :)
                      0
                      А javadoc чем не хорош для этой цели?
                        0
                        Я не из мира java, возможностей javadoc не знаю :). Сам использую ndoc и ghostdoc.

                        Но хотелось бы иметь примерно следующее.
                        Имеется написанный код, методы и классы названы в соответствии с Agile принципами(тесты тоже :)).
                        После очередного «коммита», все это собирается, само документируется(ghostdoc или аналог) и выкладывается, например в wikki. В результате получаем готовое описание кода без лишних хлопот.
                        0
                        Помимо javadoc мы еще широко используем Wiki
                        0
                        Бюрократы :))
                          0
                          ? :)
                            0
                            Да я про burndown в редмайне и вообще все что с ним связано (с переводом багов в нужные статусы и т.п.). А что у вас за аджайл? Скрам?
                              0
                              Да, Scrum.
                                0
                                Зато согласитесь, burndown — это один из очень удачных инструментов отчетности высшему руководству :)
                                  0
                                  Соглашусь:) Мы чертим фломиком на бумажке, которая прилеплена магнитом на доске. Гораздо нагляднее:)
                            0
                            Казалось бы, причем тут Agile…
                              0
                              Aptana пользовался, инструмент так сказать «швейцарский нож», но для меня она показалась глючной (ломала установку обновлений для eclipse на раз). Для манипуляций с html,jsp и проч. начал использовать
                              Jboss Tool. Есть удобный редактор web.xml
                                0
                                Присоединяюсь ко всем заметившим, что данный набор технологий почти никак с аджайл не связан.

                                Мы используем следующие инструменты:
                                Intellij IDEA. Здесь я описывал, чем она лучше Eclipse.
                                — Для CSS, JavaScript, HTML — всё та же IDEA. Платная версия прекрасно с ними справляется.
                                — Для работы с SVN и GIT — всё та же IDEA. Она поддерживает эти системы из коробки, не нужно инсталлировать дополнительные плагины. И интерфейс у IDEA для DIFF и COMMIT гораздо более удобный.
                                — RunJettyRun — хорошая вещь, но мы предпочитаем писать свою запускалку. Здесь процесс описан подробно.
                                — Для Continuous Integration используем Jenkins. Не знаю, лучше ли он TeamCity, но по крайней мере бесплатный.
                                — Для управления задачами используем PivotalTracker. Вот это реально аджайлный продукт, Jira рядом с ним отдыхает.
                                — Для UI тестов — Selenide (в случае Java) или WatirSplash (в случае Ruby).
                                — Для зависимостей используем Ant+Ivy либо Gradle. Maven не любим.

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

                                Самое читаемое