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. 2
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. 3
Project teams as team areas The structure of the project teams is defined by one or more team areas. Users might have multiple assignments that require them to work on more than one team. Typically, one or more teams are assigned to each line of development. 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. 4
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. 5
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 within the project area. 6
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. 7
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 iteration and tracked in an iteration plan. 8
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. 9
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. 10
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. 11
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. 12
Project Release Plan A Project Release plan is the highest-level plan in RTM that provides a brief overview of the project goals. Although you can create a Project Release plan for any iteration, it is advisable to create a Project Release plan for the top iteration. 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. 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. 13
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 14
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. 15
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. 16
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. 17
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. 18
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. 19
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. 20
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. 21
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 22
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, 23
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. 24
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. 25
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. 26
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. 27
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. 28
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. 29
Connect to Project Area Connect to the Tutorial1 project area. Team Artifacts > Repository Connections > Connect to Project Areas... 30
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 31
Tutorial 1 Project Area Tab A WorkItem category is added as a default. This will be the filed against property. 32
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. 33
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. 34
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 / 35
Time Infos Time informations can be used to track the progress of the project. 36
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. 37
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 38
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. 39
Exercise A Create a timeline with the MyAMDD process. 40
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 41
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. 42
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. 43
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. 44
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. 45
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 46
Repository Workspaces The repository workspace appears in the Pending Changes view with: The target stream The components in the repository workspace 47
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) Select the resources to version 48
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. 49
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. 50
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. 51
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 52
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 Discard: removes from a WS 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 Usually after an accept from a stream. Reverse: removes the change set by creating the opposite of the change set. 53
Component History RTM keeps trace of all the change set history of a component. Pending Changes > Right-click the comp. > Show > History 54
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 55
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 56
Inspect Changes You can inspect each change you are going to accept: Inspect the change: Right-click file > Open in Compare Edit 57
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 58
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. 59
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 60
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 61
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. 62
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. 63
Resources RTC online help: http://publib.boulder.ibm.com/infocenter/rtc/v2r0m0/index.jsp Resources about JAZZ: http://jazz.net 64