I read somewhere (sorry don't exactly remember the source) that facebook has release Tuesdays. They release the new features to their internal employees first, then to a small set of external users and then to the whole world. I believe google also does something similar
I work primarily with Microsoft stack (TFS for source control, IIS, asp.net, sql server with huge data). Public facing sites of course, so they have to be up 24x7x365. Though I can envision releasing my api/dll only on one of the servers (in the webfarm) and testing it out, how would I do this if there are DB (stored proc signatures, table schema changes )? Presently we are versioning SPs (the new ones will be mySPNameV2, where as the old one will be mySPNameV1 - both taking different set of parameters hence the renaming) and the new APIs would use SP-V2 where as the old API would continue with SP-V1.
I see some design smell, but is there a better way to do it?
Edit: we release the new code to only one server and test it, what is difficult is how would you abstract (may be abstract is not the right word, but you get the idea) db schema changes from multiple concurrent versions of the application
If I understood you correctly, what you want is to have two mechanisms that use the same live data, but different API versions. Now, assuming you're already working with a double buffer mechanism, I guess that your actual problem is to use live tables during that transition.
The solution is for your tables to include both V1 and V2 columns (e.g., one users table that will include fields from both APIs). Note: All non-common fields must have default values.
In order for this to work seamlessly, you should create views for V1 and V2, exposing only the relevant fields for each API version, and you should develop for views instead of tables (similar to the concept of developing for interfaces instead of implementation).
The same goes for stored procedures - all non-common parameters must have default values, etc...