Development on parallel branches with EA

[svenfx]

Hello everyone,

in my company, we have a development workflow which includes several branches (branch in terms of svn, not with the special meaning in EA).

I am unsure how to implement such workflow with EA.

Right now, we have a eap file in svn which every developer checks out and which is updated and committed only on rare occasions (e.g. when new packages are added).

In the model, we have packages under version control. We check packages in and out inside EA.

The model as it is is quite suitable for the mainline development we do.

Then again when we create a branch (in terms of svn) and the software development goes down a different way down the branch than on the mainline, what then?

We create the branch in svn, the branch contains a copy of the eap file and its associated package xml files. We open the eap file from the branch, and the version control settings in there still point to the mainline svn. If I am not mistaken, the version control settings are global. And with them the path to the package xml files.

So my question is, when I take a step back, what is the suitable means to do it our way with EA?

Will baselines do?
Will replica do?
Is there anything else?

Do any documents exist on this topic?

I have EA 7 here, by the way.

I'd really appreciate any professional advice whether or not any good, established practice exists. Thank you very much.

Sven

[qwerty]

http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1393332646/0#1

q.

[Helmut Ortmann]

Hello,

it works with SVN. Some time ago I tried it. Be aware: Merging repositories isn't fun. I hope I remember right.

Assign the EA UniqueID (Project, Version Control, Version Control Settings) to the SVN Branch (Working Copy Path in EA). Then make a Get All Latest.

Check if all packages are checked in.

Helmut

[Dermot]

Have a look at Baselines - "Load Other Baselines". You can create a copy of the Source as a Branch repository then merge packages  with updates between the repositories using "Load Other Baselines".

[Ian Mitchell]

I have a customer with the same issue.
Large shared model, with users working on some parts of it, but the changes don't get committed to the Shared model until the change is implemented, which may be many months later, once testing is complete.
BUT, all users need to see that the change MIGHT happen, so they can check if they are affected.
So I don't think baselining of the shared model would be practical: users need to see the 'trunk' and the 'branch'(s), so both EA baselines would need to be in the model at the same time, which isn't how baselines work ?

 We're proposing that the 'branch' elements are cloned from the trunk, and connected back to their trunk elements via an EA Connector. Then users of the trunk version can see that there are potential changes, by following the link to the branch.
 ..but all this has to be done manually: the initial  'clone' is hard, as the 'copy element' doesn't work reliably (issue reported for v11 Beta1), but that is as nothing compared to how hard it is to do a 'Merge'.

I seem to keep coming across this same issue in every client recently: they want to see the trunk and the in-progress branches, and this is the least-worst solution I can come up with.

I'm SURE someone has solved this in a more elegant way?

[Helmut Ortmann]

Hi,

I agree: I don't see a general way to efficiently support branching in modeling. In source code it's easy. There are powerful dif and merge tools.

Models are sophisticated: So it's no easy task. Maybe tool developer will help us in future.

My own solutions are:
- Avoid such scenarios
- Find a workaround for the special circumstances
  e.g. Make a diff tool to show the for me important differences

For DSLs like DDL it's quiete easy. You may have to add some text to the ddl to make a reasonable diff.

The general approach is more difficult.

From the domain of Matlab I know that there are some diff tools. They are not cheap and don't met everyones requirements.

This discussion isn't new and I don't know any good solution.

I'm interested to discuss/learn approaches to solve this dilemma.

Thanks for your time,

Helmut

[Dermot]

The Baseline Difference and Merge feature is an equivalent 'Diff tool' in EA.
Given you can use it to Difference across copied repositories - Source and Branch (using Load Other Baselines)  - it does form the foundation for Differencing and Merging 'Branch' repositories.
Sure the Branch is in a different repository - the dfference-view allows you to view changes, but keeps these seperate until verified and merged.

[rothnic]

I have a customer with the same issue.
Large shared model, with users working on some parts of it, but the changes don't get committed to the Shared model until the change is implemented, which may be many months later, once testing is complete.
BUT, all users need to see that the change MIGHT happen, so they can check if they are affected.
So I don't think baselining of the shared model would be practical: users need to see the 'trunk' and the 'branch'(s), so both EA baselines would need to be in the model at the same time, which isn't how baselines work ?

 We're proposing that the 'branch' elements are cloned from the trunk, and connected back to their trunk elements via an EA Connector. Then users of the trunk version can see that there are potential changes, by following the link to the branch.
 ..but all this has to be done manually: the initial  'clone' is hard, as the 'copy element' doesn't work reliably (issue reported for v11 Beta1), but that is as nothing compared to how hard it is to do a 'Merge'.

I seem to keep coming across this same issue in every client recently: they want to see the trunk and the in-progress branches, and this is the least-worst solution I can come up with.

I'm SURE someone has solved this in a more elegant way?

That is an interesting concept. It seems like it might be difficult to deal with in practice. You would be making the trunk aware of past and future changes through links.

A less complicated but less granular concept would be to manage your baseline as a standalone model. In that you create a concept of your "change packages" or whatever they would be called. This parent model is the model of the models. Use artifact concepts or something link that with some pointer to a branch that was created to develop the change.

It is the responsibility of some person (who should be identified in the identified baseline model) to merge any new baseline changes from the trunk into the potential change package. Then whenever you are ready to implement the change, you merge the branch back into the trunk.

[Ian Mitchell]

After much thought, we've decided that the least-worst way is to sub-class the Component, Interface etc elements, and put tagged-values of the new elements to show when they are proposed to be implemented.
Not elegant, but we'll see how this scales.
I'm still interested to hear about better approaches!

[qwerty]

Why don't you use the Status for that?

q.

[Ian Mitchell]

For what?

[qwerty]

put tagged-values of the new elements to show when they are proposed to be implemented.

q.

[Ian Mitchell]

Ah - I see.
But I'd like to work towards a 'time aware' EA, where elements have tagged values which point to 'time' elements, which understand that, for example, January 2015 is part of Q1 2015, which is part of 2015 etc. Then, we might imagine getting some future Add-in to create time-aware diagrams, views, reports etc.
Does anyone think this would be useful? One for the TOGAF-types perhaps?