EA Corporate Deployment question

[meshank]

Hi All

This is my first post on this forum. Please bear with me as I am new to EA.

I am planning to introduce EA into our organisation so investigating an ideal deployment option. After some initial research I have found that the following deployment may be ideal for us:

1. One Repository - Multiple Projects: My understanding is that in this deployment we will be creating a single EA Project and creating multiple root nodes for each Business Project. I think this will enable us to reuse components across projects.

2. A Central DBMS Repository: I can not understand the benefit of having this if we also use Version Control.

3. Version Control using Subversion: For security, sharing and history.

Please note that I have NOT yet set up EA this way so I am not sure how this will work. Please can you answer the following questions:

Q1. Why do we need a DBMS Repository when we can check-out files using Subversion? DBMS Repository seems to contain the same data which is also available through Subversion. Subversion maintains the master copy. Users can check-out to create local copy and make changes to the local copy and check-in. I am very confused about the purpose of DBMS Repository.

Q2. If we use the deployment described above what will be the steps for an EA user to open the project and make changes and save changes?

Q3. How can we enable security such that a user can only modify contents of the project he / she is working on.

Q4. Upto 20 users will be using EA every day. Most of them will be on local network. All of us work on more than one project at any time and we wish to encourage sharing on contents across projects. Please can you suggest if any other type of deployment will be suitable?

[Oliver F.]

I would like to comment on the DBMS issue.

First of all EA lets you put packages under version control meaning you can check in/out certain packages only and let the other part live in a shared storage (eg. a DBMS) where it is accessible for everyone (maybe readonly, maybe not).

You  have the choice where you local repository is lying in- a database, a local file, a shared file, etc.

If you choose DBMS as a deployment option even under version control you can benefit from all advantages this shared DBMS model delivers compared to a local storage (depending on the setup like quicker searches, transactions, regular backups, identical setups, shared views, templates, etc.). Not everything is stored under version control, this is especially valid for reference data (again, templates, views, etc.) which has to be exported and imported to make it benefittable for everyone. In a central storage this is not an issue.

I hope that helps.

Best regards,

Oliver

[Darin P]

I have a related question:

After some preliminary testing it seems that if you are using shared storage (I'm using a shared .EAP file) and have packages in your model under version control, whenever any user checks out a package from version control the package is checked out (and modifiable) for anyone else using the shared model.

I was hoping for a deployment where the package would only be changing for the user that had it checked out until it was checked back in.

I would like to avoid putting the .EAP file itself under version control, but I'm not sure what the other options would be. We want to have some of the individual packages under separate version control so that they can be shared across projects. Putting the EAP file under version control as well seems redundant, locks everyone out of the entire project while someone is making changes, and uses more storage space.

I also thought about having each user have their own local/private project file and just import the root of the model, which could be under version control. Seems like it would work. The only thing I didn't like about that option is that there isn't a centrally located EAP file that a non-developer could view (e.g. using EA Lite). We would have to manually save one somewhere periodically.

Any other thoughts? How do people deal with this?

Thanks,

Darin

[Eve]

Darin,

That's definitely not the normal behavior.  My first guess would be that all your users are using the same version control user.

Unfortunately, I don't have further guesses because this isn't my area.

[Geert Bellekens]

Darin,

If you are thinking about using EA with about 20 users then you definitely want to go with the DBMS solution.
Remember that the "shared EAP file" is in fact an Access database, and we all know what happens with Access when you have more then 10 simultanious users.
I've had this issue where all users have write access to a checked out package too about a year ago. This was due to an error in the way our version control software used the scc interface.
This issue was fixed somewhere in the 7.1 release, but there is also a workaround when you combine the EA security with version control. When you then check out a package EA will propose to lock this package as well.
I think in your first post you got a bit confused with the combination DBMS/version control. In fact, when you checkout a package you checkout the xmi file for that package. EA will then allow your user to edit this package in the central database. So even when working on this package before checking it in all other users can see the changes you made. When you do a checkin of this package EA will export the contents of the package to an xmi file and commit that file to the version control. And of course it will then make this package read-only again.
So there is actually no local editing when working with the DBMS setup.

I hope this clears things up a bit for you.

Geert

[Darin P]

Thanks for the help everyone.

There will be three developers using the same model, but I am the only one using EA right now. I'm trying to determine what our configuration should be to allow sharing between developers, have the model under version control, and also be able to share some packages between projects. My evaluation "testing" was with me as a user on two different machines. That may have affected the outcome.

For my setup I had a shared EAP file and the packages within the model were under version control. We are using the SCC interface with IBM/Rational ClearCase. What I saw was that when I checked out a package on one computer, the package also showed as checked out from the other computer, making it modifiable for both "users".

What I overlooked was that I am the same user on both machines with the same working directory in the version control system. I will have to try a more realistic test one of our other developers.