Deployments/Features Process/Mobile Notes

Mobile Dev/Deploy

recently switched to dedicated deploy branch
- called production
- simultaneously
deploy by recreating production branch of master
- merge freeze 24hours-ish before deploy
- deploy fixes without needing to mess with complicated merges/changes we don't want to deploy yet
had problems when a new wmf branch was created, it grabed the mobile frontend from master, and it had problems with quality
currently still need to spend some time testing during deployment
- use test.wikipedia.org heavily
- since they have the 2 hour window why not use it for testing
  - usual devs poke around basic functionality or stuff that has changed
  - michele has a test plans, which is run against 3 version
normal unstable, beta, alpha
dont' want to do mobile with core, because it has caused problems in the past
- last major problem about a month ago
- due to recent changes, the possibility of it needed any more is much less
modeling after the separate branch?
- depends on problems
- what is the tech plan of the product managers
- switching to dedicated production branch helped us
sometimes they depend on core changes and thus, as a part of their deployment they have to deploy core changes as well, usually quite isolated
I (Michelle) have a testing environment that I deploy merged code to so that the Designers and Product can see changes prior to the release it's http://staging.wmflabs.org/. This staging environment and test.m are only a piece of the puzzle because of caching which as you know adds a bit of a wrench in out deployments.

Chat with Maryana:

two staging areas
- alpha and beta mobile site
- all three are different
have to test each separately
big challenge
- what is a real bug but not just a product of test environment
- eg test wiki
- betalabs is still wonky
- sometimes find out stuff a couple weeks later because of lack of intense testing on beta
always the actual live production needs
always begging to flush cache/sync stuff etc
there is a more regular