Versions Compared

Old Version 1

changes.mady.by.user Mike Gorrell

Saved on

compared with

New Version Current

changes.mady.by.user Mike Gorrell

Saved on

Key

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

...

Attendees

Discussion items

TimeItemWhoNotes

UI Testing Framework recommendations

Zak Burke

UI Testing Team

has made a recommendation Performance

 has made a recommendation - these decisions are being documented based on meeting/agreement yesterday.

  • Jest and React Testing Library (RTL) for Unit Tests - community standards, high level of support, existing knowledge for developers.
  • BigTest v2 for Stripes components - want to see them run in a real browser. Others don't due testing in real browser. Frontside will contribute some resources to build out these tests. 
  • BigTest v2 for End to End - work with POs to have them identify cases in TestRails and automate some of the ones that previously were done by hand.

Allows us to invest in relationship with BigTest, but not put all of our eggs in that basket. There are some compelling things in BigTest v2 which we would like to see take off (e.g. testing directly in browsers, testing responsive design) so are willing to take some risk. 

Migration: current BigTest v1 tests will migrate to RTL; still need to create tickets for this work, make estimates, and work into backlogs.

For Stripes, will migration BigTest v1 to BigTest v2, and FrontSide will dedicate some resources to help with this, similar for End-to-End testing.

See also: 2020-09-01 UI Testing Team Meeting Notes

What if a team wants to use a different testing framework? Not advisable, want to minimize tools so that it is easier to move between modules.

Currently have some Cyprus tests as part of the research spike, will need to allocate resources to migrate those to Jest or RTL.


Performance Taskforce (PTF) Environment request

Mike Gorrell  

 PTF has asked that the community start the process to take over the EBSCO/FSE-built environment they've been using until now.

New work for Core DevOps team. There is still existing work, main competitor is scratch environments for dev teams. Might be able to target end of year?

Q: how is uptake of scratch environments? Some teams are taking this up, but still getting some requests for restarting folio-testing, folio-load, have not yet been able to decommission some purpose-built environments.


Secret Storage and Distributed configuration

Craig McNally

Distributed Configuration is a discussion item that also has a Spike that's active: 

Centralized configuration via mod-configuration is problematic from a security perspective - right now secrets are stored in mod-configuration - so if something has rights to access mod-configuration it gets access to all secrets. While it provides a convenient mechanism for storing configuration, the permission granularity is too coarse. Granting a user the ability to access an entry for one app means that they will also have access to ALL configuration entries.

Security team met and thought it was a problem that merited action and discussion at Tech Council.

There are 2 aspects of the problem

1) Distribute configs so that they aren't all together

2) Enable usage of a secret store - needs to be flexible and support multiple technologies (see the wiki page for a non-comprehensive list).


After discussion at TC - potential room in Q4 for core:platform team. Capacity Planning team will discuss/review.


Other?


Architectural Blueprint item revewTCDelayed - to be discussed at later date - TBD. Review status/updates: Folio Architectural Blueprint Strategic Changes

NEXT WEEK
Tech Debt Rankings/updates