Versions Compared

Old Version 3

changes.mady.by.user Josh Zamor

Saved on

compared with

New Version Current

changes.mady.by.user Josh Zamor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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: 

Jira Legacy
serverSystem JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId448ba138-230b-3f91-a83e-16e7db1deed1
keyOLMIS-6056


Orderable EditsJosh ZamorQuick update
(next time)15mRegression testing & environmentsand WIPSam Im (Deactivated), Joanna Bebak (Deactivated), Wesley Brown, Sebastian Brudziński
  • UAT, QA, Regression testing and RCs.

Notes

Action Items

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

  • Jira Legacy
    serverSystem JIRA
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-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

Next:

  • Discuss within Team Parrot and bring back to larger group

Action Items