User:DWalden (WMF)/Test2wiki k8s migration

Scope of change
The parts of the application that will be running in Kubernetes are highlighted in red in the below diagram.



See also File:Presentation_qte_sync_20042022.pdf.

Scope of testing

 * Test when we touch the app server, for example:
 * load a page
 * submit a form
 * make an API request
 * back-end processing (deferred updates, jobs)
 * features which call external binaries (see )
 * Don't worry about UI parts of the application
 * unless they are making API requests in the backend (e.g. we might want to test VE as it relies on calls to parsoid)

Risks

 * Do the individual docker images function?
 * MediaWiki + extensions
 * Back-end processing (Jobs, Deferred updates)
 * External binaries (Shellbox)
 * Do the docker images have access to the appropriate resources inside Kubernetes?
 * What features rely on other resources like files, keystores, etc.
 * Do the docker images contest for resources inside Kubernetes?
 * Does it have access to resources outside Kubernetes?
 * Things inside our ecosystem but outside Kubernetes (e.g. database, APIs, Parsoid)
 * External services (outside our ecosystem)
 * Reliability, performance, load, stress...

Next steps

 * Get Selenium tests running on test2wiki to provide smoke tests (T303739)
 * Fill out the readiness reviews for teams.

Open Questions

 * Do we need to test that whatever load balancing solution we are using is working?
 * Do we test rolling back changes to test2wiki?
 * What testing do we need in terms of:
 * reliability (e.g. concurrency)
 * performance
 * load
 * anything else

Team testing readiness
(Making a page for a team not listed below? Use /Readiness_template) (Want a high-level view? See /Readiness_high-level)
 * /Anti-Harassment_Tools
 * /Apps
 * /Campaign_Development
 * /Community_Tech
 * /Editing
 * /Growth
 * /Inuka
 * /Language
 * /Structured_Data
 * /Trust_and_Safety_Tools
 * /Web_Readers

(Also see /How_to)

Teams or features not covered above
See Developers/Maintainers.

Teams or features that don't need testing coverage

 * Design_Systems_Team (nothing on production yet?)
 * Fundraising_tech (I am not sure about their technology stack)
 * Platform_Engineering_Team (I am not sure about this team)