Book a Demo

Author Topic: Urgent: Deployment Best Practices  (Read 4504 times)

oriol priol

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Urgent: Deployment Best Practices
« on: February 14, 2009, 06:25:03 am »
Hi folks,

I went through the whitepapers and the forum, but I am still puzzled how to set up a collaborative deployment. I had the model moved into a mysql database and set up ODBC-Connection for the clients, but when testing the setup I found that there is no notification/warning if  concurrent edits to an object take place. Of course, that will not do. I tried to toggle on the ODBC-connection setting ("share deny write") which resulted in a connection error.

I am very intrigued by the vertical pervasion of EA's approach, and am on the verge to establish EA as a company-wide solution, if it wasn't for the described problem. If I can't present a sound, dummy-safe solution, it'll be doomed.  Maybe it's easy for a fully-blown developer to derive the right way to kick ass from the provided documents, but it isn't for a domain guy. :-X

We are using svn for version control, if that helps...

So does anybody out there know what would be the best way of deployment for the following requirements:
- Users should be able to work offline
- When syncing, there should be a way of sorting out discrepancies
- When working online, users should be prompted if they encounter concurrent edits and be given at least  the options: overwrite, cancel
- Changes to the Model should propagate automatically if online

I'm really desperate in solving this issue, since by the end of next week it'll be trick or treat - either it's up or dead. :-[

Thank you for any input!

Dermot

  • EA Administrator
  • EA User
  • *****
  • Posts: 591
  • Karma: +7/-0
    • View Profile
Re: Urgent: Deployment Best Practices
« Reply #1 on: February 16, 2009, 12:04:02 pm »
There are many alternatives for this type of deployment, ranging from using the .eap  replication for the off site usage (synching), to using the version control.  The deployment whitepaper covers the former. If you need specific locking on packages being editied then the Version control would be a better solution, however you can also manualy lock diagrams and packages.  
I suggest you look at the first three pages of the help file on VC and check the locking alternatives:
http://www.sparxsystems.com/uml_tool_guide/uml_model_management/version_control_basics.html
http://www.sparxsystems.com/uml_tool_guide/uml_model_management/applying_version_control_to_en.html
http://www.sparxsystems.com/uml_tool_guide/uml_model_management/applying_version_control_in_te.html

Frank Horn

  • EA User
  • **
  • Posts: 535
  • Karma: +1/-0
    • View Profile
Re: Urgent: Deployment Best Practices
« Reply #2 on: February 16, 2009, 06:08:49 pm »
OK, the help file and the whitepapers cover most of it, but what about this requirement:

Quote
Changes to the Model should propagate automatically if online

I for one wouldn't know how to achieve this.

Thomas Mercer-Hursh

  • EA User
  • **
  • Posts: 386
  • Karma: +0/-0
  • Computing Integrity
    • View Profile
Re: Urgent: Deployment Best Practices
« Reply #3 on: February 17, 2009, 10:01:43 am »
You make it sound like the model changes should propogate in real time without a check-in.  Even if that were possible, I can't imagine it being desirable.

Frank Horn

  • EA User
  • **
  • Posts: 535
  • Karma: +1/-0
    • View Profile
Re: Urgent: Deployment Best Practices
« Reply #4 on: February 17, 2009, 06:15:58 pm »
Quote
You make it sound like the model changes should propogate in real time without a check-in.  Even if that were possible, I can't imagine it being desirable.

Certainly not. I wouldn't want everybody to get a message everytime I create a package.

But as to propagating check-ins to those who are working online, and still leaving a way for offline working:

I think you would have to use shared models on a server for online working. When someone checks in a package, the others will see the change of icon in the project browser. For offline working, one would have to use a private eap file, get all packages required from the version control repository, check some of them out, and later go online again with the private eap file to check them in. After that one could close the eap file and resume work on the shared model.