Mobile web/MobileFrontend deployment/Planning
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on any information on this page. |
QA[edit]
- 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[edit]
- Ops -wikitech:MobileServiceOps* MW Admin facing for anyone wanting to run the extension
Production Deployment[edit]
- Draft what it means to deploy successfully
- Pick a date
- Reserve ops resources
.. wait
- Depricate old hawhaw and ruby gateway
- Ramp up plan (operations)
- Rollback plan (ops)
- Budget time post deployment to monitor and solve production issues
Monitoring[edit]
- Internal errors that still result in a non 500 response (e.g., libxml based failures)
- Service times
Open Questions[edit]
- 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[edit]
- Server side redirect
- additional hardware?
Rob's Ideas[edit]
- 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