Централизованный репозиторий в СУБД или SVN

Я работаю над созданием централизованного репозитория для хранения артефактов, созданных корпоративным архитектором (из систем Sparx), для использования командой из 6-8 человек. Первоначально предполагалось разместить базу данных PostgreSQL для централизованного хранения артефактов, и другой вариант, который был предложен, - это использовать SVN. Глядя на документацию EA, не получаешь четкого представления о том, каковы плюсы и минусы рассматриваемых вариантов. По сравнению с использованием SVN у меня есть следующие накладные расходы при использовании СУБД.

  1. Хостинг и управление СУБД
  2. Предоставление пользователей и управление для СУБД
  3. Версии артефакта нужно делать отдельно
  4. Резервное копирование и т. Д. Для СУБД

Что касается SVN, из документов EA упоминается, что модель развертывания подходит только для команды с максимальным размером 10, и существует вероятность повреждения файлов. Кроме этих узких мест в использовании SVN для размещения хранилища? Было бы здорово услышать предложения от людей, которые работали с Enterprise architect в многопользовательской среде.

Источник

4 ответа

Решение

Предупреждение "максимум 10 человек" относится к ситуации, когда у вас есть команда, совместно использующая один файл.EAP. Он не применяется, если у всех пользователей есть свой собственный файл.EAP или если вы настроили хранилище СУБД.

В настройке СУБД я рекомендую использовать базовые показатели EA для управления версиями, а не внешний репозиторий контроля версий. Концепция похожа: отдельные пакеты являются базовыми, но вместо того, чтобы хранить версии извне в SVN/CVS/etc, они хранятся внутри базы данных.

Это дает вам меньше хранилища для управления, но следует также отметить, что у EA есть проблемы при объединении СУБД с внешним контролем версий, которые могут раздражать или даже (в худшем случае) вызывать потерю информации. Внешний контроль версий предназначен для использования с файлами.EAP.

Базовые линии имеют одно большое преимущество перед внешним контролем версий: вы можете визуально сравнивать разные версии внутри EA и видеть, что было добавлено, удалено, изменено и перемещено на отдельных диаграммах. Большой недостаток: базовые пакеты не обозначаются специальными значками в браузере проекта, как пакеты с контролем версий.

Модель развертывания с отдельными файлами.EAP и внешним управлением версиями дает людям возможность импортировать разные пакеты и разные версии этих пакетов в свои проекты EA. В модели СУБД есть только один проект EA, поэтому все всегда видят одни и те же версии одних и тех же пакетов.

Да, для СУБД вам необходимо настроить пользователей и реализовать план резервного копирования. Но вам нужны резервные копии и для SVN-репозиториев, и для отдельных файлов.EAP членов команды.

Управление пользователями в EA на СУБД - двухэтапный процесс. Каждому пользователю необходим доступ для чтения / записи к базе данных, и каждому человеку также нужна отдельная учетная запись в проекте EA. Их можно легко создать, импортировав из домена Windows.

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

Моя рекомендация для настройки команды всегда - СУБД + безопасность пользователя + базовые показатели. Он дает вам единое местоположение для артефактов советника, и все всегда видят одно и то же.

Источник

Я согласен, у меня такая же настройка и среда.

В моих документах есть фрагмент кода из сети Интернет. извините, у меня нет источника. Но здорово найти все базовые линии в корневой модели или в проекте:

Поиск всех базовых показателей в СУБД STRG+F открывает Поиск моделей. Параметры -> Управление поисками -> Создать новый поиск -> Имя "Найти все базовые показатели" -> Тип редактора SQL-редактор. Вставьте это:

SELECT t_package.ea_guid AS CLASSGUID, t_document.ElementType AS CLASSTYPE, t_package.Package_ID as ID, t_package.Name, t_package.Notes as PackageNotes, t_document.Notes as BaselineComments 
FROM t_document INNER JOIN t_package ON t_document.ElementID = t_package.ea_guid

Теперь у вас есть новый поиск с именем (Find all Baselines), который очень удобен!

Источник

В настоящее время я смотрю на ту же проблему, и я нашел, что они полезны:

Развертывание Enterprise Architect http://www.sparxsystems.com/downloads/whitepapers/EA_Deployment.pdf

Рекомендации по управлению версиями для Enterprise Architect http://www.sparxsystems.com/WhitePapers/Version_Control.pdf

[Обновить]

Наша команда выбрала маршрут контроля версий после нескольких месяцев рассмотрения и тестирования нашего сценария.

Каждый проект Enterprise Architect нуждается в собственной базе данных. Это означает, что если у вас есть 5 проектов, вам нужно 5 баз данных, по одной для каждой команды. В масштабе 50 проектов или систем у нас есть 50 баз данных для работы, управления и т. Д.

Наш подход был:

  • Каждый проект имеет свою собственную папку внутри контроля версий;
  • Многоразовая служба активов (RAS) для совместного использования моделей архитектуры;
  • Безопасность осуществляется с помощью команд контроля версий;
  • Модели делятся с помощью импорта / экспорта (не забудьте включить экспорт изображений!)

Что нужно улучшить:

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

Источник

Еще одно соображение по настройке СУБД - это производительность советника при работе с хранилищем из удаленного местоположения. EA не оптимизирован для удаленного подключения к своей проектной БД (EAP или СУБД), и медленное подключение может позволить вам ждать целую вечность во время ваших изменений.

Источник
Другие вопросы по тегам