Code Delivery Process - quality-manager/onboarding GitHub Wiki

Code Delivery Process

Delivering code requires a process which must be followed each time the code is modified for an update, patch, fix, enhancement, or addition.

Prerequisites

  • IBM Intranet ID
  • Jazz.net ID Registration
  • Repository and Project Area Access
  • RTC Client Setup
  • Access to a Development Work Item

Understanding The Task and Work Flow

Though the interface for work items is unified, items such as defects, tasks, and enhancement contain details that are specific to each individual instance. Team Leaders review work items and set specific areas based on analysis, such as Severity, Priority, Planned For, Owned By, Status to Triaged, and what week the work item will be worked on.

Ensure Work Item is Reproducible

Before any work starts on a pre-existing work item, work items must be up to date, reproducible (if they are a defect), and on the most recent build.

Steps

  1. Ensure that the work item is up to date with the most recent build. If the work item is not up to date, update the Work Items with the findings in the comments, and then resolve the work item.

  2. If the work item is up to date and a defect, ensure that the problem is reproducible.

  3. To reproduce a defect, follow any instructions in the description box and comments left by the creator of the work item. Be sure to observe any attachments left by commentators and the creator. All work items should include the steps to reproduce the symptom or a system where the symptom is reproducible. If there is any confusion about how to reproduce a defect, ask questions in the comments.

  4. If it can be reproduced on the latest build, move forward. If it is not reproducible, update the work item with your findings and obtain further information on how to reproduce the defect. If it is not reproducible after further information is obtained, resolve the work item.

Begin Work on Work Item

Complete the requirements for the work item, such as resolving and fixing an issue related to a defect, patching the code, enhancing a feature, etc.

Steps

  1. Begin working on the work item, and change the item state to “in progress”.
  2. If the work item is a Translation Verification Test case, please review the steps at https:// github.com/quality-manager/onboarding/wiki/TVT-Cases before moving forward.
  3. Update the Estimate and Planned for fields to indicate how much time is allocated to the task.
  4. Observe the history of the code being modified. Every time a file is modified and saved, the developer gets changes in the ‘Pending Changes >> Unresolved changes’ directory. If you don’t see the pending changes tab, open it by going to window >> show view >> other >> Jazz Source Control >> Pending changes. Changes are marked by yellow highlights in the Pending Changes tab. If you don’t see your changes, refresh the Pending Changes view.

Create a Change Set and Check in Changes

Before code can be delivered to the Quality Manager Mainline stream, it must be added to a change set, updated as changes occur, and attached to its subsequent work item. To do this, you must check in your code to a change set.

Steps

  1. Find your changes in the Pending Changes view, and right click them. Hover over Check in, and select New Change Set. ⁃ Ensure you leave a comment on the change set summarizing what was changed.
  2. If you make any changes to the code associated with the change set, the changes will appear in the Unresolved Changes directory. ⁃ The code’s history compared to remote versions can also be viewed in this menu. ⁃ Any further modification of the code must be checked into this change set before it can be delivered. Associate Change Set to a Work Item

Associate your changes with a work item

All changes must be associated to a defect

Steps

  1. After creating and checking in the change set in, the change set item will appear in the Pending Changes view. Right click on the change set item to view its options.
  2. Navigate to Related Artifacts at the bottom, and select Associate Work Item.
  3. In the search menu that appears, search for the work item associated with the code and link the items
  4. Observe that the change set is now associated with the appropriate work item before moving forward. Tip: You can set the work item as your ‘current work item’ so change sets are automatically associated with the work item.

Testing your code before sending to review

Testing The Code Before asking others to review the code, ensure that it has been thoroughly tested in and around the area the code has modified.

Steps

  1. Manually test the changes in and around the functional area that it was updated.
  2. Execute the RQM JUnits (AllRqmUnitTests.java). ⁃ If the change is in the RQM Reportable REST API and/or OSLC QM V2 API, the API JUnits must be run.
  3. Add a comment with details regarding the the testing performed in Resolution tab "Verification steps".

Complete your change set

Complete the Change Set Once you have gone through the process of developing, testing, and reviewing the code, you may complete the change set in order to have others test it during the review process.

Steps

  1. Navigate back to the Eclipse workspace’s Pending Changes view.
  2. Mark the Change Set in the Eclipse Pending Changes view as Complete.
  3. Change sets should be complete before requesting a review so the reviewer can accept the change set(s) into their local workspace.

Review Process

Before your code can be delivered, it must be reviewed and approved.

Steps

  1. Ensure that your most recent changes are checked into the change set.
  2. Once the code meets the requirements for the work item and passes initial testing, be sure the code is saved, up to date, and the change set has the most recent changes.
  3. Thoroughly test and ensure the code passes the Unit, Integration, and Impact tests before moving forward.
  4. After testing, navigate to the Approvals tab in the relevant work item in either the development Web UI or the Eclipse Work Item View
  5. Create a new approval, and assign a type, such as Code Review, add a TL approval for the ETM Development Team Lead.
  6. Create a new review and assign a type, such as Code Review with one reviewer.
  7. Update the "Change summary" and add a paragraph describing the changes you did.
  8. During a shutdown week, or if the fix is complex/broad, two reviews might be required.
  9. Select developers with expertise relevant to the code’s area to review the code.
  10. Set the work item to status "In review"
  11. If the code is rejected Make the required modifications to the code based upon the reviewer’s comments Check in the modified files to the change set. Update the comments with information pertaining to the changes made. Resubmit the change set for approval and change the work item to "In review".
  12. If the code is approved, test the code one last time to ensure quality

Deliver to Mainline

Deliver to RQM Once you have gone through the process of developing, testing, and reviewing the code, you may complete the work item and deliver your change set to RQM.

Steps

  1. Before delivery, remove any  or characters from the copyright statement (see https:// jazz.net/wiki/bin/view/Main/CspfIdeSettings#Copyright_Statements_and_Broken).
  2. If you are working on a Translation Verification Test, ensure you have followed the TVT steps necessary for delivery before continuing: https://github.com/quality-manager/ onboarding/wiki/TVT-Cases
  3. Update the copyright year of all files to reflect current changes.
  4. Navigate back to the Eclipse workspace’s Pending Changes view. 5. Right click the approved change set and select “Deliver”.
  5. If all steps have been followed and the change set has met all reviews with the approved status, the code will be delivered to RQM. If not, the UI will alert with any discrepancies. Note: You must have the authorized rights granted in order to deliver code.

Resolving the work item

Before resolving the work item, update the “time spent” field to reflect the amount of time spent working on the work item, set the "Delivered to Stream(s)" to mark the streams you delivered your changes to, also add any modifications to "Change summary" caused by the review process.

Steps

  1. Add a any changes in "Change summary" in "Resolution tab".
  2. Add a comment in "Verification steps" describing the steps someone would take in order to verify that you indeed fixed the problem.
  3. Add a comment in "Test strategy" describing the steps you took in order to assure that your fix works.
  4. If this defect has an APAR associated, also update the "APAR Information" include all the special considerations if this defect were to be back ported to a previous release.
  5. Once the code is delivered to RQM, update the Work Item’s status as Resolved based upon the delivery.
  6. Set the resolution type label, which should be set appropriately for how it satisfies the work item: Duplicate: A defect with the same recreation steps is already open.
  • Fixed Indirectly: The defect is similar or the same, but has different recreation steps.
  • Works as Designed: The product is doing what it was designed to do.
  • Not Supported: The defect cannot be reproduced on supported components, and there is a reasonable view that the defect is due to that unsupported component.
  • Finished Troubleshooting: A defect raised due to environmental or configuration issues, or the raiser did not follow documentation. Should only be raised when there is no necessary changes to the product or documentation.
  • Not Enough Information: Used where the defect cannot be recreated because we do not have accurate information, logs were not provided, or some other context is missing. ⁃ Resolved Elsewhere: If the defect lies with a different team or third party and must be raised in a different repository or system. ⁃ Fixed: Fixed and delivered to a stream.
  • Won’t Fix: Accepts that a behavior described is a defect, but due to other reasons, will not be addressed in any foreseeable release.
  • Fixed: The defect has been fixed and code has been delivered

Priority order:

P3 Low -> P2 Medium -> P1 High

Severity order:

S1 Blocker -> S1 Critical -> S2 Major -> S3 Normal/P1 High -> S3 Normal/P2 Medium -> S3 Normal/P3 Low

Run team

Run Team Members are expected to work on their defects in severity/priority order, and are responsible for setting the estimate, time spent, and resolution status of their work items.

Some of the run team activities are:

  • Fix non-feature based defects
  • Monitor forums
  • Conduct code reviews.

Run Team members are encouraged to work on defects outside their area of expertise and functional components/sub-components to increase the cross-pollination of developers and breadth of skills. Technical Leads are available for answering technical and architectural questions.