How to decide on RTC Components during a migration?
Baeyens 060001XDU9 Visits (10045)
When doing a migration from an existing version control tool to RTC there are a lot of new concepts to be learned. I’m thinking about Collaborative lifecycle management, streams, change sets work items, project area, team area and components.
Most people struggle with these ideas and it takes time and mostly experience to see the benefits of these concepts. In a migration project however there is hardly any time to experience the concepts and as such the concepts get explained at a conceptual level.
I did have discussions on all these concepts with customers. In my experience the concept of components have been the toughest to come to grips.
Why are components the toughest? Streams, project area's, team area's and working sets are easy to change once the migration has been done. Components on the other hand are not so easy to change. If the migration splits the code in a wrong way; it will cost lots of time and effort to correct later. This creates stress and uncertainty. A full understanding of the concept is as such needed. Add to that that in most cases there is no simple golden rule on how to decide on the components for all code before the migration starts.
Therefore customers have questions like “What is a component?” “How do we split our code in components?” “Do we create 1 big component?” “Do we create a component for each software component?”
The first question to answer is the easy one “What is a component?”.“A grouping of related artifacts in a stream or repository workspace. A component can contain any number of folders and files.”
A component in the Unified Modeling Language "represents a modular part of a system, that encapsulates its content and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces".
It is also clear that the definition provided by infocenter is not instructive on the question “how do we decide whether 2 files need to be in the same component or not”.
The good news is that there is a simple rule that leads you through the component decision process. That rule is:
Select your components in such a way that all the users of the system only have the files in their workspace they accept in their work space.
Even though this is a simple rule on "what you want to achieve" it still does not explain the "How do you achieve the what". The good thing about the rule is that it identifies the 2 key players in the process. The users (in casu the developer)??? and the file(1). 2 things we all know. During the process of defining the components we will group files and users. A group of files is a component and a group of users is a user group. The main difference between the two groupings is that a file can only belong to 1 component while a user can be part of many user groups. What I do is: I assign exactly 1 user group to each component.
So lets look at the process:
1. Take the first file
2. Identify all the users who need this file on their system
3. Call this user group : user group 1
4. put the file into component 1 assigned to user group 1.
5. take the next file
6. Identify all the users who need this file on their system
7. If this user group maps to a existing user group add the file to the component linked to this user group
8. If the group does not map to a existing user group create a new component and assign the new user group to it.
9. Add the file to the new component
10. If there are more files to do; go to step 5
11. Reconsider the results you have.
In the above process step 1 to 10 describes a simple iterative process that assigns files to user groups based on "need the file on my system". The process also assigns a component to each and every user groups.
This way you get a split on "need basis". However the "need basis" is too strong. It is very likely that this process leads you to to many components. The rule given above states :"users accept in their workspace". This is where step 11 comes in. There are no real rules here but common sense will get you a long way.
For instance: you may find yourself in a situation where you have multiple components having very little files. Grouping the files into fewer components is likely to improve the setup. The overhead to the users of having the files on their system may be less than the administrative cost of having more components.
A final thought. If you go through this process; make sure you involve all users. For instance do not forget the build user. Or a person having 2 roles on the project has to be seen as 2 users.
(1)Here a file is used as the file itself and its location. As such folders can be kept out of sight.