Author Topic: Version control advice  (Read 583 times)

ty.newton

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Version control advice
« on: February 21, 2019, 09:12:24 am »
Hi,
I am investigating implementing version control in Sparx 13.0.1309 and would appreciate some advice from anyone who has implemented version control.  I have a centralised installation in Microsoft SQL with many users connected by a high speed network.  My organisation uses Microsoft TFS for version control. 

I am wondering about a few things that I didn't notice in the documentation:
1. When a package is checked out and is being modified are the modification only visible to the person who checked it out?  For example I checkout and start amending the diagrams contained within; architect B opens the package.  Do they see the unmodified package diagrams or the partially amended ones?
This question seems to be a duplicate of https://www.sparxsystems.com/forums/smf/index.php/topic,42346.0.html  The implied answer is everyone sees the modified diagrams.  Is this really the case?   ???

2. Without version control, any architect can create a new package in my model.  With version control enabled is this still the case?  And can any architect set a package as being "under" version control?  I'm thinking about a self service workflow for the architects here.

3. Ideally I would like to have packages version controlled.  However, I would also like to have common objects that are reused in my model: the building blocks that packages rely on.  Are there any problems with a diagram in a version controlled package referring to an object that is in another package (that is also version controlled)?  I'm thinking of a common package that holds objects I want architects to re-use, they have their own packages containing diagrams the refer to the common package.  It seems that this will create a point of serialisation since whenever a re-usable object needs to be created/amended the package needs to be checked out.

I think there is an alternative to version control integration: duplicating packages + locking with security controls + baselining.  This feels more complicated to me but is your experience that it is a better (more robust/reliable/effective) approach?

Thanks
Ty
« Last Edit: February 21, 2019, 11:08:56 am by ty.newton »

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 9533
  • Karma: +274/-27
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Version control advice
« Reply #1 on: February 21, 2019, 03:04:12 pm »
Hi,
I am investigating implementing version control in Sparx 13.0.1309 and would appreciate some advice from anyone who has implemented version control.  I have a centralised installation in Microsoft SQL with many users connected by a high speed network.  My organisation uses Microsoft TFS for version control. 

I am wondering about a few things that I didn't notice in the documentation:
1. When a package is checked out and is being modified are the modification only visible to the person who checked it out?  For example I checkout and start amending the diagrams contained within; architect B opens the package.  Do they see the unmodified package diagrams or the partially amended ones?
This question seems to be a duplicate of https://www.sparxsystems.com/forums/smf/index.php/topic,42346.0.html  The implied answer is everyone sees the modified diagrams.  Is this really the case?   ???
Yes, exactly the same as without version control
Quote
2. Without version control, any architect can create a new package in my model.  With version control enabled is this still the case?  And can any architect set a package as being "under" version control?  I'm thinking about a self service workflow for the architects here.
Yes, if you give them the appropriate rights on both EA as TFS
Quote
3. Ideally I would like to have packages version controlled.  However, I would also like to have common objects that are reused in my model: the building blocks that packages rely on.  Are there any problems with a diagram in a version controlled package referring to an object that is in another package (that is also version controlled)?  I'm thinking of a common package that holds objects I want architects to re-use, they have their own packages containing diagrams the refer to the common package.  It seems that this will create a point of serialisation since whenever a re-usable object needs to be created/amended the package needs to be checked out.
Adding version control doesn't really change anything in this regard. Yes, if someone wants to change any of the "shared" elements they will need to check them out.
Quote
I think there is an alternative to version control integration: duplicating packages + locking with security controls + baselining.  This feels more complicated to me but is your experience that it is a better (more robust/reliable/effective) approach?
Duplicating packages is certainly not a good idea, and baselines are completely at hoc, so you can't trust those to keep a history of changes.

We are using SQL Server databases with TFS version control and in general this works just fine in most cases. We don't necessarily version control everything though, so we use the regular security locking as well. That sometimes creates some confusion for the less experienced users as you now have a double mechanism to be able to write in a package. You need both the security lock as the checkout.
 
Just don't think because you have version control, you can do merging; because you can't. Merging cannot be done in models (without massive overhead)

Geert

qwerty

  • EA Guru
  • *****
  • Posts: 10622
  • Karma: +233/-194
  • I'm no guru at all
    • View Profile
Re: Version control advice
« Reply #2 on: February 21, 2019, 07:16:52 pm »
Just a #MeToo. I support each of Geert's statements. Especially and with many exclamation marks the last one!

q.

Arquesoft

  • EA User
  • **
  • Posts: 258
  • Karma: +5/-3
  • EA Consulting and development in Spanish
    • View Profile
    • Arquesoft website
Re: Version control advice
« Reply #3 on: February 22, 2019, 06:19:27 am »
In my experience, version controlled packages are not a good idea, because you loose the ability to modify elements within the same controlled package. When you version-control a package, only the user that checked out can edit. Depending on the size of the controlled package, this could cause idle time in the people waiting for the package to be checked in again in order to edit. Editing elements became serialized from the users view-point.

I prefer to make baselines periodically and we created a tool in order to ensure the baselines are created every week (for example, every friday at 5pm). In this way, all users can work in the same package and the baselines are automatically made.

If something weird happens with your model, you can view previous baselines and recover the lost data (this is the reason we use baselines). Avoid thinking in branching and all stuff that normally a version control software provides. I think this is an approach not recommended in EA.

ty.newton

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: Version control advice
« Reply #4 on: February 22, 2019, 07:11:04 am »
Thanks for the advice. 

The functionality in this area is disappointing.  I think I'll have to rethink our workflow to see if there's a way to work within the limitations.

Helmut Ortmann

  • EA User
  • **
  • Posts: 937
  • Karma: +39/-1
    • View Profile
Re: Version control advice
« Reply #5 on: February 23, 2019, 05:04:30 pm »
Hello,

if I want a professional solution with Version Control which supports Parallel Development and all major processes like SPICE/CMMI I use EA together with LemonTree as a Merge tool.

Working with models is then similar to working with Code. The typical steps are:
- Create a branch with your Version Control tool
- Work on your branch (Check-In, Check-Out)
- Merge with LemonTree

In most cases, the Merge is done by LemonTree without any conflicts.

The pros are:
- Parallel Development
- Easy integration with Change Request and Version Control
- Working with models as you may be familiar with the code

the cons are:
- You have to buy LemonTree
- Sometimes, in praxis rarely you have to cope with conflicts if two people change the same model element
- You have to get accustomed to

One of the beauties is that can see what changes are in which branch.

Best regards,

Helmut
Coaching, Training, Workshop (Addins: hoTools, Search&Replace, LineStyle)

Arquesoft

  • EA User
  • **
  • Posts: 258
  • Karma: +5/-3
  • EA Consulting and development in Spanish
    • View Profile
    • Arquesoft website
Re: Version control advice
« Reply #6 on: February 26, 2019, 12:53:10 am »
But LemonTree only works with EAP files. What if you have a database based repository?