2020-09-02 Meeting notes
Date
Attendees
- Marko Knepper
- Ian Walls
- Zak Burke
- Anton Emelianov (Deactivated)
- Craig McNally
- Jakub Skoczen
- VBar
- Tod Olson
- Marc Johnson
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
UI Testing Framework recommendations | UI Testing Team has made a recommendation - these decisions are being documented based on meeting/agreement yesterday.
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 | 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 | 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 revew | TC | Delayed - to be discussed at later date - TBD. Review status/updates: Folio Architectural Blueprint Strategic Changes | |
NEXT WEEK | Tech Debt Rankings/updates |