It's all about the answers!

Ask a question

Identifying changed subset of an RTC component


Ben Williams (134) | asked Sep 15 '15, 6:13 a.m.
edited Sep 15 '15, 7:50 a.m.
 Scenario:
  • 100+ RTC Components
  • Each RTC Component logically maps to a 'Module' in our architecture
  • 1000+ 'components' (not RTC components) in our architecture
  • Each Module (RTC Component) contains between around 1 and 50 'components' in our architecture
Our Components are represented in a folder hierarchy under each Module (RTC Component).
So every RTC component has one or more subfolders, with each first level subfolder representing one component in our architecture. Each of the component subfolders includes build scripts.

On code delivery, we want to build only the changed components (our components, not RTC components) in a Module (an RTC component). So, as part of a change set delivery, we want to invoke the build scripts for any components (our components, not RTC components) that have changed.

We will be using RTC 5.0.2, and Jenkins for builds.

Whats the best way to achieve this? 

It would seem that nested components in RTC 6 would be a great way to go, with each component in our architecture mapping to an RTC component, and using higher level RTC components to represent our Modules, to nest he relevant components and manage the complexity/scale. In that case, this identification of changed subset of an RTC component would not be necessary, but we're only just moving to RTC 5.0.2, so need a more immediate solution.

One answer



permanent link
Ralph Schoon (63.2k33646) | answered Sep 15 '15, 8:31 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You would have to use the RTC SCM commandline to detect the changes (between the current baseline and the one before) that go into the change and from that find the scripts to run.

I am not convinced that 1000+ nested components in a stream would scale. I think this could have performance impacts.

Comments
Ben Williams commented Sep 15 '15, 9:07 a.m. | edited Sep 15 '15, 9:08 a.m.

Ralph, thanks.


That concern around performance (as well as human navigation concerns in the absence of nesting) is indeed why we have adopted the current approach - good to know that RTC 6 doesnt really help here.

I believe you are suggesting a 2 step solution:

1. Baseline on every delivery
2. Write a script to detect changes

For #2, do you have any pointers to examples?

Your answer


Register or 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.