Uploaded on

A scenario demonstrating the usage of Rational Team Concert for System i. This is a tool set for building team collaboration around RPG, COBOL, CL, and DDS assets.

A scenario demonstrating the usage of Rational Team Concert for System i. This is a tool set for building team collaboration around RPG, COBOL, CL, and DDS assets.

More in: Technology , Sports
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,795
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
27
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. • Kenny Smith • Principal Consultant Rational Team Concert for i Demo Scenario 1
  • 2. Overview • This presentation is designed to take you through a demonstration scenario of usage with Rational Team Concert for System i • For an interactive demo, please refer to the Enterprise Modernization sandbox for i • You can also try out the software directly from http://Jazz.net www.StrongbackConsulting.com 2
  • 3. A sample lifecycle: How do we collaborate? Sample scenario - Business Executive sends a request to the IT department, which involves a change to a composite application with business Logic change with RPG components and web presentation change with EGL components Check Business Request Approval Project Status Approve Enhancement Throughout the changes Executive Project lifecycle Divide work into Approve Create Approve Check progress tasks, schedule the Code review/ Upgrade to Dev/Proj Mgr - George Enhancement release plan, and Technical approval on iteration Production Work Item Design plan assign to system Developers/groups Design Request Deliver RPG Developer - Joe changes Design Code changes Functional to Approval Testing components Design Request changes Deliver Functional Design EGL Developer - Joe to Approval Code Changes Testing component Approve System Analyst Technical Design Create requirements End User Approve Integration Testing Technical Design Schedule Promote/Build And Deploy Sys Admin/Builder - Robin Testing Integration Enhancements Steam To Production System www.StrongbackConsulting.com
  • 4. Sample Application 1. Web application provides a web interface to view “Customer Information” stored on IBM i. www.StrongbackConsulting.com
  • 5. Sample Application (continue) 1. RPG component 2. EGL Component www.StrongbackConsulting.com
  • 6. RTCi Web Interface 1. Web Client Log In 2. Web Client Menu provides the following tabs: ProjectArea, WorkItem, DashBoard, Iteraltion Plan, Source Control, Report www.StrongbackConsulting.com
  • 7. Define Requirement www.StrongbackConsulting.com
  • 8. Demo Scenario – Executive Submits a New Requirement 1. Business executive submits a Story Work Item about a potential new requirement via RTC web interface – Project Dash Board. 2. Fill in the description of the idea and pick the product group/team that the Work Item is filed against. 3. Select Link tab to attach any files (screen capture, article and etc), also add user names who will be notified about this new requirement Work Item. 4. Assign to the system Analyst. 5. System Analyst is notified by RTC and via Email. System analyst works with end User and other stake holders. All stake holders add their comments into this Work Item. www.StrongbackConsulting.com
  • 9. Demo Scenario – Executive Approves the New Enhancement An agreement is reached. System Analyst clearly defines the requirements - estimated cost, scope, and impact of existing products. System Analyst requests the approval from Executive. 2. Executive approves the new requirement. 3. System Analyst assigns the Work Item to the Development/Project Manager to work on. www.StrongbackConsulting.com
  • 10. Plan the Work www.StrongbackConsulting.com
  • 11. Demo Scenario – Development/Product Manager Creates an Enhancement The Story develops into a defined Enhancement. 1. Development/Project Manager creates an Enhancement Work Item to implement the newly defined feature. 2. In the Link Tab, add the story Work Item as the parent of this new Work Item. 3. In the Approvals Tab, add executive, end user, system Admin, and etc to the approvers and reviewers list. www.StrongbackConsulting.com
  • 12. Demo Scenario – Development/Product Manager Analyzes the Work A defined Enhancement is divided into multiple tasks 1. Development/Project Manager creates two new tasks. One is against RPG component, the other is against EGL component. Assign each to the appropriate developer and set the release plan. 2. Set the Parent Work Item for both new Tasks. This shows the overall hierarchy of these Work Items. www.StrongbackConsulting.com
  • 13. Demo Scenario – Development/Product Manager Plans the Work 2. Development/Project Manager Plans the release 1. Development/Project Manager sets the peer reviewers for the new Tasks www.StrongbackConsulting.com
  • 14. Feature Development www.StrongbackConsulting.com
  • 15. Demo Scenario – Developer Joe and Mary Accept the New Assignment 1. Dev Joe and Mary are notified by email and log into RTC project area via RTCi and RDi integrated client. 2. Select MyWork Tab to check his/her new work assignment. 3. Dev Joe accepts all works newly assigned to him. Then Joe opens the Work Item and set the Work Item status to Start Working 3. Dev Mary accept sall works that newlyassigned to her. Then Mary opens the Work Item and set the Work Item status to Start Working www.StrongbackConsulting.com
  • 16. Demo Scenario – Stake Holder Approves the Design Documents Dev Joe submits a design document for Project Lead, Dev Mary submits a design document System Analyst, and End and a screen capture of User Interface User’s approval. for Project Lead, System Analyst, and End User’s approval. Project Lead, System Analyst, and End User Project Lead, System approve Joe’s design. Analyst, and End User approve Mary’s design. Dev Joe and Mary start implementation of the Enhancement www.StrongbackConsulting.com
  • 17. Basic Software Configuration Management (SCM) Anatomy IBM i PC Stream Repository Local Workspace Workspace Your changes Other’s changes  Streams are for sharing resources. For example, a Team Development Stream contains all product assets that a team is actively working on.  A repository workspace is your personal space saved in the repository. It is for developer to save intermediate work. It is not visible to other team members until you deliver into stream.  Local workspaces are where you edit resources.  Changes flow back and forth. www.StrongbackConsulting.com
  • 18. Set up/load Local Workspace & Check-in and Deliver from Local Workspace Create Repository Work Space Developer Edit the File Load into Local Workspace Check-in the new file to Repository Workspace Deliver to the Steam to share with other developers IBM i PC Stream Repository Local Workspace Componen Workspace t Eclipse Eclipse Project Project Fil Fil File Fil e e Folde Folde e r r File File Fil Fil e e Folde r Eclipse Project Eclipse Fil Project Fil e e Fil Fil e e Componen t Eclipse Eclipse Project Project www.StrongbackConsulting.com
  • 19. Demo Scenario – Developer Joe Sets up the Work Environment 1. Dev Joe launches the New Repository Workspace panel by selecting My Repository Workspace right mouse menu. 2. Dev Joe selects the right Stream for the RPG component. www.StrongbackConsulting.com
  • 20. Demo Scenario – Developer Joe Loads the Project into Local Workspace 1. Dev Joe selects the RPG Component. 2. Dev Joe selects to Find and Load Eclipse Project (RDi Project) into Local Workspace. This tells RTC to load (copy) RPG project into Joe’s local workspace on his PC. www.StrongbackConsulting.com
  • 21. Demo Scenario – Developer Joe Works on the RDi Project 1. Visualize the RPG application. www.StrongbackConsulting.com
  • 22. Demo Scenario – Developer Joe Works on the RDi Project 1. Dev Joe opens iProject perspective 2. iProject 3. RDi Remote System Explorer www.StrongbackConsulting.com
  • 23. Demo Scenario – Developer Joe Works on the RDi Project 1. Compile the RPG via RDi RSE interface www.StrongbackConsulting.com
  • 24. Demo Scenario – Developer Joe Works on the RDi Project 1. Debug the application www.StrongbackConsulting.com
  • 25. Demo Scenario – Developer Joe Checks-in & Delivers the Change 1. Dev Joe opens RTC Work Item (RTC) perspective. Select the Pending Change tab and expand the component tree. Notice the => icon in the Pending Change tab. This means new change in your local workspace needs to be checked-in to repository workspace and delivered into the stream. 2. Dev Joe launches Check- in Panel by selecting the right mouse menu. www.StrongbackConsulting.com
  • 26. Demo Scenario – Developer Joe Works on the RDi Project 1. Process forces “A work Item must be associated with the change set”. 2. Click “Associate Existing work item” to pick a Work Item. www.StrongbackConsulting.com
  • 27. Demo Scenario – Developer Joe Works on the RDi Project 1. Process forces that the change set must be reviewed before it can be dlivered into the Team Integration Stream. www.StrongbackConsulting.com
  • 28. Demo Scenario – Reviewers and Approvers Review the Change Dev Joe updates the Work Item. Approvers and Reviewers are notified by RTCi and via Email. 1. Project Lead and Other RGP developers review the change. To see the Change Sets, open the Work Item and select Open the Change Sets in the Links Tab 2. Selects the element/file and Open in Compare Editor to compare the changes made by Joe line by line. All reviewers approve the change. www.StrongbackConsulting.com
  • 29. Demo Scenario – Developer Joe Checks-in & Delivers the Change (Continue) 1. Dev Joe selects the Work Item and finishes the Check- in and delivery. This associates the Work Item with that Change Set Notice: If there is a conflict – the file Joe is about to deliver has been modified by other developers, RTCi will ask Joe to merge the change. www.StrongbackConsulting.com
  • 30. Demo Scenario – Developer Joe Resolves the Work Item 1. Dev Joe is notified that his change is approved. 2. Dev Joe opens the Work Item by select the Work Item 3. Dev Joe Resolves the in Work Items Tab Work Item. www.StrongbackConsulting.com
  • 31. Demo Scenario – Developer Mary Works on the EGL Project 1. Developer Mary creates the Repository Work Space and loads the project into her Local Work Space. 2. Developer Mary opens EGL perspective and opens EGL project. 3. Mary is notified that Joe has delivered his RPG component changes. So Mary can test her change. 4. Developer Mary finishes the code change and tests in the Sand Box. 5. Developer Mary Checks-in and Delivers the code change. ** Notice: Develop Mary does her work in parallel with Developer Joe. This slide continues from slide 15 – Stake Holder Approves the Design Document. www.StrongbackConsulting.com
  • 32. Demo Scenario – Developer Mary Checks-in and Delivers the Change 1. Developer Mary Checks-in and Delivers the change. 2. Developer Mary updates the Work Item. 3. Reviewers and approvers are notified by RTC and via Email. 4. Reviewers and approvers approve Mary’s code change. 5. Developer Mary Resolves the Work Item www.StrongbackConsulting.com
  • 33. Builder Promotes Change from Team Dev Steam to Testing Integration Stream IBM i PC Team Development Stream Joe’s Repository Workspace Joe’s Local Workspace RPG Component Deliver RPG Component Check-in RPG Component Joe’s Change Joe’s Change Joe’s Change Joe’s Change Deliver Mary’s Repository Workspace Mary’s Local Workspace Check-in EGL Component EGL Component EGL Component Mary’s Change Mary’s Change Mary’s Change Mary’s Change Accept Changes Testing Integration Stream Robin’s Repository Workspace Robin’s Local Workspace RPG Component RPG Component RPG Component Joe’s Change Load Joe’s Change Joe’s Change Joe’s Change Deliver Build EGL Component EGL Component EGL Component Mary’s Change Mary’s Change Mary’s Change www.StrongbackConsulting.com
  • 34. Demo Scenario – Builder Robin Sets up the Work Environment streams Team Development Stream Testing Integration Stream Repository WorkSpaces Builder EGL Workspace Builder RPG Workspace Builder Robin Accepts Incoming Changes from Team Develop Stream www.StrongbackConsulting.com
  • 35. Demo Scenario – Builder Robin Sets up the Build Environment 1. Builder Robin defines a Build Engine. 2. Build Robin starts the Build Engine from IBM i system. www.StrongbackConsulting.com
  • 36. Demo Scenario – Builder Robin Launches the Build 1. Builder Robin submits the Build Request. 2. Builder Robin checks the Build Result. In this case, the integrated build failed. 3. Builder Robin finds out that Joe’s change breaks the build by opening the Change Sets link in build log. www.StrongbackConsulting.com
  • 37. Demo Scenario – Builder Robin Analyzes the Build Log Team is notified of integration build failure. Joe is notified of the newly assigned blocking defect. 2. Joe starts working on the blocking defect and fixes the error in his Local Workspace, then checks-in and delivers into the Team Dev Steam. 3. Builder Robin accepts the Joe’s change. Then launch a new build. The build succeeds. www.StrongbackConsulting.com
  • 38. Demo Scenario – Builder Robin Analyzes the Build Log (Continue) 1. The team is notified with the latest build result via RTC and Email. 2. A new release is created for End User to do Integration Testing www.StrongbackConsulting.com
  • 39. Demo Scenario – Executive Approves to Deploy to Production End User is notified that a new release candidate is available for testing. End User tests the release and updates the Work Item with successful testing result. Executive is notified about the testing result. Executive approves the deployment to the production. Release is deployed to the production. Work Item is updated with the final result. Product/Development Manager resolves the Enhancement Work Item. www.StrongbackConsulting.com
  • 40. Additional Features www.StrongbackConsulting.com
  • 41. Executive Checks Work Item Status via Dash Board Executive checks the progress of this Enhancement anytime during the development process by checking the history of Work Item via Dash Board. RTCi saves the Recently Viewed record on the server. This helps Executive check only Work Items he/she is interested in. Executive can also find other related Work Items via Links Tab. Personal reports can be created for Executive’s convenience. Personal queries can be created for Executive’s convenience. www.StrongbackConsulting.com
  • 42. Executive/Project Manager Checks Project Status via Project Dash Board Notice: Project Dash New Work Items by Severity Board is highly configurable for every project. Closed Work Items by Priority Blocking Work Items Open Work Items by Type www.StrongbackConsulting.com
  • 43. High Traceability of RTCi All related Work Items are linked, from Story to Enhancement, from Enhancement to Tasks. Each Task includes a complete list of Change Sets. Each Change Set includes the detail information for Auditing and other purposes. The time ,the person makes the change, and what are changes are all recorded. www.StrongbackConsulting.com
  • 44. High Traceability of RTCi (Continue) Work Item includes the complete history of the Task. For each Change Set, you can open the line by line file comparison. www.StrongbackConsulting.com
  • 45. Resources • Our blog site – search on RTC or System i: – http://blog.strongbackconsulting.com/ • Jazz Team site for Rational Team Concert – http://jazz.net/ • RTCi hub – http://bit.ly/2lhEGk www.StrongbackConsulting.com