Comments 31
Можно сказать, что любой из приведнных компонентов легко заменяется альтернативным без ущерба. А вообще очень типичный наборчик и не для agile. Даже для «водопада» вполне водходящий
Вообще говоря не набором единым определяется agile :) От того, что он подойдет для водопада, хуже явно не будет :)
Поделитесь, пожалуйста, информацией про альтернативы. Очень заинтересовала меня эта тема.
Например:
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
> Про интеграцию Subversive и Mylyn см. документацию
Так все-таки Subversive или Subclipse?:)
для такого подхода к использованию системы контроля версий git будет удобнее
Мы использовали очень похожую схему, поэтому предлагаю несколько улучшений:
1. Артефакты в должны попадать в Nexus после сборки в TeamCity, после того как прошли юнит-тесты и функциональные тесты в независимом окружении, а не на машине разработчика, как нарисовано у вас на диаграмме. В Вашей диаграмме получается, что в репозиторий Maven могут попасть библотеки, которые содержат классы, которые не были добавлены в Subversion(что явно расстроит ваших колег). Кроме того TeamCity может корректно проставить версию вашему jar файлу, который будет добавлен в репозиторий Nexus, а иначе версионирование Ваших библиотек недетерменировано.

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

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

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

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

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

Мы используем следующие инструменты:
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 не любим.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.cr-media.ru
Employees
Unknown
Registered