инструменты, чтобы помочь небольшой магазин оценка выше на «Joel Test»

Question

Вопросы # 1 по # 4 на Joel Test на мой взгляд, все о средствах разработки используется и система поддержки на месте для разработчиков:

1. Вы используете источник управления?
2. Можете ли вы сделать сборку за один шаг?
3. Вы делаете ежедневные сборки?
4. У вас есть база данных ошибок?

Мне просто интересно, какие бесплатные/дешевые (но хорошие) инструменты существуют для небольших магазинов развития, у которых нет больших банковских счетов, чтобы использовать положительный ответ на эти вопросы.

Для контроля источника. Я знаю, что Subversion - отличное решение, и если вы являетесь магазином одного человека, вы можете даже использовать SourceGear's Vault.

Я использую NAnt для своих больших проектов, но еще не настроил скрипт для сборки моих инсталляторов, а также для запуска инструментов обфузии всего за один шаг. Любые другие предложения?

Если вы можете ответить «да» зданию за один шаг, я думаю, что создание ежедневных сборок было бы легко, но какие инструменты вы рекомендовали бы для автоматизации этих ежедневных сборок?

Для одной или двух человек команда, о которой уже говорилось выше, вы можете использовать FogBugz On Demand, но какие другие способы отслеживания ошибок существуют для небольших команд?

Answer 1

1. источник: Subversion или Mercurial или Git
2. автоматизации сборки: NAnt, MSBuild, Rake, Maven
3. непрерывной интеграции: CruiseControl.NET или Continuum или Jenkins
4. проблема отслеживания: Trac, Bugzilla, Gemini (если он должен быть .NET и свободной МОГ)

Не забывайте автоматизированные испытания с помощью NUnit, Fit и WatiN.

Answer 2

1) Subversion

2) Ant/Maven

3) Continuum

4) Управление Bugzilla/Trac

Answer 3

Хорошая проблема, которая была относительно недорогой, была axoSoft OnTime. Я использовал его много лет, прежде чем получить MS TFS.

Nant и CruiseControl являются основными продуктами моей окружающей среды.

Answer 4

Я не думаю, что вам действительно нужно обфускацию.Net no (see another response)

Я бы не рассматривал Vault, SVN на самом деле является лидером рынка на данный момент (и бесплатным). Git выглядит довольно многообещающим, но в настоящее время это командная строка только с крутой кривой обучения.

MSBuild бьет NAnt для .Net 2 или 3,5

CC.Net отлично.

Answer 5

Мой инженерный стек:

1. Git (я люблю GitHub, но Git не требует размещаемых решений)
2. Rake
3. CruiseControl.rb
4. FogBugz

Без сомнения, на этот выбор влияет мой стек разработки, который чаще всего включает Ruby, Rails, SQLite, Firefox и OSX.

Answer 6

* 4) Redmine

Я рекомендую Bitnami для тестирования из различных стеков. У него есть Trac, Redmine и Subversion, а также несколько других несвязанных.

Answer 7

У меня нет инструментов, чтобы предложить, но у меня есть предложение о ежедневных сборках. Я всегда отвечаю «да» на этот вопрос, хотя у нас нет ежедневных сборок. Вместо этого мы делаем сборку каждый раз, когда кто-то делает фиксацию. Таким образом, мы почти сразу сталкиваемся с проблемами. Если в любом из наших проектов когда-либо будет достаточно LOC, для строительства потребуется более тривиального времени, то это также будет грациозно деградировать в направлении ежедневной сборки.

Answer 8

Возможно, вы захотите посмотреть мой существующий вопрос для finding an alternative to Team System. В нем есть много рекомендаций.

Answer 9

Проверьте эти статьи на непрерывной интеграции с использованием MSBuild, CruiseControl.NET, FxCop, NUnit, NCover и Subversion ...

From the software development trenches

Answer 10

настоящее время я использую SVN, но я обычно имел много или проблема с проверками на сетевой диск на dev-сервере. Там, как правило, есть проблемы с блокировкой, для которых требуется много промысла. Возможно, использование метода доступа WebDav облегчит некоторые из этих проблем, но я еще не экспериментировал.

Любой из Bugzilla, Trac или Fogbugz поможет вам отслеживать ошибки, и каждый из них предлагает функцию экспорта, поэтому вы всегда можете изменить свое мнение позже. Кроме того, если вы можете получить вашу команду, чтобы полностью купить в программное обеспечение управления временем также может быть удобно для трупов и т.д. (если каждый будет мотивирован, чтобы в полной мере участвовать

Answer 11

Я предпочитаю стек:.

1) Subversion , Я заинтригован распределенным контролем источника, но у меня еще не было возможности попробовать в гневе. Для централизованного решения svn - твердое тело.

2) Ant. Maven - это радость от использования, когда он работает, но, как старый муравейник, я нахожу, что maven трудно следовать, как только все пойдет не так.

3) Гудзон. Не было упомянуто до сих пор, но определенно стоит исследовать.Невероятно полезный и активно поддерживаемый инструмент. PreviousLy мы заплатили за Anthill Pro, который казался чешуйчатым, и было больно исправлять каждый раз, когда он напортачил.

4) Мы платим за джира. Не дешево, но гораздо удобнее, чем варианты с открытым исходным кодом, на которые мы смотрели и очень гибкие.

Answer 12

Для автоматизации строительства и непрерывной интеграции см. TeamCity от Jetbrains.

У этого есть много features, и это действительно легкий ветерок для настройки и использования.

Если вы используете Visual Studio 2005/2008 он будет строить свое решение непосредственно без необходимости дополнительных скриптов (если построить все, что вы хотите.)

Он будет также выполнять модульные тесты и собрать статистику по сборке успех, время выполнения единичного теста и т. д.

Лучше всего: выпуск Pro бесплатный для команд с 20 пользователями и 3 агентами сборки.

Answer 13

1. Гит
2. Сделать
3. Крон
4. Trac

Я человек несколько слогов ;-)

Обязательно использовать какой-то контроль версий где разработчики могут легко создавать частные филиалы волей-неволей, затем отбирать свою частную ветку и втискивать ее в одну фиксацию на основной ветке. Таким образом, отдельные разработчики --- в отличие от организации - могут получить преимущества контроля версий, не загрязняя чей-либо код (и замедляя работу) с нарушенными коммитами.

Эта функция - это то, что мне нравится в git. Я думаю, что это реально присутствует в распределенных системах контроля версий; использование DVCS не означает, что вы действительно должны заниматься распределенной разработкой.

Что касается одноэтапного здания, make является инструментом построения по умолчанию, и он подходит для большинства задач. Я бы согласился с этим, если у вас нет веских оснований.

Вы хотите ежедневные сборки, поместите команду build в свой cron.daily. Настройте крюк procmail для обработки почты из cron, если это необходимо.

Для отслеживания ошибок используйте $(apt-cache search bug tracking). В принципе, до тех пор, пока он говорит «ошибка трекера» на коробке, и вы знаете, что другие люди его используют, вероятно, это будет нормально работать. Среди постоянных пользователей - bugzilla, mantis и trac. контроль

Answer 14

1. источник: резюме
2. сборки гну сделать
3. хрон, который вызывает Баш скрипты
4. Bugzilla