Author Topic: collaboration & multiple feature relase (Read 5254 times)

yiki · « **on:** January 27, 2012, 05:31:55 am »

is there any good/standard known method of how to organize a project that more than one team work on it, and use it in way to support multiple releases?

OpenIT Solutions · « **Reply #1 on:** January 28, 2012, 01:10:35 am »

Its a tricky question to answer without a little more detail. Its tricky because you don't want to over engineer your solution.

My advice is that if you can, use the built capability that allows you to host your model on a shared RDBMS. Use "baselinging" to enforce explicit version control (sync baseline versions with element versions). If you need branching, baseline your model, export it to a new database instance, work on it and merge back into the trunk database instance.

This setup works for most teams and avoids the overhead of integration with a version control platform. If however your needs a more complex then you will have to look at VC integration.

As to how your structure your model, again this depends upon what your modelling and using Sparx for. At a minimum think about a "view" library for elements that will be reused, your 'as-is' view and a project view (under which you would have packages such as requirements, use cases etc)

There are some sample projects you can look at shipped with EA; there is also a good guide to VC / Team working under the resources section of this site.

Regards,

Jon.

pittagentskip007 · « **Reply #2 on:** January 29, 2012, 03:01:26 am »

Hi,

I had this exact same question. Here is what I plan to do about it when we implement EA this year. Any feedback is welcome:

Created a core folder structure and a gold copy of our master specifications as part of a KT program from contractors to full time staff.

Deploy EA in a shared DB mode and PROD copy is locked down except for a few administrators. New projects then get their own copy of the DB to work on.

We also establish a copy of the EA DB for each of our physical environments i.e. TEST, QA and the flow works like this:

1) Project X Copy (aka DEV) takes a baseline
2) In TEST region, we look to merge the changes from their baseline into our TEST region for. The project's teachnical lead takes this responsibility and makes sure as he is doing the merge that all the differences make sense based on the scope. This occurs the same time the code moves to the TEST instance of our application from a deployment perspective and repeats as code is repromoted
3) When its time for the next project to go into TEST, the do the same and get the chance to see how their changes clash with another project
4) process repeats for QA region...
5) process repeats for PROD region except the EA administrator does that merge because that instance is locked down to prevent unscantioned changes

The only issue we have this process is during some testing we seem to get out of memory errors sometime when taking a baseline. Our source code is big (as we keep multiple apps in the same EA project since they integrate with each other) so our project has a ton of elements in it.

While I have no explaination for this from EA, my guess is because when you take a baseline it seems like it has to hold the entire XML in memory before it writes it to the output file so it will throw out of memory error/crash with too big of a package structure being baselined.

Please let me know if anybody else has had this problem and/or tried to use EA in this way.

Regards.

qwerty · « **Reply #3 on:** January 30, 2012, 07:21:54 am »

Have you ever tried baseline merge? You should do so prior to setting up a whole project.

q.

Geert Bellekens · « **Reply #4 on:** January 30, 2012, 06:15:03 pm »

In theory that seems like a good idea, following following the development branches, qwerty is absolutely right with his comment.
Merging with EA is to be avoided a all costs. (you can get old really really fast while merging EA models

)
So unless you have some kind of code generation going on, and EA is your primary development environment, I would rethink that process.
In most cases you don't absolutely need the different branches. Most clients I've seen just had one (to-be) model, with some degree of versioning. (going from plain old backups over baselines to full version control integration).

Geert

yiki · « **Reply #5 on:** January 31, 2012, 04:03:30 am »

OpenIT Solutions thx that was helpful.

pittagentskip007 , I was thinking to definetly create a " baseline" but after what you said that is the project is big (which is my case) you get out of memory sometime. What was the size of your model when you start getting memory errors?

qwerty what do you mean prior to setting up a whole project? Do you mean before putting your model in a DBMS and configure it for users?

Geert what do you mean by (to-be)?

I appologize if some of my questions were tidious but I'm still new to EA, and i'm trying to understand the best practices. (I have read the 2 white paper on sparks site "version contro" and "team deployment" but it seems that there are many ways to implement things. Thanks for the help

qwerty · « **Reply #6 on:** January 31, 2012, 06:55:38 am »

I mean before starting a project based on baseline merge you should try that at home. As Geert said your hair will turn white during baseline merge. Having a couple of hard working modellers in your back will make you sweat...

Answering for Geert: to-be means a model you plan to have in the future.

q.

Geert Bellekens · « **Reply #7 on:** January 31, 2012, 02:30:24 pm »

Quote

Geert what do you mean by (to-be)?

The to-be model is a model of the system how it will be after it has been developed. (as opposed to as-is that is a model of the current state of the system-

Geert

pittagentskip007 · « **Reply #8 on:** February 01, 2012, 06:15:51 am »

I've tried the baseline merge and I agree its quirky. So I've dropped the idea of one EA instance per environment and one EA instance per project and will instead will keep on EA instance per project and a PROD instance that everybody takes a copy with in each project.

Here is why I came to this conclusion:

My goal: use EA for use case/business workflow/functional requirements to component/source code traceability.

What I find limiting in EA that makes me want to do this EA DB per project and environment is document generation.

I need to filter out all changes made between multiple projects i.e. project X only gets printed stuff related to project X. I know I could make people tag any elements for their project and/or alter the phase or version numbers and filter on that but its a LOT of work to ask somebody to do that.

I could separate things for a given project i.e. package per product and have people recreate new elements for each project into their own packages but that doesn't really work for source code as each project would need to keep their own source branch in EA.

With one EA instance per project, I can simply apply the modified date as a document generator element and diagram filter so anything you changed will get included in your document export in true push button fashion.

Also, another gripe I have with document generation in particluar a lot of my design documents look like this:

Heading 2: Changed Components

For each component (element)...

Heading 3: Element name i.e. Class 1
Heading 4: Diagram (s)
Heading 4: Traceability (printing related elements from another elements i.e. connector > source > element)

For the life of me I cannot get the document generator to apply filters on the elements on the ends of the connection to be any criteria at all. So for my logical components/source, if I want to show requirements traceability to only those created and defined in a project I get requirements from all projects, including those from past projects.

qwerty · « **Reply #9 on:** February 01, 2012, 08:38:46 am »

You might come to the conclusion that you need to write your own generator. We did so as we need to do a lot of context dependent parsing in order to produce the right output. Something a rule based generator can't hardly do. I remember there's a product out there to produce more advanced doc generation. Can't recall the name but google is your friend.

q.

pittagentskip007 · « **Reply #10 on:** February 02, 2012, 08:00:22 am »

I did some googling and saw a good third party doc generator that will give me my structured documents much easier than the native document generator from the looks of it called eaDocX. I'll download the trial and report back on how it goes.

One promision option with this tool is to print based on relationships. So perhaps I could create a project element and link requirements to the project and then code to the requirements. I'll let everyone know how that goes too.

Thanks for the input on the doc gen side. I'll also let everyone know how sick of baseline merge I am after a few weeks of my process :-/

-skip

qwerty · « **Reply #11 on:** February 02, 2012, 06:34:18 pm »

I just recently started two threads to improve baseline merge usability and was astonished that I got not feedback. I guess the reason is simply that people like you tried it once and then moved it into that large chest containing all that useless stuff you never needed. Obviously nobody is using it. Basically the idea is good, but they need to make it useable.

q.

Sparx Systems Forum

News: