Mobile web/MobileFrontend deployment/Planning

QA

 * Add profiling to extension
 * Open launch blocker tracking bug
 * Test caching
 * Load testing (Asher)
 * Test i18n
 * Request community testing
 * Blog post to gain visability about changes
 * External testers
 * Wikia, Iranian Encylopedia, etc ..
 * Contract with DeviceAnywhere for device testing
 * Add monitoring
 * Code review (Tim+Brion, others?)
 * logging
 * service health
 * analytics (Erik Z/RobLa)
 * QA resources
 * http://www.deviceanywhere.com/mobile-application-testing-smart-devices.html
 * http://www.perfectomobile.com/
 * http://mobileappstesting.contussupport.com/
 * External testing (Patrick will follow up)
 * QA testing plan - determine the specific things to test and the platforms to test them on
 * Community test plan (Sumana)
 * Production cluster testing - dark launch + cookie-based access
 * JSON API
 * Add to deployment calendar

Documentation

 * Ops -MobileServiceOps* MW Admin facing for anyone wanting to run the extension

Production Deployment
.. wait
 * Draft what it means to deploy successfully
 * Pick a date
 * Reserve ops resources
 * Depricate old hawhaw and ruby gateway
 * Ramp up plan (operations)
 * Rollback plan (ops)
 * Budget time post deployment to monitor and solve production issues

Monitoring

 * Internal errors that still result in a non 500 response (e.g., libxml based failures)
 * Service times

Open Questions

 * Redirect rule for wap based devices redirecting too many clients (squid)?
 * Cache infrastructure integration
 * Is the redirection happening for mobile?
 * HipHop?
 * What does it take to deploy a hiphop thingamajig?
 * Do we need to order extra hardware?
 * Can we run the extension on the regular cluster?
 * Asher going to help with profiling/testing to figure this out
 * Overhead of squid rewrite rule for server-side redirect?
 * Ops says this is not a good way to do this (due to performance/serving traffic for all wikis), perhaps rely on nginx cluster?
 * Perhaps rely on Tim's 'vary' script
 * We need a way to test what's going to work or not, hijack Ryan Lane's virt cluster?
 * Ramp up (expose to small % of users, redirect everyone else to current gateway) - can we use LVS?
 * Rely on LVS weighting
 * Some concern about cache issues (items from one service in the cache returned when accessing the other service)
 * Client side metrics gathering?
 * Render times
 * Delivery times
 * Action items: 1. get on analytics priority list 2. possible collaboration with Mediawiki Core team
 * How do we test WAP devices?
 * Migration to Varnish? (Asher)
 * How do we integrate with ESI?

Launch blockers

 * Server side redirect
 * additional hardware?

Rob's Ideas

 * Q/A
 * We haven't given our external testing good test plans.
 * Bad: Not prioritizing
 * Good: Define prioritized smoke tests per cycle
 * Figure out your top 3-5 browsers
 * Performance testing & Profiling
 * Possibly use het deploy