2021-04-28 Capacity Planning Meeting

• Waiting for Vega to release pubsub changes, which should happen today. 
• MODINVSTOR-521 has been performance tested; Bohdan is running the process now on Iris and says the migration script takes 5 hours to run.

Two planned hotfixes
May 28th and June 28th

What about P1s after June 28? 

We planned Juniper before we were told that we should focus on bugs and integrated tests.  This means that many features planned for Juniper will not actually get completed, but they are still marked with a Fix Version of R2 2021.  When I created the pointing exercise "ballot", I excluded everything with a Fix Version of R2 2021.  The end result is that I excluded features from pointing that are not going to be completed in Juniper and therefore should have been part of the pointing exercise.  We need to make sure the community knows which features will not be completed in Juniper, plus we need to figure out what to do about the former Juniper features that were not pointed but are important. 

Features planned for Juniper that do not make it, will be automatically scheduled into Kiwi. There is no need to re-prioritize or point these features. ie they do not need to be in the pointing exercise. 

These should be assigned the "at risk label"

• Bugs have to be submitted to CP for approval during CP meeting.
  • If you have a hot fix candidate, please make your submission at the release-bug-triage Slack channel before work commences. 
  • All requests for hot fixes need to be approved by the Capacity Planning Team at their regular Monday 9:00 AM US EST meeting.  Please submit your request to the release-bug-triage Slack channel by noon on Friday (US EST) to give the Capacity Planning Team members time to review the request. 
  • The requestor must attend the Capacity Planning Team meeting in person to present their case.  The Capacity Planning Team meets on Monday’s at 9:00 AM US EST.   Approvals will be granted at the meeting so that the Capacity Team can review the decisions, impacts and implications in aggregate. 
  • If there is something urgent, an out of cycle Capacity Planning Team meeting should be requested.  At the meeting, there should be at least 3 permanent members of the Capacity Planning Team to grant an approval.
  • Seeking approvals via Slack channel should be avoided.
• Acceptance criteria for including a bugfix in a hot fix release
  • Candidates should be P1 or P2
  • HotFix requires a patch version to be released
  • Issue reported from an institution already on Iris OR an issue blocking an institution from going live with Iris and unable to wait until Juniper
  • All testing should be performed according to Definition of Done
  • Release should be deployed in BUGFEST env and verified there

Problem statement:
Ideally - Automated testing would provide significant test coverage and reduced reliance on manual testing. 

Currently - Manual testing occupies an ever growing chunk of SME and PO time, occurs late in the dev cycle and is reaching the upper limit of possibility, we are running out of testers, even as functionality requiring testing increases.  At the same time POs and Dev teams has even more requirements for functionality and less time to set up automated tests. 

Bugfest and Smoke test process is unsustainable at current level.  Release quality and platform stability could be significantly enhanced by automated tests -ie  the unit tests  executed when the new code is being committed and the automated smoke would run after a module is upgraded, but POs and Dev teams do not have time to create tests. 

Proposal: - Schedule PO and dev capacity to include automated test creation in exchange for reduced manual tests. 

Automated smoke tests will run daily, and stop need to manual testing

Karate tests are backend tests - so building those will also reduce some bugs discovered

Any functionality that is to be delivered is to include automated tests.