What did we do well?
- Zaza joined the team!
- Yauhen helped a lot with test cases
What should we have done better?
- We should update release notes with info about re-index once we know it will be needed for a particular release in advance and not a post-factum.
→ option: ticket for each release + breaking changes (not only mod-search module)
→ option label + comment
- approach for testing complex functionality cross-modules Natalia Zaitseva to create a testing ticket for MODSOURCE-550
- breaking changes should be communicated via meeting in addition to slack, jira, email. + instruction for merging back-end and front end changes
- create test issue for complex issues like MODSOURCE-550
- created FAT-4197
- Natalia Zaitseva to think about general flow when breaking changes appear and propose it to the team
- Natalia Zaitseva to think about flow for mod-search re-index flow (additional label + Jira ticket for release notes update)
- Natalia Zaitseva to create Complaints and Suggestions board/page → created page for R1 2023
- Natalia Zaitseva to move action points from previous Retros → copied items for 2022 year
- Natalia Zaitseva to create a board with visualised info related to issues found for Nolana Bug Fix and Morning Glory HF#1
To reduce number of issues in mod-search, feature UXPROD-3963 created, based on recommendations ElasticSearch Reindex Performance Recommendations
- Natalia Zaitseva to discuss the option with substitution of integration tests with unit tests (add it to Oleksii's Petrenko retro board + add Pavlo to discussion) → added point to Folio Release Board
- Radhakrishnan Gopalakrishnan (Vijay) to work on point related to mod search
- it would be profitable for the team to have single point for mod-search requirements + test cases that should always work. As a possible option - sync up between Prokopovich PO and Spitfire (possibly Valery + Pavlo+ Vijay) to summarise/clarify
- Spitfire team should be notified about reindex results, here are possible actions:
- Make sure release notes are up-to-date two weeks before the start of bugfest
- Test MARC authority mapping rules prior to bugfest
- If the team has to investigate an issue that is more than an hour and is not a part of any other ticket, then create a ticket and include in current sprint OR backlog.
- When requesting PTF testing - Change the status to Blocked when first version is buggy and requires additional development effort
- Natalia Zaitseva to track Java 17 update for Orchid
The update to Java 17 and Spring Boot v3 covered by short-term created team in scope of FOLIO-3648
- review current DoR and DoD and our related processes
- too long preparation of Vagrant box for schema upgrade testing. We should think about other approach for this testing (local Docker, Rancher)
- Vagrant boxes are using for local testing now, but there is so much problems and restrictions with Vagrant (using a lot of resources: at least 15gb of RAM, impossibility of using new versions of Docker, new versions of VirtualBox could cause crashes of box, impossibility of using some useful for development features on Windows like WSL, a lot of time for up and run box, complicated procedure of module deployment). We should think about other approach for local testing (docker compose that will up infrastructure, auth-modules and only needed business modules)
- mod-quick-marc logging should be improved
- each feature should include Karate tests
- self-evaluation document misleading (based on Module acceptance criteria template I tried to create a PR in that repo, but self-evaluation results should instead be saved in an online Word document and the link added to technical evaluation Jira ticket)
- some failing tests related to Karate tests still appear