Automated project transfer

[Boron]

Hello,
I often need to make baselines of our project models. Our models are stored in a SQL database. We have about 10 different model ().
We don't use the EA baselining mechanism as we want eap files to be checked in our version control system.
Therefore we make a "project transfer" (DBMS to .EAP) for each single model in the database. This is very time consuming and prone to erros (e.g. selected model X for the transfer when you meant Y).

Is there a way to automated this? Maybe via the automation interface?
Thanks for any idea?

[qwerty]

We use a similar approach but not by checking in EAP. We export the whole model (via automation) to large XMIs which are checked in. Additionally we use the audit log to check for the necessity of a checkin.

q.

[Geert Bellekens]

I think q.'s approach is a better idea.
Even better yet is to use version control integration.

Geert

[Boron]

A year ago we switched from checking in the XMIs to EAP files because our UML profile is not part of the XMI.
So when someone wanted so see the model he imported the XMI into an empty model and all diagrams looked not the way we are used to, because in our UML profile we have many customized elements with own shape scripts.
An EAP file is much more comfortable. Everything is in it. Even in ten years!

[qwerty]

Maybe, Geert. But our reason to do it this way was because in our setup the VC way did simply not work and we had a lot of trouble. So we favour this variant.

I might elaborate that if someone's interested...

q.

[MagnusH]

We do the project transfer using the automation interface. Look at ProjectTransfer in the project interface. (Was introduced in version 9)

q. Please elaborate because we have a lot of users asking why we don't use version control integration.

BR
Magnus

[qwerty]

So here's the story.

In the beginning we started with a plain MySQL repository. The only "security" was the ODBC connector which needed a user/password to be configured. That worked for quite a time with just a few modellers working mostly in different parts of the model(s). Until one day some work of one modeller was lost due to unknown reasons. Luckily it was only some hours work, but it was a signal.

Back to the very past: In a different model/part of the company we worked on a shared model (MS SQL) with VC packages. This was horrible for two reasons. The first was the checking out/in took quite some time for packages and (the worse part) dead-locked people in their work. Of course you could avoid that by better cutting a project but that had not been done (it wasn't me!). But the even worse part was that some people used Get ALL Latest which regularly clobbered the whole repository. So I had this in mind.

Back to the future: Having had the bad experience with VC on a central repository we decided to use local EAPs for single modelers. This from our new perspective seemed to have the advantage that each modeller could branch, develop independently and merge back when done. Now, we didn't go with branching in the beginning but just with VC on the main branch. This proofed to be "sub-optimal". First the Get Lastest did not work (no idea whether this was du to our very old ClearCase 2003 installation) and you had to update your view manually befor issueing Get Latest. The second it proofed that even after a Get Latest diagrams were not loaded correctly. Parts were missing especially when we had cross package dependencies.

Now we stepped into a real mess. That was when we decided to use branch and merge. Branching seemed to be fine and modellers could set up their models with no pain - except it took half an hour or so to build the model. And special care had to be taken for the reference data (images). Then local modelling was fine. --- But modelling is nothing you do in your chamber. --- You need to merge your results. And that was a real pain. It definitely took at least a day to merge results. And you never were sure that everything was transferred. I can't tell you what we suffered these days.

So we made a cut. We moved back to our central MySQL, enabled security and turned on Require Lock to Edit. That (up to now) seemes to be the right way to go (except for this). Concurrent work is possible and modelers can see other modeler's work at once. This way communication between modelers is extremely enhanced. Also we are able to have sanity checks via automation, backup via automation and reference data backup also via automation. The only draw back is the user administration which has to done for each repository separately. But we'll work on automation support for that too.

So that's the story in short. It always depends on your requirements which kind of repository configuration you need. Finding out the right way can be painfull. And you might be forced to try different directions.

q.

[MagnusH]

Thanks for you answer.

We have not have the history that you have but started with the central repository with required locks directly and that has worked fairly well at least from a stability point of view.

Our issue is that we have a very distributed organization in Europe/Asia (in total ~8 sites with ~450 potential users). In order to get the remote sites to work we have a Citrix server for that purpose (used also for Linux users). This solution is not a responsive (in terms of graphical user experience) as running EA natively and we're are evaluating different approach to avoid this.

Besides the alternatives that you mention we have stated with an approach that we use the central repository we have to today but allow people to create a snapshot (project transfer to EAP file) after the have locked the node tree they want to edit. Then they can continue to work locally and when ready they do an XMI export from the EAP file and after that an XMI import into the central repository. This way we allowe local editing but avoid the merge problem.

Do you see any problems with such approach? (Except the reference data..)

BR
Magnus

[qwerty]

Well, it depends. There are not too many alternatives and what you're doing would be just what I would do. Merging externally developed branches is very challenging. For a short time I tried the build in merge tool but with not much luck. I simply compared a completely merged branch with the file I imported from - and EA showed quite a number of differences. Although the differences were just "not important" it made me feel uneasy. I simply do not trust this merge algorithm. So what we do in similar cases is to replace a whole branch by re-importing. There's still that bad feeling in the stomach with the experience we had. Basically it's the same what is happening under the hood when you use VC (that is replacing branches from XMI files). So we avoid it where possible.

In your case there is not much choice. I guess database replication will not work as well. The only thing which helps is a good cut of your model. I think the r/o r/w approach we use is useful. That helps to see parts of different modellers (just with some time lag) while being able to develop locally some branches which in turn get mirrored later to the remote modellers.

However your view it: you have no optimal solution. EA is quite nice for local teams (if you avoid the pitfalls) but it's not really ready for worldwide enterprises. To get that working seamlessly it would take a lot of additional effort from Sparx and most likely the price for such a tool would be ten or more times of the current.

q.