Cloud Services + Baselines

[acalbaza]

Hello,

I'm reaching out because I'd like to use baselining with Cloud Services.  I have a setup with multiple users working in EA.  Setting up the ODBC drivers is a pain and we are in distributed locations.  Cloud Services makes the most sense for us I think.  However, I'd also like to take advantage of baselining our work to get some level of "version control" (I know baselining is not true a version control) and help us with collaboration.  Right now, we're using a single .eap which is getting larger and changes are not controlled as tightly as they could be.

Here is what I'm trying to do:

As described in the Deployment white paper, it sounds like I can establish a project as a baseline that will serve as "trunk" (or master copy).  I'd like to create a copy of this "trunk" project to serve as a "branch" by using the project transfer feature.  From there, I could iterate over designs on the "branch" and then re-integrate those changes with the trunk at a later time using baseline merge features. 

This is my understanding which comes from figure - 8 of the deployment guide - http://www.sparxsystems.com/downloads/whitepapers/EA_Deployment.pdf

All of this sounds great!  However, I get stuck with the "project transfer" option.  I am unable to perform this action since I am using Cloud Services.  As a result, I cannot get to the "branch" state that I am looking for. 

Does anyone have any guidance on how to achieve what I am shooting for?  Am I understanding the description of "Using Baselines" - figure 8 properly?  Or is there another way to achieve this with Cloud Services?

Any help is appreciated.

Thanks!

Alejandro

[Geert Bellekens]

Alejandro,

What you said all sound plausible in theory, but is just nonsense in practice.

Just do a POC using plain old eap files. Make a branch, make a realistic bunch of changes, and then try to merge this into your trunk model.

Models are not linear as code is, you'll see what I mean once you try to merge a model.

Geert

[mperry152]

Hi Alejandro

My clients use the same method you describe for maintaining a current state version of our repository (your "trunk") and project-based target state versions (your "branches") but are using EAP files currently. We don't use the project transfer feature, we simply copy from one EAP to the other. When the project is finished, we merge its content using baseline merges back into the main enterprise repository.

Several of my clients are also migrating to cloud services to better facilitate access and collaboration, and to rid ourselves of all the EAP files.

I have tested baseline features in the cloud and it does seem to work. You'll want to export the baseline from the "branch", import it into the "trunk", and then do the baseline merge. As Geert mentions, because the models are not linear, merging is not an exact science and you need to ensure that you review changes prior to doing the merge.

We're running into glitches with cloud however using package locking (which I believe is essential for shared access to a single repository.) So if you have any feedback on that, let me know!

-m

[Uffe]

Hi Alejandro,


Figure 8 in the deployment white paper describes manual management of baselines between repositories. You can use this method between two cloud-based repositories, but you can't use the "Load Other Baselines" function it mentions because the Package Baselines dialog doesn't support cloud connections. Instead you have to export/import the baselines as files (in the same dialog).

Similarly, the Project Transfer dialog doesn't support cloud connections, so in order to carry out a project transfer you need to use the actual behind-the-scenes DBMS connections / file paths to the repositories you've set up.

With those modifications, the outlined method should work.

It is important to note, however, that you don't baseline a whole project in one go. Baselines are managed on the package level, and any package can be baselined. So there is no such thing as a project baseline, nor a baseline project. A project contains a number of packages, some of those packages can be baselined, and those baselines can be moved between projects; that's the mindset you should adopt.

I would also advise you to look into the reusable asset service (RAS). This uses the cloud service to store reusable assets, which are very much like package baselines but with the added twist that their dependencies are managed -- otherwise a huge headache for package-level version control (which is what EA supports, whether you choose to use baselines or Subversion).

HTH,


/Uffe