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
@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, @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