Now that iOS 4.2 is out Typekit has changed how we support for iOS devices. We've stopped supporting iOS3 and earlier, which means users that haven't upgraded yet won't get browser crashes.
The "new school" is not about operations doing it all themselves, or about a new "devops" position that does both dev and ops. It's about greater cooperation between the team that's developing the application ("dev") and the team that supports it on a day to day basis ("ops"). It's not a new idea, but that doesn't stop it being useful.
If you're working on a team that is responsible for both then devops isn't a useful concept - you're probably doing it already. Many people are not so lucky.
We're not aware of any issues in Safari 5 - could you drop an email to [email protected] with an example URL showing the problems so we can look into it?
Performance. Embedding 18 fonts via CSS would add a lot of weight and the browsers (particularly mobile safari) don't cope too well when you embed too many fonts at once.
All the time. For example, we switched from one video transcoding backend to another recently. Having a single config flag used to chose which codepath a video went through meant we could launch it for staff only at first. Then, as we rolled it out to more people we could very easily switch to the old codepath if we found issues.
We've used flags for changes at all layers within the application code itself - whether to use the more optimized javascript, the new css sprites, the new database access layer, the new database schema, the new spam detection system etc etc.
You get even more out of config flags when deploying non-user facing changes - nobody knows if you roll it back so you can turn it off and on as many times as you need to get detailed data on exactly what impact the new code has on your metrics (both business and infrastructure).
One thing we don't use flags for is changes in the layers below the application - the OS, web server, php libraries etc. It's much easier to roll these out server by server.
[I work at flickr and gave the presentation linked to above]
You don't need to test every permutation. Pretty much all of the flags in the codebase are independent of each other - someone might be working on changes to our admin interface in some files while someone else is changing the way comments are displayed elsewhere. There's no overlap in the changes.
If the flags do interact with each other then in most cases the features will launch one after another, so you only need to test a handful of states (foo off bar off, foo on bar off, foo on bar on)
If the flags interact with each other and the features will be launching at the same time (or the betas overlap) then you have to do the same amount of integration testing that you'd have to do with landing several branches into trunk at once. This is complex, we don't do it very often.
And we clean up flags once they're not needed any more, which minimizes the possible combinations.
I was skeptical about this before I started working at flickr, now I can't imagine working any other way.
The problem is finding all the places that the language has changed and all the places you relied on the old behavior. The documented stuff was easy to find, it was the undocumented (or unintended?) changes that were hard. For example, strtotime($null) returns now in php4 but returns null in php5.
QA and automated testing will only get you so far in this process. Nobody had thought to test how we display the "Date Taken" on photos from before December 14th 1901 until a member pointed out they were displaying wrong (caused by another change to strtotime() behavior).
At some point you have to upgrade a subset of your servers, watch the error logs, fix the bugs as they come up and be prepared to rollback quickly. It wasn't a fun experience...
I'm guessing this is just extra paranoia, but it opens an obvious attack to log people out of a site maliciously.
Any ideas on that one?