Centralized repository in DBMS or SVN

Question

I am working on setting up a centralized repository to store enterprise architect (from sparx systems) generated artifacts for the team of 6-8 people to use. Initially thought of hosting a PostgreSQL database to store the artifacts centrally and the other option that came up was to use SVN. Looking at the EA documentation, not getting a clear idea on what are the pros and cons for the options in consideration. As compared to using SVN I have the following overheads while using a DBMS.

1. Hosting and managing DBMS
2. User provisioning and management for DBMS
3. Artifact Versioning need to done separately
4. Backup etc for the DBMS

For SVN, from EA documents it is mentioned that the deployment model is suited for a team of maximum size 10 only and there is a possibility of files getting corrupted. Other than these are any bottlenecks in using SVN to host the repository ? It would be great to hear suggestions from folks who has worked with Enterprise architect in multi-user environment.

Answer 1

The "maximum 10 people" warning refers to a situation where you have a team sharing a single .EAP file. It does not apply if all users have their own .EAP file, nor if you set up a DBMS repository.

In a DBMS setup, I recommend using EA's baselines for version management, not an external version control repository. The concept is similar: individual packages are baselined, but instead of storing the versions externally in SVN/CVS/etc, they are stored internally in the database.

This gives you one less repository to manage, but it should also be noted that EA has issues when combining DBMS with external version control which can be annoying or even (worst case) cause information loss. External version control is intended for use with .EAP files.

Baselines have one big advantage over external version control: you can compare different versions visually inside EA and see what's been added, deleted, changed and moved in individual diagrams. The big disadvantage: baselined packages aren't indicated with special icons in the project browser the way version-controlled packages are.

The deployment model with individual .EAP files and external version control gives people the option of importing different packages, and different versions of those packages, into their EA projects. With the DBMS model there is only one EA project, so everyone always sees the same versions of the same packages.

Yes, with a DBMS you need to set up users and implement a backup plan. But you need backups for SVN repositories too, and for the team members' individual .EAP files.

User management in EA on DBMS is a two-step process. Each user needs read/write access to the database, and each person also needs a separate account in the EA project. These can be easily created by importing from the Windows domain.

This is assuming you switch on user security in the project, which you most definitely want to do in order to prevent concurrent-editing problems.

My recommendation for a team setup is always DBMS + user security + baselines. It gives you a single location for the EA artifacts, and everyone is always seeing the same thing.

Answer 2

I agree, i have the same setup and environment.

I have in my documents a code-snippet from the i-net. sorry i havent the source. But it's great to find all baselines in a root model or in a project:

Find all Baselines in the DBMS STRG+F opens Model Search. Options --> Manage Searches --> Create new Search --> Name “Find all Baselines” --> Editor Type SQL-Editor. Paste this:

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

Now you have a new search named (Find all Baselines), which is very comfortable!

Answer 3

Currently I am looking at the same issue and I found these to be helpful:

Deployment of Enterprise Architect http://www.sparxsystems.com/downloads/whitepapers/EA_Deployment.pdf

Version Control Best Practices for Enterprise Architect http://www.sparxsystems.com/WhitePapers/Version_Control.pdf

[Update]

Our team decided the Version Control route, after months of consideration and testing for our scenario.

Each Enterprise Architect project needs its own database. That means if you have 5 projects, you need 5 databases, one for each team. Scale that to 50 projects or systems, we have 50 databases to work with, manage, etc.

Our approach was:

• Each project has its own folder inside Version Control;
• Reusable Asset Service (RAS) for sharing architecture models;
• Security is done with version control teams;
• Models are shared using import/export (remember to turn on image export!)

What needs to be improved:

We would like the contractors to be able to access these models using the "cloud", but there are security concerns that we need to address first.

Answer 4

There is one more consideration for DBMS setup, and that's the EA performance when working with the repository from a remote location. EA is not optimized for remote connection to its project DB (either EAP or DBMS) and slow connection may let you waiting for ages during your edits.