Sinjack
   |
Posted - 2009.05.25 14:31:00 -
[1]
People don't seem to realize that yelling "FASTER FASTER FASTER FASTER" doesn't actually change the fact that there's a process.
Typical Development Cycle
1) Changes on Development Server
2) Move changes to QA Server
3) Repeat above until Changes pass User Test.
4) Schedule move to Production
The sudden (almost reflexive) thing to do if a showstopper is passed to Production is a rollback, however there are a couple things that can prevent that, but first requires a little explanation of how the development cycle affects the three servers.
Development is the server that is LEAST like Production, experimental changes in a version tracking system ensures this server can be broken and unbroken and re-broken at all times in the day, when the developer decides he's met the requirements of the Change Request he schedules a move to a Testing server.
QA is the server that's supposed to be MOST like Production without actually being production, bad changes are supposed to be reversed or patched and nothing [is supposed to] sit in QA that doesn't get moved to Production "soon".
Production is the server that the users get to see.
Development is supposed to be a clone of QA, and QA of Production; but as time goes on and changes are made and patched and re-patched, they get "desync'd" (drat). Refreshes are when Production is copied to QA, and then to Development, a long time between refreshes means that potentially unstable patches get moved to Production simply because one piece of code doesn't interact with the rest of the build as properly as it did in QA. (Damn computers, always messing up perfectly good code)
Now, as to why they didn't just roll-back to 1.1? It is possible that in making patches and changes since 1.1 (even minor ones) they altered the database in a way that cannot be reverted with the press of a button, or it might require a roll-back of the client database as well... so that would mean losing days/weeks/months of training time, as well as Character/Corp/Alliance creations, standing/member changes, etc.
Bugs are [usually] classified with a severity system, and as MUCH as you guys would absolutely love this to be a Severity 1 bug... it isn't. Why? because Severity One implies that the bug is preventing operation of a critical business resource that [literally] costs the company money-per-second until it's fixed. As dramatic as you get, you can't fight it: The Servers are up, accepting connections and registrations.
This puts it at most a Severity Two bug, which is a critical show-stopper, but not persistent. I don't think I would give it that much credit, it's more of a Severity 3, a show-stopper affecting *some* of the population intermittently.
and that boys and girls, are how bugs are [accidentally] made in a production server with a proper development cycle, and probably why they're not scrambling fighter jets to combat this bug.
^ TL;DR?
This is likely a Severity 3 Bug being staffed by the developers to have a working fix developed & documented as quickly as reasonably possible. There was no rollback because it would likely require a (perhaps full) database revert, which *would* cost CCP thousands of dollars in people fleeing the game for the loss of days/weeks/months of training time. |