It's been many years since I worked in a shop that didn't deploy during the day (large financial institution aside), and for all the reasons the post mentions I completely agree.
What enables a mid-day deploy, however, is a well thought-out deploy process that aims for a zero downtime deployment. This can be especially complicated when you have relational database changes baked into a deploy.
It's interesting to see some folks suggesting that they may not be able to do this during business hours. Here's the thing: when bad things happen, you need to deploy ASAP. Developing a great deploy process that allows your system to remain standing during that deployment has numerous advantages, including the ability to deploy at will, and have no fear in doing so.
Relational DB changes don't have to be particular show-stoppers, provided you're willing to accept a few constraints:
1. No select * in SQL; name your columns in selects and inserts (prevents the select result set from changing or the insert from breaking when you add a column later)
2. All tables need table aliases in join queries. (Otherwise, adding a column can cause a naming collision and introduce ambiguity into a presently non-ambiguous select.)
3. Transactional columns can be added, provided they have defaults or are nullable
4. Columns can only be dropped in two releases, one to remove all references to them and the second to actually remove. (You may want to rename the column first during the second release and drop it a few minutes/hours later once you're sure no one is relying on it.)
5. Modifying a column requires some care (to insure that you don't lock the table too long during the modification). Here again, you can probably add a column of a different name, gradually populate it, then rename into place later, add a new table and left outer join to that, or wait for a future downtime event (rarely required in practice).
It's not necessarily "trivial" to accomplish, but it's also not deep, black magic.
This is a good guide, but note that he said zero downtime deployment
That imposes an additional constraint - the new code needs to be backwards compatible (while any data migration scripts are running), and - in a clustered environment - it needs to be able to deal with the case where old and new code bases and databases are available and running simultaneously.
If you release the new code only after the DB changes are complete, the new code doesn't need to be backwards compatible.
The above guidelines are designed to provide no-change to the queries the old code is running, so that should be possible to accomplish for 95+% of your migrations.
For truly long-running migrations (longer than you're willing to wait to push code), you're correct that the new code must handle both cases. In our case, that's extremely rarely a factor, but we also don't push on every commit (nor even every day) like some shops do.
What enables a mid-day deploy, however, is a well thought-out deploy process that aims for a zero downtime deployment. This can be especially complicated when you have relational database changes baked into a deploy.
It's interesting to see some folks suggesting that they may not be able to do this during business hours. Here's the thing: when bad things happen, you need to deploy ASAP. Developing a great deploy process that allows your system to remain standing during that deployment has numerous advantages, including the ability to deploy at will, and have no fear in doing so.