Rational Team Concert
Guido Salvaneschi
Dipartimento di Elettronica e Informazione Politecnico di Milano
salvaneschi@elet.polimi.it
Project Areas
The project area is the system's representation of a software project.
The project area defines the project deliverables, team structure, process, and schedule.
A project area the top-level or root item in a repository.
A project area references project artifacts and stores the relationships between these artifacts.
Access to a project area and its artifacts is controlled by permissions.
A project area cannot be deleted from the repository; however, it can be archived, which places it in an inactive state.
Lines of Developement
A project can be quite simple or complex in terms of its committed product deliverables, process, and schedules.
A project can have multiple active lines of development, known as timelines, such as:
Maintenance for one or more shipped releases
Development of a new release
Exploratory development for a future release
These timelines work in parallel, each in a different state.
Each timeline can have one or more iterations in which some set of deliverables and functional improvements are committed.
Project teams as team areas
The structure of the project teams is defined by one or more team areas.
Typically, one or more teams are assigned to each line of development.
Users might have multiple assignments that require them to work on more than one team.
Some members, such as the project lead, might not belong to a team area
They are defined as members at the project level in the project area overview.
For small projects no team areas are used.
Work item categories.
Work item categories group work items by the various components or functional areas of your project.
Each category is associated with a team area whose
members are responsible for developing that component.
When you create a work item, you set its Filed Against (category) attribute.
Members of the team area associated with that category receive notifications when the work item is created or modified.
For each timeline, you can specify a different association.
The process defined for the associated team area is the process that users follow for managing and resolving the work item.
Team Area
The structure of the project teams is defined by a hierarchy of team areas.
The team area manages team membership, roles assignments, and team artifacts:
Defines the team members and specifies their roles.
Defines the timeline in which the team is participating.
Team areas are optional. In a simple project with a small number of users all work is done in the context of the project area.
Team areas inherit the process and timeline of their parent, which can be the project area or a parent team area.
Project work items belong to only one team area. Over
time, a work item might be triaged to another team area
Project process
Process is the collection of practices, rules, and guidelines used to organize and control the flow of work.
The project process is defined in a project area and is typically based on a template.
Basic process structure: set of timelines and iterations.
can be further customized in a team area, timeline, iteration.
You use process to define user roles and their
permissions for performing operations within the tool, such as changing the state of a work item.
Process details for roles, permissions, reports, work items types and workflows, can be customized in the process configuration.
Project schedule as iterations
The project schedule is specified by process iterations, which represent intervals in the life of the project.
Each set of iterations is specific to one line of development.
Teams can configure iterations in a hierarchy; for example a timeline could have multiple milestone iterations.
Each of those milestones could contain one or more phase iterations.
The iteration hierarchy and names are user-defined.
You can define the timelines and an iteration hierarchy in the project area overview.
The overview contains controls for adding timelines, start and end dates for iterations and a designation for the current iteration.
After iterations are defined, work items can be assigned to an
Timeline (1)
A timeline represents an area of activity within a project that typically has its own schedule, deliverables, teams, and process.
E.g. a project with both new product release development and current product maintenance might define two separate timelines because they have different delivery schedules, teams, processes.
Project intervals or phases are defined within a timeline and expressed as a hierarchy of iterations.
Timeline (2)
You can designate one timeline as the project timeline.
All of the predefined process templates specify a project timeline.
The project timeline defines the project area start and end dates along with the iteration breakdown of those dates.
The project timeline differs from your other timelines in the following ways:
The project timeline iterations apply to the project area. This means that if the project timeline process is customized for the current iteration, that customized process affects any artifacts associated with the project area.
All team areas that do not have an explicit custom timeline set are governed by the process of the project timeline.
Iteration
Projects are organized into a series of development periods called iterations.
Each timeline contains a hierarchy of iterations which can define start and end dates.
An iteration hierarchy typically represents broad phases of a project, each of which is subdivided into a series of shorter iterations.
Iterations (2)
The example contains development and
maintenance timelines.
The timelines contain a
release with milestones (m1 and m2) or version releases (1.0.1 and 1.0.2).
The current iteration for
each timeline is marked with a blue arrow. Completed iterations are marked with a check mark.
Project Release Plan
A Project Release plan is the highest-level plan in RTM™
that provides a brief overview of the project goals.
Displays top-level work items, such as Stories and Epics associated to a project area or team area, child team areas, current iteration, and its child iterations.
Although you can create a Project Release plan for any iteration, it is advisable to create a Project Release plan for the top iteration.
The other plan types, such as Team Release plan and Iteration plan, can be created for child iterations.
Note: If you follow the Scrum process template, a Project
Release plan is called a Product Backlog.
Simple Team Process Template
The process template enables teams to start quickly.
Team members have permissions to do any project modification.
The template does not include any team areas.
It includes the following structure and components:
A single timeline, Development
A month-long iteration, I1
Two roles with associated permissions: default and team-member
Three work item types:
Defect
Enhancement
Task
Work Items
A work item is a way of keeping track of the tasks and issues that your team needs to address during the
development cycle.
Work item types examples in the Scrum process:
Defect: identifies a bug.
Story: describes part of a use case.
Task: describes a specific piece of work.
Impediment: tracks things that get in the way of making progress.
Track build item: typically created from a build result to track the fixes needed for a failed build.
Work Items
RTC as a defect-tracking systems. Work items purposes:
Describing defects
Describing feature improvements
Identifying simple tasks, such as updating copyright notices
Recording customer requirements
You can also use work items to generate a list of new
features that your team is delivering with a release.
Work Items
While working on work items, you can:
Associate source code change sets (from the Pending Changes view) with work items so that users can navigate from a work item to code and back.
Attach documents and screen captures.
Transfer ownership from one team member to another.
Include them in plans for specific milestones by setting the Filed Against and Planned For field values to those of the plan.
See which work items other team members are working on.
Add an approval to a work item. When you add an approval, you identify one or more users who should review, approve, or verify the work done to resolve the work item.
Work Items
Each work item type has a state transition model (STM).
The STM defines the states a work item can be in and the actions that users take to move the work item from one state to another.
A typical state transition model provides a path from a submitted or opened state to a resolved or closed state.
States in between those starting and ending points allow users to indicate their progress in the issues described in the work item.
Primary mechanism for finding work items: queries.
Predefined queries, e.g. the query that returns all unresolved work items assigned to you.
Create queries to meet your needs, and share queries with all members of your team or with specific users.
Work Items plans and areas
Team leads and team members can use plans to manage their work items that are planned for completion for a
release, backlog, or an iteration.
Newly created work items, are assigned to a category.
A team lead later assigns the work item to a milestone.
Plans can be associated with a team area or project area.
If the work item categories are associated with a team, Jazz™
displays work items in the responsible team's plan based on the work item's category and planned iteration settings.
If the work item category is not associated with a team area, a project area is used.
Plans and WorkItems
Plans are composed of work items matching certain criteria. Treating plans as a set of work items has the following useful characteristics:
Plans are live:
Changing work items changes the plan. For example, closing a work item marks the work item as done on the plan, without need for further explicit actions.
Changing the plan directly changes the work items, or creates new work items if necessary.
Plans can be viewed in many ways. A plan can easily be
regrouped by owner, functional category, duration, or any other criteria that is available on work items.
Plans are available to everyone on the team.
Repository Workspaces
A workspace is an area where you can view or modify components.
A repository workspace on the server stores components as versionable artifacts that can be loaded into a local workspace (such as an Eclipse workspace or an ordinary folder) on the client.
Every repository workspace has an owner, and only the owner can make changes in the workspace.
Changes you make in your workspace remain private until you decide to deliver them to a workspace flow target.
When you want to work with changes that other users have made in their repository workspaces, you can accept them into your workspace.
Components
Projects are grouped into components and components can be grouped into streams.
The fundamental organizational unit for source code is the component.
A component typically contains at least one Eclipse project, and usually contains several.
Most of the operations that manipulate files and folders, such as loading, unloading, and adding to a workspace, are expressed in terms of components.
You can move projects from one component to another, or refactor a single component into multiple components
Components
You can create a new component or add to an existing one by sharing a project from your Eclipse workspace.
You can also explicitly create a new, empty component to which you can add projects.
To create an empty component, right-click a repository workspace in the Team Artifacts view and click New > Component,
Streams
A stream is a repository object that includes one or more components.
Typically the components in a stream have dependencies or functional relationships that make it sensible to group them.
Streams are typically used to integrate the work done in workspaces.
Team members deliver their own changes to the stream and accept other team members' changes from the
stream into their repository workspaces.
When updated the stream represents the current state of
the team's development effort.
Streams
Create a stream:
In the Team Artifacts view:navigate to your project area, right-click Source Control, and click New Stream.
From the contents of a repository workspace, navigate to the
workspace in My Repository Workspace and click New > Stream.
In the Stream editor, enter a name and optional description for the new stream, and select the project or team area to own the stream.
In the Components area, specify the components that team members will work on in this stream. (If you are creating a stream from a repository workspace, it will initially contain the same components that are in the workspace.)
Click Add to search for existing components to add to the stream.
Click New to create a component and add it to the stream.
Share a project (1)
To add an Eclipse project to the repository, use the Share Project wizard to add it to Rational Team Concert™
source control.
Right-click the project and click Team > Share Project.
In the Share Project window, select Jazz Source Control as the repository type and click Next.
If you are not already connected to the repository in which you want to share the project, select a repository to use and click
Login. To create a new repository connection, choose New in the drop-down list of repository connections.
Share a Project (2)
Specify the repository workspace to use:
If you have an existing repository workspace and component in which you want to place the project, leave Select a component in an existing repository workspace selected, expand the workspace, and select a component. To place the project in a new component in an existing repository workspace, select the workspace, click New Component, enter a name for the new component, click OK, and select the new component in the list. Click Next.
If you have not created a repository workspace, or you want to create a new one, select Create a new repository workspace
named, enter a name for the workspace, and click Next. Since you will not need to share the project with anyone else, select Just
back up my work. Don't flow changes to a stream yet and click Next.
Share a project (3)
If your project contains any file types or folders that are ignored by Eclipse, the wizard prompts you to review them.
The Eclipse project is added to a component in a
repository workspace. Changes that you make in the
project are copied to the repository workspace when you
check them in.
Tutorial 1 part A
Create a timeline with iterations and plans and some example work items.
Create work item queries.
Assign and manage work items.
Connect to Project Area
Connect to the Tutorial1 project area.
Team Artifacts > Repository
Connections > Connect to
Project Areas...
Tutorial 1 Project Area Tab
Open the Tutorial1ProjectArea tab
Team Artifacts > Tutorial1ProjectArea > Open
If you haven't one jet, get a Team Role.
This can be a reason for unexpected “permission denied” errors
TutorialProjectArea Tab > Select a user > process roles
Tutorial 1 Project Area Tab
A WorkItem category is added as a default.
This will be the “filed against” property.
Tutorial 1 Project Area Tab
In the Overview tab you can edit timelines and iterations.
Iterations can have subiterations, in a tree.
You probably need a single timeline and some iterations.
Adding Plans
Fill each iteration with a plan.
Team Artifacts > Chose an iteration > New... > Plan
In the plan page you can edit the description.
WorkItems are managed in the Planned Items tab.
Adding a Work Item
In the Planned Items tab, Right-click on a user or on
“Unassigned” > Add Work Item
Double-click to open the Work Item
ConfigureFrom the work Item page
Type
Severity
Owner
Priority
Planned for
Time estimation
Start working / Resolve / …
Time Infos
Time informations can be used to track the progress of the
project.
Tracking artifacts
A work Item can be associated to an artifact using links and attachments.
Artifacts should be part of a versioned workspace.
Some iterations produce diagrams, texts, ecc rather than code.
Search WorkItems (1)
A work Items are search inside the whole project area.
The best way to find them is to define custom queries
Team Artifacts > WorkItems > MyQueries > New Query >
Simple Query
Examples:
Closed
In Progress
New
Owner
Search WorkItems (2)
Use “Start from Scratch” for more accurate conditions.
Team Artifacts > WorkItems > MyQueries > New Query
> Start From Scratch
Es: “Planned For”
find all the Work Items in the first iteration.
Exercise A
Create a timeline with the
MyAMDD process.
Exercise A
Fill each iteration with a plan.
Establish suitable deadlines for each plan
Fill each plan with some Work Items.
Try to attach a local file (e.g. the use case diagram).
Requirements envisioning, among others:
Requirements table
Requirements document
Use case modes
Architecture modeling, among others:
Component diagrams
Petri nets
Exercise A
Create queries.
Open work items
Closed Work Items
Assigned to a certain user
Planned for a give iteration
Open a work item assigned to you, complete the work
item and close it.
Tutorial 1 part B
Create a repository workspace.
Create a stream.
Organize changes in change sets.
Learn versioning basics: check-in, deliver, view
history, accept changes.
Source Control
Versioning is managed in the “source control” dir.
Some defalult repository objects are created:
A default project area Stream.
A default component in the stream.
Streams
Open the stream configuration editor
Team Artifacts > Tutorial1ProjectAreaStream > open
A stream il owned by a project area.
A stream can contain several components.
A stream can have flow targets.
Repository Workspaces
Create a repository workspace for your user.
Team Artifacts > Source control > new... > Repository Workspace...
In the first wizard:
Flow with a stream
Select the default stream in the Project Area
Add a name
Select the default component
Add a tick in “load repository workspace after creation”
In the second wizard:
Find and load eclipse projects
Select the default component
Repository Workspaces
The repository workspace appears in the Pending Changes view with:
The target stream
The components in the repository workspace
Add a project to the repo WS
In the (local) Workspace tab create a new java project
New... > java project
Right-click the project > Team > Share Project...
Checks-in the project in a repo WS
In the wizard:
Jazz Source Control
Select the component in the repository workspace (not in the stream)
Choose resources to be versioned
Default:
Do not version .class files
Do not version files in the /bin dir.
Adding a /documentation
dir can be a case in which
you would like to add new
ignore patterns.
Pending Changes
The creation of the project is in the “Outgoing” (from repository WS to the stream) folder.
A default “Share projects” change set is created to add file changes to.
It is the “current” change set
Each new change is added to it unless you define a new change set and set it as current
The single modifications are displayed
Right-click the change set >
Edit Comment to change the default name.
Unresolved Changes
Changes to a local WS when a repo WS is loaded, are added to the “Unresolved Changes” dir of the repo WS.
From the package view
add a class src/start.StartUp to the local workspace
Unresolved changes can be checked-in:
Right-click Unresolved > check-in >
chose a change set / add to an existing change set
Create a new change set with the class creation.
Change sets
Now you have two change sets in the repository WS ready to be delivered to the stream.
A small arrow shows the current change set
Changes to the same file cannot
be spread over different change sets
Deliver to the stream the outgoing change sets :
Right-click a change set > deliver
The change set disappears from the outgoing folder
Change set operations:
Complete: when you stop adding changes. It is no longer active, you can only change metadata (e.g. name)
Deliver: sends to the stream
Suspend: removes from repo WS and from local WS but
Preserved in the “Suspended” folder so that you can restore it later
If you start working on a change while another task is not complete
Discard: removes from a WS
Usually after an accept from a stream.
Reverse: removes the change set by creating the opposite
of the change set.
Component History
RTM keeps trace of all the change set history of a component.
Pending Changes > Right-click the comp. > Show > History
Add two methods
The first user creates two methods in the StartUp class.
Each method creation goes in a different change set.
Add a method
Right-click Unresolved >
Check-in > New Change Set
Rename the change set
Right-click the change set
> Complete
Create the second method
Right-click Unresolved >
Check-in > New Change Set
Deliver both change sets
Receive incoming changes
The second user sees the two change sets in the Incoming folder.
After inspection you can accept changes
Right-click change set
> Accept
Inspect Changes
You can inspect each change you are going to accept:
Inspect the change: Right-click file > Open in Compare Edit
Inspect the File History
Inspect all the changes of a file for each change set
In the package view Right-click file > Team
> Show Histrory
Double-click on a
change set to compare with the previous version
Locks
Lock a resource in a stream avoids that other developers deliver changes to the same resource while you are
working, leading to incompatible (conflicting) changes:
In the local workspace view: Right-click file > Team > Lock...
Than choose the stream in which you want to lock the resource.
Other users see a lock on those resources.
An arror occurs if a delivery is tried.
Remember to unlock resources when done.
Conflicts
A conflict occurs when two developer try to deliver incompatible change sets.
User1 inspect the code and see that method a() is never called in the component. User1 deletes the method a() and commits.
At the same time User2 adds a method b(). In b()'s body there is a call to a().
When User1 tries to commit a conflict is detected.
Use locks to avoid conflicts.
If it is too late inspect the file changes:
Pending Changes > Right-click a file > Show History
Pending Changes > Right.click a file > Compare With
> Remote File
Baselines
When you have done long sequence of change sets, create a new baseline.
It is a snapshot of the component.
It is delivered as a change
Pending Changes > Right-click component > New > Baseline
Right-click the baseline > Deliver
You can compare baselines among them
You can restore a component to a previous baseline
Pending Changes > Right-click a component > Replace with...
> baseline
Exercise B
User1 creates a new project and add it to your repo WS.
User2 creates its own repo WS and accepts the project creation.
Create some classes and deliver and accept change sets.
Create different methods in the same class.
Visualize the change history.
Try different change set configurations.
Add a test class with Junit 4.
Try: complete, suspend, deliver, discard, reverse.
Compare a file with its previous version before accepting a change set.
Exercise B
Create some baselines.
Inspect the history of a file.
Lock a resource and try to make a delivery from another user.
Create a conflict.
Compare a file with its remote version.
Resources
RTC online help:
http://publib.boulder.ibm.com/infocenter/rtc/v2r0m0/index.jsp
Resources about JAZZ:
http://jazz.net
