Deployment 如何在具有大量客户端交互和本地数据的AJAX应用程序中进行连续部署？

我们有一个用PHP编写的应用程序。前端大量使用javascript。通常，对于需要重新加载页面的普通应用程序，连续部署实际上不是问题，因为：

• 应用程序可以使用构建标签进行部署：

  myapp-4-3-2013-b1

  ，

  myapp-4-3-2013-b2

  ，等等
• 当用户加载页面时（我们使用的是front controller模式），我们可以插入buildtag，并使用正确的build标记从app目录加载文件
• 我们不需要将较旧的构建保留太长时间，因为随着较旧的请求完成，它们将移动到较新的构建标记
• 数据库和用户数据不兼容的问题并不是很严重，因为我们会在用户请求完成后将其迁移到较新的版本（稍后将对此进行详细介绍）

现在，我们的应用程序的问题是，它大量使用AJAX来平滑页面加载。此外，由于用户在应用程序中导航时根本不需要刷新页面，因此用户可以在当前浏览器会话中保留未保存的数据，并在浏览器未刷新时重新访问

如果我们想要实现连续部署，这将导致更大的问题：

• 我们可以将用户的buildtag保留在会话中（在用户发出第一个请求时设置），并且只在注销并再次登录后切换到较新的buildtag。这显然是不好的，因为如果在较新的版本中数据库模式发生更改或要写入磁盘的文件格式发生更改，则无法协调这一点

• 我们强制所有新的请求到一个新的构建标记，但是如果我们强制每个会话的人立即到新的构建标记上，我们就有可能更改客户端javascript并破坏很多东西

显然，上述情况不会发生在我们推动的每个构建中，希望不会经常发生，但我们希望构建一个傻瓜式的过程，以便能够部署通过测试的每个构建。同时，我们希望确保每一个已部署且通过测试的构建不会无意中打断正在运行会话的客户端，从而导致一系列问题

我做了一些调查，谷歌所做的（至少在谷歌集团中）是，他们向客户发送一条消息，以刷新应用程序（浏览器窗口）。但是，在这种情况下，所有未保存的客户端数据（如未保存的消息等）都将丢失

---

考虑到现在使用AJAX和本地数据的应用程序非常普遍，有哪些更智能的处理方法可以将对用户/客户端的干扰降至最低？

让我先说一句，在阅读您的文章之前，我从未想过要进行连续部署，但这听起来确实是个不错的主意！我有几个例子可以说明这一点

不过，我对解决您的问题的想法是采纳您的第一个建议（更清晰），并绕过数据库架构更改，如下所示：

registerNewUser2(username, password, fullname) {
    writeToDB(username, password, fullname);
}

在应用程序中实现一个API服务层，用于处理构建标记环境之外的数据库或文件访问。例如，您将拥有

myapp-4-3-2013-b1

和

db services

文件夹

db services

将通过一系列版本化服务提供与数据库的任何交互。例如，

registerNewUser2（）

或

processOrder3（）

当您需要更改数据库模式时，您需要提供该服务的新版本，并升级构建标记环境以查看新版本。您还将提供一个遗留服务，用于处理从旧模式到新模式的升级

例如，假设您注册了以下新用户：

registerNewUser2(username, password, fullname) {
    writeToDB(username, password, fullname);
}

您需要更新模式以添加用户的出生日期：

registerNewUser3(username, password, fullname, dateofbirth) {
    writeToDB(username, password, fullname, dateofbirth);
}

registerNewUser2(username, password, fullname) {
    registerNewUser3(username, password, fullname, NULL);
}

新的生成标记将更改为调用

registerNewUser3（）

，而以前的生成标记仍在使用

registerNewUser2（）

因此，旧的构建标签将继续工作，只是任何注册的新用户的出生日期将为空。使用更新的构建标记时，出生日期将正确写入数据库

您需要在推出新的构建标记时立即更新

db服务

，或者在推出构建标记之前更新

一旦确定每个人都在使用新版本，就可以从下一版本的

db services

中删除

registerNewUser2（）

要确保正确处理旧API和新API调用之间的转换，这将非常复杂，但如果您已经在处理连续部署，这可能是可行的