Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Project Layout help

Hi,
I need a little advice on how to layout my projects and teams. I have read the many different docs on this site but still have not concluded the best layout or if rtc 2.0 allows me to do anything better.

Basic requirements:
1 - All folders must be rooted in the same directory for the build (folders probably equal components)
2 - Some folders belong to "the core"
3 - Some folders belong to "the platform"
4 - Some folders belong to a group of "platforms"
5 - There will be many "platforms" and some will be using latest "core" while others will be based off older "core" release.
6 - The "core team" and "platform teams" often are similar people but we don't want to encourage mixing development in "core" and "platform" for a developer at the same time.
7 - To build a "platform" the core code must also be present
8 - To test the core code generally you need some platform code
9 - The core and platform combined delivery the "platform features"

Can anyone help me with the basic layout that will still allow me to keep core/platform developers separated (to encourage good, clean interfaces between core/platform) while being able to take advantage of the tools and the build within RTC.

Thanks

0 votes



9 answers

Permanent link
Hi,
I need a little advice on how to layout my projects and teams. I have read the many different docs on this site but still have not concluded the best layout or if rtc 2.0 allows me to do anything better.

Basic requirements:
1 - All folders must be rooted in the same directory for the build (folders probably equal components)
2 - Some folders belong to "the core"
3 - Some folders belong to "the platform"
4 - Some folders belong to a group of "platforms"
5 - There will be many "platforms" and some will be using latest "core" while others will be based off older "core" release.
6 - The "core team" and "platform teams" often are similar people but we don't want to encourage mixing development in "core" and "platform" for a developer at the same time.
7 - To build a "platform" the core code must also be present
8 - To test the core code generally you need some platform code
9 - The core and platform combined delivery the "platform features"

Can anyone help me with the basic layout that will still allow me to keep core/platform developers separated (to encourage good, clean interfaces between core/platform) while being able to take advantage of the tools and the build within RTC.

Thanks


Hi Sean

It sounds like you should be looking at RTC Components to manage all this. Your proposed setup sounds like a smaller version of RTC development.

You should look at having a Core RTC Component, and a Platform RTC Component. Each component can be one or more Eclipse projects.

Each of the platforms could be an RTC Stream - and you can then be very specific about which version (baseline) of each component is needed for each platform. Not quite sure what is in 4

Some folders belong to a group of "platforms"


Once you have your streams and components, you can also sort out RTC Teams.

Hopefully, this will get you started - keep asking questions here and people will answer.

regards

anthony

0 votes


Permanent link
thanks for the reply.
Not sure if having a core component works. When previously exploring components one thing I found was each component (folder) was rooted in the same directory.

That breaks requirement 1. If the core has multiple folders, theymust be rooted at the same level as folders from the platform then it seems the only way to do it is each folder must be its own component. Does this sound correct?

The problem with that above is then it makes your baselines pretty complicated because instead of tracking a single baseline you have 10 or 15 different baselines that equal a "good, known" level.
Any ideas?

thanks

0 votes


Permanent link
In 2.0, there is flexible loading, which lets you control where on your
local disk files and directories (such as the component roots) are loaded.

WRT tracking sets of baselines, that is done in a stream, and then a
particular combination that works together is captured by creating a
"snapshot".

Cheers,
Geoff

spbrogan wrote:
thanks for the reply.
Not sure if having a core component works. When previously exploring
components one thing I found was each component (folder) was rooted
in the same directory.

That breaks requirement 1. If the core has multiple folders, theymust
be rooted at the same level as folders from the platform then it seems
the only way to do it is each folder must be its own component. Does
this sound correct?

The problem with that above is then it makes your baselines pretty
complicated because instead of tracking a single baseline you have 10
or 15 different baselines that equal a "good, known" level.

Any ideas?

thanks

0 votes


Permanent link
In 2.0, there is flexible loading, which lets you control where on your
local disk files and directories (such as the component roots) are loaded.

WRT tracking sets of baselines, that is done in a stream, and then a
particular combination that works together is captured by creating a
"snapshot".

Cheers,
Geoff

spbrogan wrote:
thanks for the reply.
Not sure if having a core component works. When previously exploring
components one thing I found was each component (folder) was rooted
in the same directory.

That breaks requirement 1. If the core has multiple folders, theymust
be rooted at the same level as folders from the platform then it seems
the only way to do it is each folder must be its own component. Does
this sound correct?

The problem with that above is then it makes your baselines pretty
complicated because instead of tracking a single baseline you have 10
or 15 different baselines that equal a "good, known" level.

Any ideas?

thanks


Geoff neatly explained the next step for me :-)

Once you have baselined components - you also have a snapshot which remembers the particular version of the relevant component. I always have this mental image of a bunch of components standing around and someone pulls out a camera - and takes a picture of them as they exist at that time.

You should also look at the build tools in RTC - that may help with sme of your restrictions on where the files live in the particular folders.

anthony

0 votes


Permanent link
So at the most basic level I would:
Create 1 master project
A team area per platform
A team area for the Core
And then assign Streams and components to their corresponding team areas?

Thanks

0 votes


Permanent link
So at the most basic level I would:
Create 1 master project
A team area per platform
A team area for the Core
And then assign Streams and components to their corresponding team areas?

Thanks


Sort-of.

1) 1 master project
2) Sort out an overall plan (your release milestones with iterations leading up to the releases).
3) Set up teams (the "team area per platform" sounds good + 1 core team - you can have people assigned to multiple teams)
4) Let each team work out its plan for each iteration

and on the component/stream side

Core compoment(s)
Platform specific component(s)

Let the core and platform teams each create a stream for themselves - perhaps more than one (dev + prod).

I know this is all a bit more complicated than your version but should work out better.

Geoff - does this make sense? If this could be simpler, that would be good.

regards
anthony

Create a stream per platform

0 votes


Permanent link
One follow up question.

Each platform has different release dates/schedules. Is this supported or is the schedule/release plan only at the "project" level?

0 votes


Permanent link
One follow up question.

Each platform has different release dates/schedules. Is this supported or is the schedule/release plan only at the "project" level?


OK - so this is not a problem. Each platform needs to have its own timeline in the plan (open up the Project Area and you will see the timelines). This will allow you to have different timelines (they were called development lines in RTC 1.x).

How are you getting on with your project layout so far?

anthony

0 votes


Permanent link
I think both approaches are reasonable.
Sean's approach would be a "software structure" oriented approach, where
you create teams based on the structure of the software.
Anthony's approach is based on an existing set of teams, which then just
get mapped directly to team areas.

Cheers,
Geoff

kesterto wrote:
spbroganwrote:
So at the most basic level I would:
Create 1 master project
A team area per platform
A team area for the Core
And then assign Streams and components to their corresponding team
areas?
Thanks

Sort-of.

1) 1 master project
2) Sort out an overall plan (your release milestones with iterations
leading up to the releases).
3) Set up teams (the "team area per platform" sounds good +
1 core team - you can have people assigned to multiple teams)
4) Let each team work out its plan for each iteration

and on the component/stream side

Core compoment(s)
Platform specific component(s)

Let the core and platform teams each create a stream for themselves -
perhaps more than one (dev + prod).

I know this is all a bit more complicated than your version but should
work out better.

Geoff - does this make sense? If this could be simpler, that would be
good.

regards
anthony

Create a stream per platform

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Jun 29 '09, 2:35 a.m.

Question was seen: 5,415 times

Last updated: Jun 29 '09, 2:35 a.m.

Confirmation Cancel Confirm