Comments 31
А кроме как Burndown, что здесь еще agile специфичного?
0
Организация кода в SVN, например.
0
Можно сказать, что любой из приведнных компонентов легко заменяется альтернативным без ущерба. А вообще очень типичный наборчик и не для agile. Даже для «водопада» вполне водходящий
0
В целом — да, согласен с Вами.
0
Поделитесь, пожалуйста, информацией про альтернативы. Очень заинтересовала меня эта тема.
0
Например:
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
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
+3
> Про интеграцию Subversive и Mylyn см. документацию
Так все-таки Subversive или Subclipse?:)
Так все-таки Subversive или Subclipse?:)
0
для такого подхода к использованию системы контроля версий git будет удобнее
0
Мы использовали очень похожую схему, поэтому предлагаю несколько улучшений:
1. Артефакты в должны попадать в Nexus после сборки в TeamCity, после того как прошли юнит-тесты и функциональные тесты в независимом окружении, а не на машине разработчика, как нарисовано у вас на диаграмме. В Вашей диаграмме получается, что в репозиторий Maven могут попасть библотеки, которые содержат классы, которые не были добавлены в Subversion(что явно расстроит ваших колег). Кроме того TeamCity может корректно проставить версию вашему jar файлу, который будет добавлен в репозиторий Nexus, а иначе версионирование Ваших библиотек недетерменировано.
2. Хорошим решением является интерграция баг-трекера с системой контроля версий, это позовляется закрывать задачи в багтрекере, просто коммитом с правильным комментарием — номером issue. Не уверен насчет возможностей Redmine, но если баг-треккер поддерживает управление релизами, то можно привязывать к релизу в багтреккере привызывать определенный бранч — для багфиксов, этим решается проблема документации, к какому релизу привязана какая ветка. (Соглашения соглашениями, а если есть простая возможность получить документирование проекта — имхо, нужно пользоваться)
3. Если у вас тестирование(функциональное и нагрузочное), и правда, автоматизированно, то по результатам сборки, результаты этих тестов, неплохо бы получать, как минимум, в виде артефактов в TeamCity, а лучше в баг-треккере/вики, потому что тогда у вас вся документация по закрытым багам и результатам тестов будет привязана к конкретной сборке/релизу
4. <юмор>ну и если уж у Вас Scrum, то неплохо бы стрелочку между разработчиком и тестером нарисовать, все таки коммуникации в agile превыше всего</юмор>
P.S. За Redmine спасибо — не знал о таком продукте.
1. Артефакты в должны попадать в Nexus после сборки в TeamCity, после того как прошли юнит-тесты и функциональные тесты в независимом окружении, а не на машине разработчика, как нарисовано у вас на диаграмме. В Вашей диаграмме получается, что в репозиторий Maven могут попасть библотеки, которые содержат классы, которые не были добавлены в Subversion(что явно расстроит ваших колег). Кроме того TeamCity может корректно проставить версию вашему jar файлу, который будет добавлен в репозиторий Nexus, а иначе версионирование Ваших библиотек недетерменировано.
2. Хорошим решением является интерграция баг-трекера с системой контроля версий, это позовляется закрывать задачи в багтрекере, просто коммитом с правильным комментарием — номером issue. Не уверен насчет возможностей Redmine, но если баг-треккер поддерживает управление релизами, то можно привязывать к релизу в багтреккере привызывать определенный бранч — для багфиксов, этим решается проблема документации, к какому релизу привязана какая ветка. (Соглашения соглашениями, а если есть простая возможность получить документирование проекта — имхо, нужно пользоваться)
3. Если у вас тестирование(функциональное и нагрузочное), и правда, автоматизированно, то по результатам сборки, результаты этих тестов, неплохо бы получать, как минимум, в виде артефактов в TeamCity, а лучше в баг-треккере/вики, потому что тогда у вас вся документация по закрытым багам и результатам тестов будет привязана к конкретной сборке/релизу
4. <юмор>ну и если уж у Вас Scrum, то неплохо бы стрелочку между разработчиком и тестером нарисовать, все таки коммуникации в agile превыше всего</юмор>
P.S. За Redmine спасибо — не знал о таком продукте.
+2
Спасибо, учтем!
0
Поделитесь, пожалуйста, опытом, как красиво интегрировать TeamCity-SVN-JIRA так, чтобы номер тега в SVN при успешной сборке билда становился бы сразу «видным» в JIRA в виде отдельного поля «build version». Идея в том, чтобы закрывать таски с JIRA с указанием номера сборки, в которой этот таск (баг) был закрыт. Нужно для тестировщиков. Если есть альтернативные мысли как связать сборки и таски, буду рад Вашим мыслям.
0
Огромное спасибо за статью. Очень хочется наладить работу в проекте, участником которого я являюсь. Буду очень благодарен за ссылки на полезные материалы.
0
В плане организации работы интересны статьи Ашманова:
www.ashmanov.com/pap/ashrul.phtml
www.ashmanov.com/pap/ashrul2/
Спасибо Сергею, что он открыл его для меня :)
www.ashmanov.com/pap/ashrul.phtml
www.ashmanov.com/pap/ashrul2/
Спасибо Сергею, что он открыл его для меня :)
0
Как вариант, большая часть плагинов заменяется функциональностью Cruise Control.
Не увидел статического анализа кода, например PMD.
Не увидел статического анализа кода, например PMD.
0
Хотелось бы услышать о системе документирования кода. Конечно, код должен документировать сам себя. Но все же желательно иметь какой-нибудь инструмент, который будет обеспечивать автоматической формирование документации, на основе хорошо написанного кода :)
0
А javadoc чем не хорош для этой цели?
0
Я не из мира java, возможностей javadoc не знаю :). Сам использую ndoc и ghostdoc.
Но хотелось бы иметь примерно следующее.
Имеется написанный код, методы и классы названы в соответствии с Agile принципами(тесты тоже :)).
После очередного «коммита», все это собирается, само документируется(ghostdoc или аналог) и выкладывается, например в wikki. В результате получаем готовое описание кода без лишних хлопот.
Но хотелось бы иметь примерно следующее.
Имеется написанный код, методы и классы названы в соответствии с Agile принципами(тесты тоже :)).
После очередного «коммита», все это собирается, само документируется(ghostdoc или аналог) и выкладывается, например в wikki. В результате получаем готовое описание кода без лишних хлопот.
0
Помимо javadoc мы еще широко используем Wiki
0
Бюрократы :))
0
? :)
0
Да я про burndown в редмайне и вообще все что с ним связано (с переводом багов в нужные статусы и т.п.). А что у вас за аджайл? Скрам?
0
Казалось бы, причем тут Agile…
0
Aptana пользовался, инструмент так сказать «швейцарский нож», но для меня она показалась глючной (ломала установку обновлений для eclipse на раз). Для манипуляций с html,jsp и проч. начал использовать
Jboss Tool. Есть удобный редактор web.xml
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 не любим.
Мы используем следующие инструменты:
— 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 не любим.
0
Sign up to leave a comment.
Инструменты инфраструктурной поддержки для Agile проекта на Java