2019-03-05 TC Meeting notes

Owned by Josh Zamor
Last updated: Mar 05, 2019

Date

7am PST / 4pm CET

https://zoom.us/j/211353423

Attendees


Discussion items

TimeItemWhoNotes
5mAgenda and action item reviewJosh
5mImplementer warning for use of pre-released servicesJosh Zamor

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.

10mApplication level cachingPaulina Buzderewicz

Discussion on research connected with work on this ticket: 

OLMIS-6056 - Getting issue details... STATUS


Orderable EditsJosh ZamorQuick update
15mRegression testing and WIPSam 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

  • OLMIS-6056 - Getting issue details... STATUS
  • 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

Next:

  • Discuss within Team Parrot and bring back to larger group

Action Items

OpenLMIS: the global initiative for powerful LMIS software