Page Comparison

Goal:  Release 3.3

Dates: 26 Apr 2018 - 09 May 2018 

Questions for team: What do we need to do to get closer to continuous delivery?

Editing Orderables

Josh: would this UI be helpful for the product registry?

...

Performance Testing & Resolution:

• Single approve - the fix doesn't quite get us to the performance guidelines. What else could we do?
  • Our baseline for single approve is ~20 seconds overall, so that is what we are aiming for in order to say we have comparable performance. looking at the 3.3.0 numbers, our median value looks to be about ~40 seconds before any fix, so in order for us to get down to ~20 second baseline, we need to reduce by about 15-20 seconds, meaning the “fix” should ideally get down to the low single digits
  • Any solution will require a regression of all requisition test cases (and maybe convert to order).
  • Research, collect and record results. Solutions to single approve performance should be reviewed by Sebastian. The goal is to match the baseline or increase performance without impacting too many services which would cause more regression testing.
• Convert to order - We need to prove we didn't degrade in performance.
  • Everyone needs to test and update performance page with results (testing one convert to order, multiple (8 to compare to baseline) convert to orders, multiple times)
    • 3.2.1 baseline for convert to order:
      Convert 8 requisitions: 20s (POST /convertToOrder 15s, GET /requisitionsForConvert 2s)
      Convert 1 requisition: 6s (POST /convertToOrder 3s, GET /requisitionsForConvert 2s)
  • Once we do some testing and get several more data points, then analyze if performance has gotten slower and if so, what is causing it
  • Analyze convert to order logic and determine solutions to speed it up. Solutions to convert to order performance should be reviewed by Sebastian. The goal is to match the baseline or increase performance without impacting too many services which would cause more regression testing.

• Additional notes:
  • Sebastian Brudziński - one thought could be to make supply line configuration change for supervisory nodes (which we recently did for Malawi) in perftest. Do we think that may have an impact on the performance results in perftest when comparing to our baseline?
  • Sebastian Brudziński - an option is to spin up a 3.2.1 server with same MW perftest data to be able to compare with 3.3 perftest for the convert to order (Chongsun writes up instructions on how and why)
    • Only if we don't get consistent results on 3.3 perftest
    • If we don't get consistent results, then we can try to see if we don't get consistent results on 3.2.1 perftest, and if so, we can say we didn't degrade because there is no consistent baseline for 3.2.1
  • Jakub Kondrat can move forward with creating tickets for 

    Jira Legacy
    server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-

...

• • 3498

     and replicating to other services.
  • Chongsun Ahn (Unlicensed) will support all performance testing questions and feedback (Josh is out on Thursday).

Team Parrot

Stock Reason Tagging

Epic link: 

Nikodem Graczewski (Unlicensed): Mary Jo Kochendorfer (Deactivated) we would like to make this epic our Sprint Goal if that sounds right to you. This means that tickets from this epic would have the highest priority in the Sprint.

•  

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-3317

Demo Data

...

• 4599

•  Q: 

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4598

•  Q: 

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4597

•  

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-

  4493

  4600

•  (Team ILL) 

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-

  4503 (Team ILL)

  4623

•  

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-

  4491 (Team ILL)

  4622

Stock Based Requisition

Epic link: 

Dependency diagram:  https://www.lucidchart.com/publicSegments/view/71af4a62-0bea-4245-9005-3461919c9d35/image.png

Sebastian Brudziński we would like you/Team Parrot to own these epics just like you did with the POD work after you were in Seattle.Dependency diagram:  https://www.lucidchart.com/publicSegments/view/71af4a62-0bea-4245-9005-3461919c9d35/image.png

Nikodem Graczewski (Unlicensed): This epic needs to wait for 

Editing Orderables

Josh: would this UI be helpful for the product registry?

•  

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-3884

  (from epic OLMIS-3804; important for Malawi and for core) (Josh and Nikodem Graczewski (Unlicensed) to review AC)

Demo Data

Josh please add ticket here, and flag which are for Team ILL/Parrot:

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4493

   (Team ILL)
•  

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-

...

• 4503

  (Team ILL)
  
•  

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-

...

• 4491

  (Team ILL)

UI

•  

  Jira Legacy
  server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-3799

Other?

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4527

  Should we do this? Nikodem Graczewski (Unlicensed): Looks like this issue has been resolved. I've marked this ticket as "Dead".

Bugs and Tech Debt

Sebastian Brudziński We would like to start a new process where a percentage of every sprint is set aside for Bugs and Tech Debt. For bugs we propose 20% of the sprint, and you would pull in bugs from the prioritized bug list that Team ILL maintains either on these wiki pages or directly from the Jira backlog (Sam Im (Deactivated) will provide the list). For Tech Debt we propose you/Team Parrot choose what items add the most value (Josh Zamor has ideas about how to get this started).

Team has groomed and estimated Tech Debt for this sprint:

Bugs

Sam Im (Deactivated) and Mary Jo Kochendorfer (Deactivated) to prioritize bugs and add to this sprint.

Notes on what we should focus on next:

...

• Strengthen process for continuous delivery (including automated testing)
• Performance improvements and testing
• Technical debt and user documentation

...

• Dashboards and reporting (across levels)
• Interfaces to external systems (potentially includes ERP, mobile, and offline applications)
• Requisition enhancements (favoriting products, columns, usability improvements)
• Budgeting
• Fulfillment and re-supply features and enhancements
• User personalization and self-service (configuration, notifications, dashboards)
• Equipment tracking
• Note: Gap features will begin during 3.4 release cycle, but will continue for the year of the Gap project. Gap feature prioritization will determine which of these features are conducted within the current Gap project budget and timeline.

...

Team Ona

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4631

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4634

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4635

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4638

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4651

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4652

Team ILL

Team ILL still needs to conduct spring planning for 52.

The following were notes and was communicated at the top of the page

• Team Parrot will start Sprint 52, but will focus on fixing the performance issue for single approve, and performance testing for convert to order. The main goal is to demonstrate/repair that we have NOT degraded in performance.
• Sprint Q&A: Team Parrot will discuss the performance testing results and day's status.
• Performance Testing & Resolution:
  • Single approve - the fix doesn't quite get us to the performance guidelines. What else could we do?
    • Our baseline for single approve is ~20 seconds overall, so that is what we are aiming for in order to say we have comparable performance. looking at the 3.3.0 numbers, our median value looks to be about ~40 seconds before any fix, so in order for us to get down to ~20 second baseline, we need to reduce by about 15-20 seconds, meaning the “fix” should ideally get down to the low single digits
    • Any solution will require a regression of all requisition test cases (and maybe convert to order).
  • Convert to order - We need to prove we didn't degrade in performance.
    • Everyone needs to test and update performance page with results (testing one convert to order, multiple convert to orders, multiple times)
    • 3.2.1 baseline for convert to order:
      Convert 8 requisitions: 20s (POST /convertToOrder 15s, GET /requisitionsForConvert 2s)
      Convert 1 requisition: 6s (POST /convertToOrder 3s, GET /requisitionsForConvert 2s)
• Additional notes:
  • Sebastian Brudziński - one thought could be to make supply line configuration change for supervisory nodes (which we recently did) in perftest. Do we think that may have an impact on the performance results in perftest when comparing to our baseline?
  • Sebastian Brudziński - an option is to spin up a 3.2.1 perftest, and have the 3.3 perftest for comparison for the convert to order (Chongsun writes up instructions on how and why)
  • Jakub Kondrat can move forward with creating tickets for 

    Jira Legacy
    server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-3498

     and replicating to other services.
  • Research, collect and record results. Solutions to single approve performance should be reviewed by Sebastian. The goal is to match the baseline or increase performance without impacting too many services which would cause more regression testing.