Microsoft Web Deployment Tool 在某种程度上支持此功能：
启用Windows事务性文件系统（TxF）支持。当启用TxF支持时，文件操作是原子的；也就是说，它们要么完全成功，要么完全失败。这确保了数据完整性并防止数据或文件处于“半途”或损坏状态。在MS Deploy中，默认情况下禁用TxF。
看起来交易是针对整个同步进行的。另外，TxF是Windows Server 2008的一个功能，因此此事务功能将无法与早期版本一起使用。
我相信可以通过使用文件夹作为版本和IIS元数据库修改脚本实现0停机时间：
此方法提供以下好处：
好的，既然大家都在downvote我2008年写的答案，那么我来告诉你我们现在2014年是如何做的。因为我们现在使用的是ASP.NET MVC，所以我们不再使用Web站点。
我们绝对不需要负载均衡器和两台服务器来完成这项任务，如果您每个网站都要维护3台服务器，那就没问题了，但对于大多数网站来说，这样做是完全过度的。
此外，我们不依赖于Microsoft的最新技术 - 太慢了，还有太多的隐藏魔法，而且容易改变名称。
我们是这样做的：
我们有一个发布后生成的DLL文件将其复制到“bin-pub”文件夹的步骤。
我们使用Beyond Compare（非常好用**）验证并同步更改的文件（通过FTP进行，因为广泛支持）上传到生产服务器上
我们在网站上有一个安全URL，其中包含一个按钮，可以将'bin-pub'中的所有内容复制到'bin'中(首先备份以便快速回滚)。在这一点上，应用程序会自动重新启动。然后我们的ORM检查是否需要添加任何表或列，并创建它们。
这只需要几毫秒的停机时间。应用程序重新启动可能需要一两秒钟，但在重新启动期间，请求被缓冲，因此实际上没有停机时间。
整个部署过程需要5秒到30分钟不等，具体取决于更改了多少文件和需要审查的更改数量。
这样做，您就无需将整个网站复制到另一个目录，只需复制bin文件夹即可。您还可以完全控制该过程并确定正在发生什么变化。
**我们总是快速检查要部署的更改 - 作为最后一次双重检查，以便我们知道要测试什么以及是否出现任何故障。我们使用Beyond Compare，因为它可以轻松比较FTP上的文件差异。如果不使用Beyond Compare，我绝对不会这样做，因为你根本不知道你正在覆盖什么。
*向下滚动到底:( BTW，我不再推荐Web Sites，因为构建速度更慢，而且可能会由于一半已编译的临时文件而崩溃。我们过去使用它们是因为它们允许逐个文件部署。修复小问题非常快速，您可以看到您正在部署的内容(如果使用Beyond Compare，否则就忘了吧)。
我想稍微修改一下George的答案，对于单个服务器，可以按照以下步骤进行：
第4步会导致IIS工作进程重新启动。
如果您不使用InProc会话，则此方法只能实现零停机时间；如果可能，请改用SQL模式（更好的方法是完全避免使用会话状态）。
当然，如果涉及多个服务器和/或数据库更改，则需要更多操作。
可以通过创建数据库快照/副本引入一些冒烟测试，但这并不总是可行的。
如果可能且需要，请使用“路由差异”，例如不同的租户URL（customerX.myapp.net）或不同的用户，首先向一个不知情的小组进行部署。如果没有失败，就向所有人发布。
由于涉及数据库迁移，因此回滚到先前版本通常是不可能的。
有一些方法可以让应用程序在这些情况下更友好地运行，例如使用事件队列和播放机制，但由于我们正在谈论对正在使用的内容进行更改的部署，因此真正没有绝对可靠的方法。
try
Web-Service: Tell all applications on all web-servers to go into primary read-only mode
Application switch to primary read-only mode, and responds
Web sockets begin notifying all clients
Wait for all applications to respond
wait (custom short interval)
Web-Service: Tell all applications on all web-servers to go into secondary read-only mode
Application switch to secondary read-only mode (data-entry fuse)
Updatedb - secondary read-only mode (switches database to read-only)
Web-Service: Create backup of database
Web-Service: Restore backup to new database
Web-Service: Update new database with new schema
Deploy new application to apt-repository
(for windows, you will have to write your own custom deployment web-service)
ssh into every machine in array_of_new_webapps
run apt-get update
then either
apt-get dist-upgrade
OR
apt-get install <packagename>
OR
apt-get install --only-upgrade <packagename>
depending on what you need
-- This deploys the new application to all new chroots (or servers/VMs)
Test: Test new application under test.domain.xxx
-- everything that fails should throw an exception here
commit myupdate;
Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number)
@client: notify of reload and that this causes loss of unsafed data, with option to abort
@ time x: Switch load balancer from array_of_old_webapps to array_of_new_webapps
Decomission/Recycle array_of_old_webapps, etc.
catch
rollback myupdate
switch to read-write mode
Web-Service: Tell all applications to send web-socket request to unblock read-only mode
end try