Shared project in a team - better strategies

[vaeVictis]

Hello everybody,

I am a new member of this nice community. It seems very well organized

I started using EA 15.2 recently in the context of a corporate.

Currently, the way of working with EA consists of some workarounds.
There is already the overhead of passing around a package of UML diagrams and maintaining it.

I was sure EA could handle the scenario and made some searches in this forum, in the documentation and in the information hub.
There are many indeed, for example there is this page for EA 15.2 Sharing File Based Projects

My problem is that I do not understand which could be the solution for my scenario.
We have cloud services, we have sharepoint, other similar utilities as well.

How do you suggest proceeding?
(Please, I understand this question could seem like I do want to skip my homework. This is not the case though. I simply would like to understand how to address my searches about this topic becasue I am currently stuck)

Thanks, in advance.

[qwerty]

There is no general rule you can apply. Each solution has pros and cons. You can use a common database (SQL Server, MySQL, etc) with locking. You can have distributed EAP (or the like) which get merged centrally. Or you can have XML exports with version control. It very much depends on the requirements and settings of the project. The best proposal would be to hier a consultant with enough experience to aid with a setup. It's not like "Ah, yes, take thise and you're done" but needs thorough investigation. Going on with trial and error will only leave you (and the whole project) with grief.

q.

[vaeVictis]

Thanks for your answer.
We are completely on the same page, and it is the reason I opened this thread.

Requirements are pretty basic.
We are a team of less than 10 people.
There is one package which contains all the diagrams.
We need the capability to work on that package concurrently and have the package updated in real time.

There is no need to have local copies, we can save the master in a shared drive since I see that it could be locked. I also read that with a different strategy you can concurrently modify and see each other's update simply refreshing a view button.
Whether there would be need to have local copies, I already read there could be several solutions.

I could ask for a professional, that is possible.
Nevertheless, I have a mind and I would like to understand what happens under the wood myself.
I usually do this in similar context, and I think it is the only way to get confident with the software you are using daily.

Thanks again
I will update with the progresses.

[qwerty]

First choice (as it seesm) is a common SQL server (anything except Oracle). Shared file is VERY limited and EAP (aka M$Access) is not designed for shared work over a network. You can get it to work but it's often like walking in a minefield.

q.

[Geert Bellekens]

A agree. Go for a central database approach.
The setup is quite simple, create a database, run the setup script that creates the table, and transfer your project to the SQL Server.

Most used (from my point of view) is SQL Server, but I guess the others are fine as well of you are already familiar with one of those.

Only Oracle should be avoided. For some reason using this database ends up having terrible performance.

You might want to look into the security feature, using the "require user lock to edit" in order to somehow manage the multiple users working on the same stuff.

Geert

[jcampos]

Hi,

I agree, its necessary to get the repository in a common database by a cloud connection. Also you can build an own strategy to colaborate in EA.

Is desirable if you could use EA 16.1, because there are develops in those functionalities.
https://sparxsystems.com/products/ea/16.1/index.html#:~:text=Modeling%20and%20Collaborating%20in%20a%20Rapidly%20Changing%20World

I hope that works, don't doubt in contact me if you need some help.

[Richard Freggi]

A side note.  Putting all diagrams on a package seems like an awkward way of organizing your project.  Diagrams are just windows into the model, what your team is working on is the model not the windows.  You may need to think about the package structure of your project, in my experience it's a difficult task that requires experience but it pays off big time.

[Modesto Vega]

Agree with everybody, a central database, other than Oracle, should be your starting point.

Richard has a very good point, having all diagrams in a package may not be the right way to organise your repository/project. If the team is working in multiple projects and/or applications, there are several threads in the forum covering this (one of the latest is https://sparxsystems.com/forums/smf/index.php/topic,47539.0.html).