Production/Development versions and change control

[mark.myers]

I am setting up an EA repository to, amongst other things, document and maintain Business Processes using BPMN but I have a question about change control.
Is there a way in EA to manage concurrent models/elements and their authorisation. By this I mean, for example, suppose you have ProcessA (a BusinessProcess composite element) that has 15 (or so) child elements (Activity elements) and an anlayst would like to make a change to the process (adding an extra activity, say). Is there a way to allow the analyst to make the change PENDING APPROVAL and then either
1. the approval is granted and the process becomes current
2. approval is not granted and the process remains as it was.

In effect there would need to be two versions of a model/package/element, ie production and development.
Approaches I've been thinking about are:

1. using baselines (limited to models/packages not elements though) but they are "tucked away" so if they represented the production versions then you'd need to import the package to a different location in the repository (is that possible) just to see the current process details.

2. using source control (Subversion) as in 1.

3. having a Production and a Development view in the repository and setup a mechanism to move model/packages/elements between the Views.

4. having a Production and a Development version of the entire repository (ie two SQL Server databases) and setup a mechanism to move model/packages/elements between the repositories.

In 3 & 4 Production would be readonly to all except the user responsible for moving from Development to Production.

Whatever it is the solution needs to be simple!!!

Regards,
Mark.  

[Martin Terreni]

1 - it is simple (and we use base lines) but you have to get used to work with it.
2 - If you use ClearCase (don't know about subversion) the "views" you are talking a out are native in the configuration control.
3 - 3/4 is a good idea as long as you don't mind supporting it your self (Sparx does not support direct use of the DB)

All in all I would go for 4. I think ti will be the best solution (even if it will make you work for it every now and then)

[mark.myers]

Thanks, Martin.
If it was just me then option 1 would be fine.
The end users are BA's that require it to all happen without thinking about it or learning anything new! If it's not push button simple and intuitive then it wont fly - and there needs to be minimal maintenance required!  

Regards,
Mark

[Martin Terreni]

I suggest you try option one your self.
It is not perfect, but it might be enough.

[mark.myers]

FWIW...
I think I will go with option 4 - two versions of the repository (Production & Development) both being shared models on DBMS with packages under source control (SVN) and individual workstations having a private working copy.

I will look at setting persmission on Production to not allow editing etc but only source control Gets (see below)

In effect, the SVN Repository becomes the production (approved) repository and the EA Production repository just has the latest packages loaded ready for viewing.

1. Analysts will open the EA Development repository and checkout the packages of interest to their private working copy however, as the EA Development repository is shared, other analysts can see work in progress.
2. When its approved then it gets checked back into the SVN Repository
3. The analyst then opens the EA Production repository and does a GetLatest (or GetPackage if its new)

I may automate Steps 2&3 in an AddIn.

Sound reasonable?

[Martin Terreni]

sounds good. but for some reason it sounds more tricky then you wrote... :-/

Let me see:
You will have 2 DBMSs each with ts own controlled packages? or are the underlying packages share between them?

[thomaskilian]

Absolutely. I would recommend to have a Release Package in the model to track "hand written" model changes between the single releases.

For the check-in procedure I'd like that EA would support simple XMI storage of the model (with stubs!) and to use Tortoise for the check-in stuff. So I could check in multiple packages with one commit - plus: I could see in the markers which packages have really changed. As the stub-saving is not supported, I have to use the version control inside EA.

[mark.myers]

Martin, its just the way of things...an idea starts out simple and then the implementation get complicated!

Thomas, yes I would love to use controlled packages rather than version control but with controlled packages and XMI export you dont have the option to save nested controlled packages as stubs as you do with version control (as you noted).

There are some problems with this approach:
1. whether a user is connected to PROD or DEV he is using the same (local) SVN Working Copy so if he has it checked out in DEV it will appear checked out in PROD but may not be "loaded". DANGER

2. being a shared repository the GetLatest command is not available in PROD so one would have to do a checkout-checkin. Yuk.

3. in order to do a checkout-checkin the user must have update persmissions on Elements so I loose the ability to make PROD "readonly" unless onoly a special user can do the co-ci.

4. there is a HUGE performance hit when using SVN??? I only have 27 packages under VC and now the model takes over 3 minutes to load.

It's beginning to sound like this ain't the solution.

[peter.zrnko]

1. whether a user is connected to PROD or DEV he is using the same (local) SVN Working Copy so if he has it checked out in DEV it will appear checked out in PROD but may not be "loaded". DANGER

You can have two SVN Working copies of the same SVN directory.
In this way it's possible to have a package
- checked out in DEV
- and check in in PROD.

These two working copies may be set as two different repositories in EA. So it is possible to set
- the DEV repository as shared
- and the PROD repository as NOT shared

Maybe it's also possible to configure different access for the same user to different projects (using these two different repositories). I didn't tried that.

[thomaskilian]

4. there is a HUGE performance hit when using SVN??? I only have 27 packages under VC and now the model takes over 3 minutes to load.

There was a bug with SVN localization which has been fixed in the last build. However, it still takes a long time to load the model (and quite some seconds each time to appear for the Put Latest context - plus I have to commit multiple single files instead of one big bunch). So in the end, if the Export XMI would work with stubs, I'd have the choice to use SVN basics instead of EA build-in functionality. It would be up to me which death to die.

[mark.myers]

There was a bug with SVN localization which has been fixed in the last build.

I'm using the latest build - 817.
There is also a big delay when accessing the Package Control submenu and usually I have to do it twice.
Is 3 minutes to load a model with 27 packages (under VC) way out of the norm and indicating that something else is going wrong? BTW, my SVN repository is remote and accessed via http.

Peter, Thanks I hadn't realised that. I thought the VC ID (and path) was stored in the registry and not in the repository so was therefore set on a per user/workstation basis. Evidently not. So I could have PROD as NOT shared but with multiple users accessing it without the rights to update anything? And, yes, you can have different access rights for the same user in the two EA reps.

I still have the problem of the excessive load times though.

Edit: Ah, I can see now that the local paths are stored in, for example, C:\Documents and Settings\Mark\Application Data\Sparx Systems\EA\paths.txt.  Hmm, so can you REALLY have the same VC ID pointing to different working copies for different EA repositories for the same user. I suspect not but will try.

[thomaskilian]

I'm using the latest build - 817.
There is also a big delay when accessing the Package Control submenu and usually I have to do it twice.
Is 3 minutes to load a model with 27 packages (under VC) way out of the norm and indicating that something else is going wrong? BTW, my SVN repository is remote and accessed via http.

I have exactly the same experience (also with 817). For me it was an improvement concerning the localization. But it is still slow. That's why I want to use Tortoise instead of build-in EA features.

Edit: No idea why I see this only now. Opening EA takes 2.5 minutes with only 11 packes (plus root). I will contact Sparx once again

[mark.myers]

Sorry for the delay in response - competing demands

Thomas, interesting so maybe whatever the problem is it is back. Let us know the response you get from Sparx.

As a result of this I had decided NOT to use VC to assist with moving packages from DEV to PROD and have removed all packages from source control. Maybe if the performance issue is resolved (finally) I may go back to that as I kinda liked it but I also may need to lock in a solution before that happens

I have extended my addin to provide a menu option to move a package from DEV to PROD which simply exports the package to a temporary file, opens the PROD repository, finds where to put it and imports the package.

The problem I have now is that I get an annoying dialog that says "The Server is Busy" which I have to say okay to several times. Hs anyone opened a second repository via API before? Is there any forseeable problem with doing this? Eg,

Code: [Select]


               Repository.GetProjectInterface().ExportPackageXMI(package.PackageGUID, EA.EnumXMIType.xmiEADefault, 1, 3, 0, 0, filename);

               EA.RepositoryClass otherRep = new EA.RepositoryClass();
               otherRep.EnableUIUpdates = false;
               otherRep.OpenFile2(Globals.ProductionRepository, Repository.GetCurrentLoginUser(false), "");

               EA.Project otherPrj = otherRep.GetProjectInterface();
               EA.Package target = otherRep.GetPackageByGuid(package.PackageGUID);
               if (target == null)
               {
                   target = Repository.GetPackageByID(package.ParentID);
                   target = otherRep.GetPackageByGuid(target.PackageGUID);
               }
               if (target == null)
                   throw new Exception("Cannot find target location for this package");

               otherPrj.ImportPackageXMI(target.PackageGUID, filename, 1, 0);

[thomaskilian]

I just quote what Howard fom Sparx replied:

Hello Thomas,
 
Thank you for your query.
 
Looking at the log file that you sent, it appears that everything is working correctly.  It seems that Subversion is just slow to respond across your network connection - you report a response time of around ten seconds for the Package Control menu to display.
 
EA makes three calls to Subversion when loading your model.  The first two, a call to "svn status" with no filenames and a call to "svn --version" are used by EA to verify that we have a working connection.  If there are errors at this stage, the configuration will be marked as "offline".
 
The third call, with filenames, is made after confirmation that the connection is good and it is this call that is used to find the status of your controlled packages.  (It was this call that we changed to handle the localized output from Subversion.  Your log file shows that it is now working correctly for you.)
 
Allowing around ten seconds for each of these three subversion commands, accounts for about thirty seconds of your model's load time.  You haven't said much about the size or complexity of your model, but presumably loading the model from the model DB is taking around two minutes.
 
You state in your forum posts that you would like to be able to perform a Batch XMI Export, then commit the resulting package files to Subversion using TortoiseSVN.  This approach comes with a whole host of problems.  The XMI file format that is used by EA (and many other UML tools) for its exported packages, can NOT be merged.  For this reason, EA enforces serialized editing of version controlled packages, that is, it prevents concurrent editing.  If you used Batch XMI exports, then tried to commit changes through TortoiseSVN, you would almost certainly have to deal with merge conflicts at some stage.  You would then face a choice of discarding somebody's modifications or spending many, many hours trying to resolve the conflicts.
 
 
We implemented a "Check-in Branch" command some time ago, to make checking-in multiple packages a little easier.  This first implementation of this function simply exports and commits one package at a time, so in your case, there will be ten seconds to "check-in" each package added to the time taken for the package export.  We do have plans to improve this operation, by exporting all packages before making a single call to VC, passing a list of all files to "check-in".
 
 
When you open the Package Control menu, EA queries the VC status of the selected package before it constructs the Package Control menu.  We do this so that the "check-in" and "check-out" menu items (and others) can be correctly enabled and disabled.  If a package that was checked-in by you a few moments ago, has since been checked-out by another user, EA must show both the check-in and the check-out menu items as disabled.  The only way that EA can determine that the package is checked-out by another, is to query the file status at the time of constructing the menu.  With you particular connection to Subversion, it apparently takes around ten seconds for Subversion to return a result.  The only way that this can be improved is by improving the response time from Subversion.
 
I hope this has shed some light on what is happening...
 
 
Best Regards,
 
Howard Britten.

[mark.myers]

Thanks, Thomas. I'm not totally sold on that though. Correct me if I'm wrong but I read from your posts that you were surprised that it was again taking 2.5 mins to load, ie it had been fixed and is now broke again. If it is as Howard states then my connection to SVN is VERY slow - if I remove version control from the packages the model loads VERY quickly (from DBMS or EAP) but if I put some packages under VC it loads VERY slowly.

What/where is the log file refered to in your post - I'd like to check mine.
Are there any ways to "speed up SVN"?