tl;dr: "Rails: Not even once."
Everything in Rails is so much work because Rails is a rolling disaster; every new major version replaces enormous chunks of framework functionality with enormous new chunks of functionality, which imposes a heavy load on the developer; "convention over configuration", plus major changes to the convention du jour in every major version, equals a necessity to re-learn, at every major version change, where the new magic lurks and precisely how it works. If I'm being entirely fair, I can't say that the Rails developers have no interest in backwards compatibility, but such interest in my experience is both quite spotty and heavily concentrated on obvious and conventional behavior, which means anything non-obvious or unconventional is probably going to need heavy rework. (I have yet to run across a Rails app which did not, at least occasionally, do something non-obvious or unconventional, and necessarily so; no framework can cover every use case, but Rails in particular seems interested in covering only the most common ca. 60%.)
To make matters worse, no one in the Rails community has the slightest interest in yesterday, and even today tends to be neglected in favor of tomorrow. You talk of entire books on the subject of Rails deployment, and while the necessity for such books to exist is certainly a problem, actually having such a book means you're doing better than average; I've recently been fighting my way through an upgrade of a Rails 2.3 app to run under Rails 3.2; it's a difficult enough task to begin with, and is massively complicated by the fact that no real documentation exists on how to perform such an upgrade. What's there is mostly to be found on various Rails devs' Tumblrs, or in IRC logs or commit comments, and these are both poorly curated and evanescent; I've spent quite as much time trying to collate information on how to perform this project as I have actually editing code, and if not for the Internet Archive, a couple of critical Tumblr posts would no longer be available at all, thanks to the Rails dev who wrote them having apparently decided to "reboot" his blog.
The whole process has been enormously frustrating, not to mention slow; I started this project better than six months ago, as a novice Rails developer, and I'm just now getting to a point where I can see the light at the end of the tunnel. I am also strongly convinced that Rails is never the right solution; as long as I'm employed at this organization, it will embark upon a new Rails project only over my metaphorical smoking corpse. There's just too much to go wrong, and the underlying ideas of the Rails community are too wrong-headed to make for a reliable platform; the purpose of a framework is to free the developer from having to rearchitect the same infrastructure over and over, yet Rails not only forces developers to do so during upgrades, but the massive changes to core functionality I mentioned earlier make the rearchitecting task enormously more complicated and painful than it'd be in the absence of any framework at all -- I do not engage in hyperbole when I say that I've led upgrades from PHP 4 to PHP 5 which were both less painful and more quickly completed than the task of upgrading a single, rather small, site, from Rails 2.3 to Rails 3.2 has been.
Rails, overall, is the worst example I've ever seen of the development model which Zawinski calls "CADT" [1]; between that, and the deep-seated and dangerous problems Shaw identifies with the Rails community as a whole [2], anyone other than a Rails core developer, who involves Rails in a project of any sort save perhaps a tiny single-developer throwaway prototype, is borrowing trouble on a potentially catastrophic scale both for himself and for any unwitting organization on which he chooses to inflict the resulting disaster.
[1] http://www.jwz.org/doc/cadt.html
[2] http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto