Какие средства разработки и создания жизненного цикла вы используете?

Я работаю над переходом моего нынешнего проекта примерно из 20 разработчиков в современную среду разработки и сборки. В настоящее время мы используем систему управления исходным кодом на основе RCS и связанную с ней систему отслеживания проблем, как с мотивом UI. Не существует формального процесса создания производства, его все работает.

Меня интересует:

  • Средства разработки
  • Контроль версий
  • Отслеживание ошибок
  • Управление зависимостями
  • Управление конфигурациями
  • Автоматическое здание
  • Автоматическое тестирование
  • Непрерывная интеграция
  • Управление артефактами
  • Управление выпуском
  • Управление развертыванием
  • Отслеживание требований
  • Что еще?

Мне интересны не только те инструменты, которые вы используете, но насколько хорошо они интегрируются друг с другом, как легко они настраиваются и используются, и как им нравятся как разработчики, так и менеджеры. Наш проект представляет собой комбинацию Java, С++ и VHDL, но мне все равно хотелось бы услышать от людей с другими языками. Я сейчас иду по пути затмения, подрывной деятельности, trac, maven, hudson и nexus.

Кроме того, есть ли лучший термин, чем "Build Lifecycle", который включает в себя не только создание, но и поток кода, с которого разработчик создает его, когда он построен, протестирован и в производственной системе? "Жизненный цикл сборки" кажется ограниченным, но "жизненный цикл проекта" уже выполнен.

Ответы

Ответ 1

  • Средства разработки JetBrains IntelliJ IDEA
  • Управление версиями Subversion
  • Отслеживание ошибок Atlassian Jira
  • Управление зависимостями Maven
  • Управление конфигурацией TeamCity
  • Автоматическое здание TeamCity
  • Автоматическое тестирование JUnit (?)
  • Непрерывная интеграция TeamCity
  • Управление артефактами Maven
  • Управление релизами Homo Sapien
  • Управление развертыванием Maven/Homo Sapien
  • Требования Трассировка Желаемое мышление
  • Однократная автоматизация Bash
  • Документация разработчика для разработчиков MediaWiki

Ответ 2

Я ненавижу Maven меньше, чем ненавижу Ant, а для Java вам нужно выбрать одно из этих зол. Если вы только начинаете, выберите Maven, тем более, что вы уже осознали, что ваш жизненный цикл сборки включает 12 разных и сложных дисциплин! Вам нужно будет выбрать соглашения для всех. Спасите себя от неприятностей и соглашайтесь с соглашениями, которые уже установил Maven.

Для непрерывной интеграции и общей автоматизации сборки мне нравится Hudson.

Ответ 3

В течение последних двух лет мы постепенно переходим от стратегии "каждый проект к своему собственному инструменту" к решению Trac + SVN + SCons и очень довольны этим.

Переключение на SCons было немного работы, но действительно окупилось. У нас есть гетерогенная среда, в основном C/С++ для разных встроенных платформ, модули ядра, некоторые настольные приложения и различные модули Python в качестве кода клея. На самом деле SCons сияет, когда вы хотите добавить поддержку своих собственных компиляторов и нишевых инструментов и вам необходимо адаптировать систему сборки к вашим требованиям. Раньше нам приходилось использовать другой графический интерфейс практически для каждой встроенной платформы - теперь, когда SCons напрямую вызывает компиляторы, рабочий цикл немного улучшился.

Наши разработчики либо использовали Emacs, либо Vim, и никто не хотел переключаться ни на что другое, поэтому мы (к счастью) придерживались этого. Я не очень хорошо разбираюсь в развертывании, поэтому я не могу говорить об этом.

Ответ 4

Если вы работаете с .NET, вам сложно побить Team Foundation Server для его интеграции с Visual Studio. Он содержит инструменты разработки, контроль версий, отслеживание проблем, управление конфигурацией, автоматическое тестирование, модульное тестирование, автоматическое построение, управление артефактами и все, что вы описали.

Конечно, TFS дорогой, часто не интуитивно понятный и отсутствует некоторые функции по сравнению с другими инструментами, которые я использовал. Если у вас есть лицензия MSDN, вы можете использовать TFS для рабочих групп (до 5 пользователей IIRC) бесплатно.

Ответ 5

Мы - магазин MS, использующий VS2008. Мы используем Subversion с Tortoise для SCC и управления версиями, а наш репозиторий размещен в сети, чтобы наша распределенная команда могла его использовать. Для сборки мы используем Hudson и CI, намного лучше, чем Nant или MSBuild. Отслеживание проблем - Bugzilla. Автоматическое тестирование - NUnit

Инструменты, которые следует избегать, включают Team Foundation Server и Sharepoint, слишком неуклюжие для использования в реальном мире.

BTW Кто-нибудь знает хороший инструмент Scrum, который может создавать схемы сжигания, идеально связанные с Basecamp?

Ответ 6

Мы также используем ряд инструментов, но мы все больше и больше движемся к Zed Builds and Bugs. Наша основная среда для разработчиков - Eclipse + Java, но мы также используем Visual Studio (все из них) и по меньшей мере 5 различных платформ unix.

Здесь полный список:

Ответ 7

Я использую svn и tac для некоторых моих проектов, а svn и fogbugz - для других. Они очень хорошо интегрируются.

Я все еще использую скрипты командной строки для сборки, поскольку они делают все, что мне нужно, включая grepping для ошибок и результатов отправки по электронной почте, но дни этой установки нумеруются. Я рассматриваю кросс-платформенные инструменты сборки.

Я использую Inno для выпусков win32. Пока нет продуктов для доставки на другой платформе - не знаете, как мы будем их развертывать.

Мы не затрагиваем многие другие пункты, о которых вы упоминаете, помимо какой-либо вспомогательной документации и кода и отслеживания проблем.

Ответ 8

Team Foundation Server и Visual Studio.

Я помню, когда мой идеал был отладчиком Sun Visual C, а source control копировал все исходные файлы в новый именованный каталог и помещал его на сервер, который должен был быть скопирован.

Только это не было