Messages

1

General Board / Re: Evaluating a manual version control scheme

« on: December 05, 2020, 09:32:47 am »

I think it is important to distinguish between version control, (change) auditing, reusable assets - such as patterns - and documentary baselines.

As both qwerty and Paolo have explain, models and, in particular, enterprise models are not best suited for version control. At best, version control gives you a fall-back position in case something happens to the repository.

Auditing changes, something Sparx is also capable of doing, is not the same as version control. With auditing enable, it should be possible to track every single change in the model. Unfortunately, there are some deficiencies with Sparx auditing capabilities that should really be addressed by Sparx Systems; the most serious of them is that Sparx does not/did not audit relationship changes.

Needless to say that reusable assets should go through a governance process and only approved assets should be published to the registry. RAS is an efficient way to reuse and version control them, but I wish it was easier to configure. The pre-requisites to create a cloud store.

Documentary baselines could be treated as reusable assets but they could also be stored in the document library.

In short, it depends on what you are trying to do: audit changes, re-use patterns or have a document library.

P.S.: I would not recommend any of the above to track how an enterprise architecture evolves over time.

This comment definitely gives me a lot to think about, I certainly appreciate the questioning of the fundamentals behind the question. I would probably say that what we want to get out of this is:

• Auditing, definitely. In that we want the ability to see the history of changes, and revert them if necessary. I understand that this is less practical with the complex structures of some models
• The ability to take a design at a point in time a branch off from it. Then the branched version may or may not make its way back to the original design
• Not just re-using assets, but being able to link them to their attributes, even if those attributes change. It sounds like I may need to check out RAS, which I don't know too much about yet for this one.

I also have to ask, what exactly do you mean by "tracking enterprise architecture evolution over time"? And what would you recommend for tracking that evolution?

2

General Board / Re: Evaluating a manual version control scheme

« on: December 05, 2020, 09:18:18 am »

Can an EA repository be split up and still maintain references? Yes
Will this be easy and lead to a useful result? Maybe

What you can do is add your model to version control. If we put a part of the model in version control, we control each and every package.

Then if you want to isolate a part of your model, say "PackageA", you'll can load that into a separate repository.
Then you have to figure out all of the direct dependencies from PackageA, and make sure you load those as well.

Now you have a repository for editing PackageA, without the risk of loosing relations to elements outside of package A
The trick is to make sure you only ever check out PackageA in this repository, since that is the only one guaranteed to be complete.
If you would checkout any of the dependencies outside of packageA you risk loosing relations.

I have some clients where a variation of this scheme is used, but you have to be very careful to not mess it up.

You might want to look into RAS as wel. I've never used it myself, but apparently that tool has a way to automatically detect dependencies.

If Uffe reads this post he'll surely be able to add some more insights about RAS

Geert

I tried out using the VC integration after I read your comment. I must say that it does seem quite streamlined. The unfortunate issue I have is that I am working with an existing (and well established) version control system using Perforce, which has deprecated support for its EA plugin. Do you know if there is any way to use a similar system in EA that does not require linking to an existing VCS? That way I could use the EAB files and branch XMI structure with my existing VCS.

I'll have to check out RAS as well, that is still a blind spot for me.

3

General Board / Re: Evaluating a manual version control scheme

« on: December 05, 2020, 09:09:39 am »

Hi,

I have been using EA for over 10 years and have NEVER used version control!  It is my contention that a model Repository is NOT a suitable "Universe of Discourse" for version control.  Instead, we use snapshot backups to help recover from failures and other issues.

That's NOT to say we don't use controlled packages.  We use them to transfer metadata between related repositories, but we DON'T use them for version control.

That said, I'm talking about enterprise-wide repositories (with many users), it sounds like that's not your use case.  However, you've already noted some of the reasons why a model repository isn't coding and doesn't behave like code and so can't really be version controlled like code.

Sorry if that puts a damper on your plan.
Paolo

[Edit:  I see qwerty beat me by 20secs on the first publish]

One of the other requirements that I need to meet is that there needs to be branching and merging of the design. I'll admit I'm not very familiar with database management. Is is practical to do this sort of management, perhaps using the snapshot backups?

Just to clarify, do you mean that you use Controlled Packages so that parts of a design can be reused?

And you are correct, the intention is that the designs have a similar workflow process to existing code, but maybe that isn't practical. Ultimately I just want to figure out what will work for us, and plans are certainly changeable!

4

General Board / Evaluating a manual version control scheme

« on: December 04, 2020, 08:45:58 am »

I am currently evaluating using version control, specifically Perforce, to control changes to EA projects. I have been using LemonTree for diff and merge functionality. The question I'm trying to answer is: can an EA project be broken up into smaller modules that will maintain links between elements? I don't want to store everything in the design as a single eapx file

I have tried using Controlled Packages to export separate packages and sub packages to XMI files, which I can then version control and import into a local copy of the design project file to get any changes. The issue is that I cannot check out and change a single sub-package, as all of the XMI files up to the project root need to be updated as well. It also makes LemonTree comparisons more difficult. Is there a way to do create similar split-up files that contain references to other files so that entire hierarchies don't need to be exported for every change?