2019-03-05 TC Meeting notes

Date

Mar 5, 2019

7am PST / 4pm CET

Meeting Link

Attendees

Sebastian Brudziński
Nikodem Graczewski (Unlicensed)
Klaudia Pałkowska (Deactivated)
Joanna Bebak (Deactivated)
Łukasz Lewczyński (Deactivated)
Mateusz Kwiatkowski
Wesley Brown (Unlicensed)
Chongsun Ahn (Unlicensed)
Elias Muluneh
Craig Appl (Unlicensed)
Paulina Buzderewicz

Discussion items

Time	Item	Who	Notes

Time	Item	Who	Notes
5m	Agenda and action item review	Josh
5m	Implementer warning for use of pre-released services	Josh Zamor (Deactivated)	Forum: https://forum.openlmis.org/t/approach-to-database-migrations-versioning/4973/4 Proposed text: Releases may be a pre-release, called a Release Candidate, that precede the final release of a specific version. These pre-releases are generally suited for testing audiences and user acceptance testing and not production environments. It should not be expected that a Release Candidate is either stable enough for production, nor may be upgraded to/from without a loss of data.
10m	Application level caching	Paulina Buzderewicz	Discussion on research connected with work on this ticket: https://openlmis.atlassian.net/browse/OLMIS-6056
	Orderable Edits	Josh Zamor (Deactivated)	Quick update
15m	Regression testing and WIP	Sam Im (Deactivated), Joanna Bebak (Deactivated), Wesley Brown (Unlicensed), Sebastian Brudziński	Summary: Mid-release regression testing is performed by QA team, to find big (blockers and critical) issues early Problem: We have a large number of big issues caused by things that are in-progress (e.g. can't go to convert to order screen) Solution: Could have a separate environment with an appropriately snapshot state of the code that's suitable for regression testing, which doesn't have all the in-progress sawdust. Concern: Wouldn't have latest changes for the 1-2 weeks testing goes on. Usually QA team is doing this as their lowest priority so it takes a bit of time.

Notes

Implementer warning

Releases may be a pre-release, called a Release Candidate or SNAPSHOT, that precede the final release of a specific version. These pre-releases are generally suited for testing audiences and user acceptance testing and not production environments. It should not be expected that a Release Candidate is either stable enough for production, nor may be upgraded to/from without a loss of data.

Application Level Caching

https://openlmis.atlassian.net/browse/OLMIS-6056
Supervisory Node chosen as it looks complex enough - see if the cache makes a change
Redis library, 2 approaches:
- Manual Repository level, RedisTemplate, with hash oriented lookups - manual calls to Redis
  - More control
    - Store / invalidate management imperative over declarative
- Redis Cache manager: Using cache annotations so that Spring framework handles calls to Redis
  - Less code written
  - support in spring boot 1.x? Will be looking at that in current ticket.
Redis doesn't support complex relations - it's a key-value store
- Deeply nested resources
- Invalidation from deeply nested entities is more possible with manual control - however not recommended

Regression testing and WIP

- See above summary
- For possible solution
  - If we had more people testing, then this might work better (as testing would be faster and so total time in testing is less)
  - Ask in QA / help slack channel if bug just found is really a regression or if it's from a WIP
- Is there a middle ground where UAT has more finished features than WIP features?
  - Deploy to UAT after each commit, manual process, usually done many times a day when it's seen in dev channel
- One of the main reasons to redeploy UAT is to clear the database for fresh demo data - which also pulls in latest code via SNAPSHOTs

Discuss within Team Parrot and bring back to larger group

Action Items

Josh Zamor (Deactivated) to let Rebecca Alban (Unlicensed) know the text for the update to the implementer guide