DBMS central repository usage for Version Control

[arcozen]

Hi everybody,
I'm reading documentation about different ways to deploy EA.
In "Deployment od Enterprise Architect" guide, DBMS repository is described as "Robust, Secure, High Volume usage".
A central repository make possible to have a "real time" view of all changes made by different users into the same model.

Version Control applied to this scenario seems to be useful only to permit a lock mechanism, avoiding concurrency of different users on the same package.

So we're trying to use only DBMS central repository for every other Version Control needs, as:
- Merge between Headline of a model and a previous release version
- Work on different versions of the same model into the same EA project

but at the moment we haven't found yet a simple way to work with different releases and merge them using DBMS repository (with no VC external support):

- if we make a global "baseline" of the model starting from its root, then we can't merge the baseline with live model difference-by-difference: in fact Diff/Merge EA tool seems to apply changes in the baseline to the entire model.

- Baseline seems not to be "read only", while we would use a EA baseline to freeze a snapshot of the model and make it globally unmodifiable.

So we would ask if there are best practices and/or suggestions to merge baselines with live models with no VC external support, starting from a global baseline of the model (i.e. not using baselines for single packages).

If these limitations we experienced are confirmed, which are the other benefits to use DMBS deployment of EA, instead of other deployment solutions?

Thanks in advance

Marco

[Geert Bellekens]

Marco,

Version Control is useful for ... wel version control... in any deployment scheme.
It allows you compare and revert back to a previous version if needed.
If you only need the locking mechanism you don't need VC, you can just use the built-in security feature.

Now it is true that EA doesn't really help you in working with different branches.
The first recommandation is: don't use branches, avoid them at all cost.

But if you are certain that there is no other option then to branch, then you probably better create a new model, and load that with a specific (tagged)  version based on the VC files.

Merging two branches will be a PITA, no matter wich scheme you use.

As for the benefits of using a real database i.s.o. eap (MS-Access) file, think backup, scalability, maintainability (only one source of the model, not a bunch of eap files scattered all over)

Geert

[Oliver F.]

Good point of time to unlurk a bit despite work load and give a few comments on this

Basically I second what Geert says about branching. The primary statement here is: Branching kills (as well as multitasking does, but- different issue).

However I acknowledge that historical reasons and long time support contracts (as well as customer and management attitudes) often contradict any attempts to get rid of this branching thing.

So we're trying to use only DBMS central repository for every other Version Control needs, as:
- Merge between Headline of a model and a previous release version
- Work on different versions of the same model into the same EA project

Note that a EA project (be it local, shared or as DBMS) only holds one single instance of a project. You can see the DBMS as a VC repository in which you check in and out information from your VC or baselines.
Usually this is the latest (HEAD) branch.
Important warning: If you check out information from a previous baseline (no VC involved) into a shared repository you overwrite what is currently in it. If you check out previous version data from a VC, people will get confused as there is no sign of evidence which version actually is reflected by a package. Remember? You have a shared model.

The way to work here is as follows (best practice- If I am talking about "best practice" it means the least distracting way to deal with the branching issue- there is no "best" one): The DBMS holds the HEAD branch on which is worked on and on which baselines are drawn.
Whoever is working with previous versions checks out the baseline (from EA or VC) in a separate (=local) EA project (thus holding the old branch), modifies it and sets up a new baseline which can afterwards be reimported into EA and carefully merged with the tools provided.
If the changes of a previous version do have to be merged into more versions/branches/etc. then this has to be repeated for all target versions.
Eg. you want to modify version 1 into 1.1, but would like the changes appear also in version 2 (making it 2.1), 3 (->3.1) and HEAD, then you would have to checkout 1, 2 and 3 each in a local project and apply the merge from the 1.1 baseline and apply it also to the (DBMS) HEAD.

As you can see the scheme is cumbersome and error prone but if you really insist on branching, this is the way to go.

I hope this helps.

Oliver

[arcozen]

Geert, Oliver
Thanks a lot for your replies.
You're helping us to undertstand how we can use EA in our software developement life cycle, so every explanation is very appreciated

Marco