Командная разработка в Navision

[dmites]

4 кодера работают над разными проблемами одной системы. Часто объекты которые они правят в свих тестовых базах пересекаются в результе заливая в боевую базу труды своей деятельности они накрывают достижения своих коллег. Есть ли опыт по разруливанию подобных ситуаций ??

[DA_NEAL]

Советую сначала поискать на форуме схожие темы а потом задавать вопросы. Тема много обсуждалась.

[dmites]

Неинформативный ответ (

[Yoil]

Ну если совсем лень попытаться решить проблему административно, воспользуйтесь чем-нибудь типа araxis-merge.

[dmites]

так и делаем... миксуем код
но отнимает кучу времени

[Yoil]

А какой Вы надеялись услышать?
Что кто-то подскажет мегасофтину, которая сама решит все траблы?
На мибусо.ру кто-то предлагал что-то такое для Navision (не мегасофтину, но нечто, помогающее решать подобные проблемы, за бабло, разумеется), поищите.

[NeNavision_imported]

Мы решаем такую проблему так. В рабочую базу имеет право ставить объекты только один человек. Все разработчики после того как разрабатываемый функционал (объекты) оттестированы консультантами на локальных базах, присылают объекты. Если пересечений объектов нет (по тэгам), то ставим, если есть пинаем разработчиков, чьи объекты пересеклись, они сами договорятся. В 99% случаев проблем не бывает. Вообщем, если следовать методологии разработки проблем в основном и нет. Девтул на крайний случай. В основном это организационный вопрос, а использование дополнительных программ только добавляет проблем.

[Wizard_imported]

Цитата:

Сообщение от NeNavision

Мы решаем такую проблему так. В рабочую базу имеет право ставить объекты только один человек. Все разработчики после того как разрабатываемый функционал (объекты) оттестированы консультантами на локальных базах, присылают объекты. Если пересечений объектов нет (по тэгам), то ставим, если есть пинаем разработчиков, чьи объекты пересеклись, они сами договорятся. В 99% случаев проблем не бывает. Вообщем, если следовать методологии разработки проблем в основном и нет. Девтул на крайний случай. В основном это организационный вопрос, а использование дополнительных программ только добавляет проблем.

+1

[ovod]

Вам сюда:
http://www.fsh-soft.ru/prod/NCT/

Правда, имеющаяся на сайте версия, как выяснилось уже после выпуска релиза, рабоает только при CASE INCENSITIVE установках на сервере. И требует, естественно, SQL версии на площадке разработчика.

Но в остальном впечатление крайне положительное. Качество работы улучшилось радикально.

[a_mitin]

У нас самописаная примочка для SQL-версии навижен. Основана на триггере на табл. Objects. Вокруг этого написано несколько фукнций по взятию объекта на редактирование - возврата объекта после редактирования и закачке объекта в мастер-копию (закачивать приходится руками -fobами, ибо Nav не предоставляет интерфейсов сделать это программно) + всякие задачи программистам и т.д. Это всё вокруг этого триггера... Основное - триггер запрещает редактировать объект, пока ты его не взял на редактирование. Ну а когда выкладываешь - в архивную копию сохраняются В общем такой простенький и довольно удобный SourceSafe получился

[Storkich]

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

[Yuriy]

1. Вести разработку на сервере тестовой версии и потом сливать все силами одного человека на рабочую версию
2. Если SQL - можно написать примочку, основанную на работе триггеров SQL таблицы Object
3. Если не SQL тут, ессно, если разработчики планируют изменять один и тот же объект - пусть договариваются

Это распространенная практика работы групп программистов Navision на западе.