Best Practice for EAPX Replication

[Paul Vermette]

What is the proper way to replicate from a "replica" to a "master".

Current Process we are following:

Open Master and Replicate changes by pointing to replica.

If there are replication errors, the replica in question is open to resolve replication errors.

Open Master again to replicate changes from replica to master.

Is this the correct procedure we should be following?

[qwerty]

Uhm. The best practice is to not use it at all. It's just MS Access replication and you shouldn't trust it as far as you can throw it. Try controlled packages or simply XMI ex-/import of clearly separated packages. Everything else will bring you nightmares.

q.

[Geert Bellekens]

I agree with qwerty. Don't use it. It's not reliable and it will corrupt your model one time or another.

Geert

[Sunshine]

In the words of Jeff Goldblum from Jurassic Park

...were so preoccupied with whether or not they could, they didn’t stop to think if they should.

I concur with previous comments on EAPX replication. Best practice is to avoid it. As to quote from Jeff again.

Oh, yeah. Oooh, ahhh, that’s how it always starts. Then later there’s running and screaming.

Seemed funny at the time

[Paolo F Cantoni]

Hi Paul,

Are you detecting a theme here? 

Most of us who have replied have been using EA for over/about a decade.

Perhaps, if you indicated WHY you decided to attempt replication, we can help with an alternative solution.

HTH,
Paolo

[Paul Vermette]

The reason why replication was chosen is that we have multiple solution architects (six) working on a model.

Replication allowed more of a style of git, where people could be working on similar areas of the model without requiring to checkout (and hold) an area of the model.

What challenges should I be aware of we if we go w/ controlled packages/source control?

[PeterHeintz]

If your users intend to work on the same stuff in parallel, why do you not just consider having a proper SQL DB?

[qwerty]

SQL DB (not Oracle) and (require user) locking (to edit) enabled is the way to go.

q.

[Paolo F Cantoni]

Hi again, Paul.

If you look into the forum history, you'll see I eschew version control.  It is a chimera.  Repository control is NOT the same as version control.  However, many, users still use it.  Another thing we eschew is keeping diagrams with the elements - we keep them strictly separated. Again, many users still do that.

There is no problem having multiple users work on the same repository (preferably a server-based RDBMS).  Using user security and good repository structure design, you can isolate various parts of the model.

Paolo

[Sunshine]

The reason why replication was chosen is that we have multiple solution architects (six) working on a model.

Replication allowed more of a style of git, where people could be working on similar areas of the model without requiring to checkout (and hold) an area of the model.

What challenges should I be aware of we if we go w/ controlled packages/source control?

Okay that puts some prospective into it.
Yeah about that GIT model which is basically a way to shared source files providing diff and merge. That doesn't necessarily work well for a relational database. 
EAP or EAPX files are MS Access (a Relational Database) so you can have a few people editing the file (database/repository) at the same time. Some folk put these on shared drive to work on simultaneously however, depending on how the drive is shared it can either work well or not. You might be okay with six concurrent users with an EAPX file stored on a shared drive. I've done that for about 8 users at one stage. A lot of people move to using SQL Server as the repository, it takes a little more effort but works well for larger groups. At the moment I use SQL server and have up to 14 concurrent users.

You should enable security and set up user groups like beginner, intermediate and advanced to provide privileges to do certain things. Those who know Sparx EA well get advanced and those who don't get a lower level so they don't have access to things like import csv where they might overwrite everyone's work.
Also good to have regular  backups. We have daily backups.