I would be -1 on this sort of change.
Changing the schema of a RDBS and deploying the dependent code should be performed with great care, the basic concept of each migration being “whole” change keeps things tidy. Giving any impression to a developer that enclosing a bunch of migrations as a transaction creates a highly-available deploy would be a disservice. There are so many other factors that go into making HA happen. Very few sites actually require anything close to HA, those that do are going to be putting all sorts of tools around their deploy process.
The suggested code/schema upgrade should go this way, hopefully in as short a period as possible, with some sanity checks between each step:
- Disable website
- Dump current database
- Migrate database
- Update code
- Re-enable website
Lets say there were 10 migrations to do and #5 failed, being in the state that 1-4 have run is where you want to be. Now you can look at why #5 failed, fix it (check it in), and continue.
This becomes particularly important if one of 1-4 were very long running statements, large import, index updating, etc. In these cases it becomes even more important that the website be shut down because the DB is going to be pinning its CPU and the user experience is going to suffer dramatically.
If the change was implemented I would suggest that it be off by default in development, where the situation of wanting the first few migrations to take and then to begin debugging is the much more normal behaviour.