@scholrlea
er not quite correct.
Yeah, SDFC requires all 'Apex' programs to pass at 80% unit test >coverage
Its Apex test code coverage has to be 75% , and it doesn't have to do anything much to get it pass. So it sucks, badly as a testing regime. Early versions of the API meant it didn't require you to create test data, and it still doesn't require it to test anything.
Note that it did not retain a known-working version for use after a failed test suite >(presumably because 'working' wasn't really an option, but I aggrdigress), meaning that >if the error occurred in a user-facing server, the page would fail hard the moment >anyone tried to use it.
Er what ? No it rolls back on a failed deploy ??
OK, fine, we'll shell out for a separate development server (and why not two more for >formal testing and UAT while we're at it), all paid for and managed independently of >each other but pipelined to each other for staging (thank Eris, they got that part almost >right), and use their rather badly broken import system for passing updates up the >chain. Oh, and there's no breaks for doing it, so every added server costs as much as >the production server + the added support needed to allow staging.
Depending on your license - Unlimited/Professional has 100 dev sandboxes , 1 full copy and 1 partial copy instance for testing. don't know what you are referring to there.
Its true automating deployments is still very much a dark art for many still welded to Change sets (copy from sandbox to another) .
SF are getting there with DX though - its still half arsed, but at least they've acknowledged the problem.
Did I mention that there was nothing keeping you from editing code in any of those >severs, including production? And not even a warning for doing it?
Nope you cannot go in and edit Apex code directly in production.
Visual Force pages/components and a bunch of other things - yes.