Я не стал создавать отдельную тему. Если надо перенесите, но я подумал, что здесь можно задавать любые вопросы по поводу проектирования.

Начал читать книгу Нильссона "Применение DDD..." вот тут речь идёт о некоей сохраняемости, но толком непонятно, что это? Это принцип какой-то?

А что приходит в голову? Именно это и означает: возможность сохранить объекты домена в некоем хранилище для дальнейшего использования.

Вот что говорит Вики:

Интеграционные тесты для Веб приложений (MVC).

Именно такими, ИМО, они и должны быть.
Сценарий:

Тест:


А всякие WatiN, Sellenium -- в топку.

Хочу немного освежить тему несколькими вопросами:

•  Есть ли у кого опыт работы в территориально-распределённых проектах? Какими средствами пользуется такая команда(ы)?
•  На протяжении всей темы шёл спор о тех или иных методологиях. Мне интересен вопрос постановки процесса разработки. Представьте, что у Вас есть небольшая команда (4-6) разработчиков NET (WinForms, WinServices). С чего бы Вы посоветовали начать повышение качества разрабатываемого ими ПО? Т.е. каковы приоритеты и последовательность внедрения тех или иных методологий и соответствующих инструментов?

Для чистоты эксперимента примем, что у команды нет ничего, кроме системы контроля версий нет.
Прошу высказать свои предложения...

Это сообщение отредактировал(а) Unlocker - 25.3.2010, 14:20

ivashkanet, поздно заметил мессагу. Эти интеграционные тесты не тестят javascript, в котором больше всего проблем и вылазит. А тупо делать тест в виде серии веб-реквестов умеет сама студия, даже с записью. Но пользы в таком тестировании мало.

Unlocker, по процессу - все очень зависит от контекста. Если бы для любой небольшой команды подходил один и тот же процесс, его бы давно задокументировали, и назвали "Процесс 4-6". 
По инструментам - стандартый набор. любая система CI (ccnet/tfs/teamcity), любая гонялка тестов (*unit, mstest), что-то для code review...

PashaPash, не открою ничего нового, если скажу, что у старины Брукса идея про отсутствие "серебряной пули" была высказана довольно давно и чётко.



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

PashaPash, внедрялись ли в вашей организации системы учёта дефектов (багтрекеры), создавались ли базы знаний на основе движков Wiki или других средств?

Обсуждение можно продолжать...

Это сообщение отредактировал(а) Unlocker - 26.3.2010, 10:38

Unlocker, у нас основная связка cruise control.net + msbuild/mstest + selenium/watin для ui тестов. Test Track Pro как багтрекер (исторически сложилось, QA не хотят с него переходить). На паре проектов - HP Quality Center, но IMHO он монструозен немного  Ну и всякие wiki и crucible, по необходимости.

Из Continuous Integration утилит еще вроде TeamCity рассматривали. Можно поробовать еще TFS как полностью готовое решение (или полностью не готовое. 

Проще поднять конкретный набор на виртуалках и проверить. 

Даже ограничение "нет ничего, кроме системы контроля версий нет" - уже довольно сильное. Вдруг у вас там VSS. Или наоборот, Mercurial.

PashaPash, насчет VSS ты попал в точку. Он был поднят еще до моего прихода в компанию и сейчас начальство приходит к мнению о необходимости его постепенной замены. Насчет новой системы контроля версий склоняемся в пользу Subversion (центральный репозиторий исходных кодов легче бэкапить), систему отслеживания дефектов Trac. А вот насчет остальной инфраструктуры пока думаем... Build-сервером пока думаем сделать ccnet.
TFS нам при поверхностном знакомстве не понравился своей громоздкой настройкой (надо настроить всё и сразу), чего естественно без дорогих специалистов сделать не получится.
Систему тестирования пока тоже обсуждаем: nunit (этот вариант пока рассматривается основным), mbunit, mstest (с твоей подачи). Это надо отдельно решать, но не к спеху, т.к. это будет после системы учета дефектов.
Build-машина пока тоже не определена: первоначально хотели nAnt, но этот проект уже несколько лет как никто не поддерживает. Тут тоже предстоит собрать инфо и обсудить.
Ну а прочие прелести типа систем инспекции кода, база знаний MediaWiki будут подниматься по мере получения положительных результатов с предыдущих этапов.

Это сообщение отредактировал(а) Unlocker - 27.3.2010, 11:31

Unlocker, если у вас распределенная команда - берите mercurial. вместо nant - обычный msbuild.

TFS все-таки попробуйте. Там не все так сложно в настройке, и может оказаться проще чем настройка 5 отдельных утилит. По установке есть подробная, до клика, инструкция.

Видать, эта инструкция мне как-то попадалась к прочтению (500 с лишним страниц не произвели на меня впечатление "быстро и понятно"). Еще в TFS мне не нравится опора на SharePoint (у нас он использовался для внутрикорпоративных нужд). На мой взгляд, Wiki в том или ином виде значительно удобнее для простого сбора, поддержки и обновления информации по проектам (ну, вероятно, у меня такое мнение окончательно сложилось после оформления дипломной работы в TeXe, где в проекте много отдельных документов, связанных определенными ссылками) ;)

Кстати, одна из проблем в нашей инфраструктуре -- это хранение важных данных в системе инженерного документооборота в формате doc/excel. При большом количестве документов, разложенных в разных папках, найти нужную тебе информацию практически нереально. Исходя из информации, полученной от начальства, филиал первоначально будет пользоваться инфраструктурой центрального офиса, т.к. ответственный персонал будет именно в центре.

Mercurial и Git мы рассматривали в качестве возможной системы контроля версий, но сошлись на мнении, что с централизованным хранилищем работа будет удобнее (что впрочем еще подлежит проверке на практике). По крайней мере, в вопросе развертывания соответствующей инфраструктуры наверняка (см. выше).

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

PashaPash, спасибо за беседу. Любые интересные мысли с удовольствием выслушаю ;)

Это сообщение отредактировал(а) Unlocker - 27.3.2010, 15:27

Немного прочитал про сравнение между собой различных продуктов СУВ (CustIS). Убедился, что всё-таки в условиях компании и довольно больших продуктов выгоднее использовать Subversion: у распределенной системы повышенный расход дискового пространства на рабочих станциях и сложности слияния при достаточно большом количестве работников. SVN хорошо себя зарекомендовал на ресурсах "Sourceforge" и "Google Code", поэтому начнём с него.

Такой вопрос по инфраструктуре разработки: 
использовалась ли кем-нибудь для управления проектами разработкой связка Trac+Subversion под .NET? 
Если да, то какие плагины Trac'a вы считаете необходимыми при первоначальном развертывании?

Процесс обсуждения параллельно идет на другой площадке по адресу -- Agile Software Development.
Вопросы организации инфраструктуры для .NET-разработки в теме Инфраструктура NET-разработки.
Желающие могут присоединяться к обсуждению... 

PashaPash, а если в одно лицо, сам разрабатываешь продукт, что бы Вы применяли в смысле инструментов?

Это сообщение отредактировал(а) ДобренькийПапаша - 5.4.2010, 18:11

ДобренькийПапаша, очевидно, те же самые инструменты