Question

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

可以使用构建代码部署应用：myapp-4-3-2013-b1，myapp-4-3-2013-b2等。
当用户加载页面时（我们使用前端控制器模式），我们可以注入构建标签，并使用正确的构建标记从app目录加载文件。
我们不需要将旧版本保留太长时间，因为随着较旧的请求完成，它们将转移到较新的构建标记。
数据库和用户数据不兼容的问题不是很高，因为我们会在他们的请求完成后将人员迁移到更新的版本中（稍后会详细介绍）。

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

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

我们可以将用户的buildtag保留在他们的会话中（在他们发出第一个请求时设置），并且只有在注销后再次登录时才切换到更新的buildtags。这显然很糟糕，因为如果数据库架构发生更改或者要写入磁盘的文件格式在较新的版本中发生更改，则无法协调这一点。
我们将所有新请求强制推荐给更新的构建标记，但是如果我们立即强制每个人都将会话强加到新构建标记上，我们就有可能更改客户端javascript并会破坏很多东西。

显然，我们推送的每个构建都不会出现上述情况，并且希望不会发生很多事情，但我们希望构建一个简单的过程，以便可以部署通过我们测试的每个构建。同时，我们希望确保每个部署和测试传递构建都不会无意中中断运行会话的客户端会导致一大堆问题。

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

鉴于目前使用AJAX和本地数据的应用程序非常普遍，有哪些更智能的处理方法可以最大限度地减少对用户/客户的干扰？

Answer 1

让我先说明一下，在阅读你的文章之前，我从没想过要继续部署，但这听起来确实是个好主意！我有一些例子可以说这很好。

我对解决你的问题的看法虽然是为了你的第一个建议（更干净），并绕过这样的数据库架构变化：

在应用程序中实现一个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()。

因此，旧的构建标记将继续有效，只是注册的任何新用户都将具有NULL出生日期。使用更新的构建标记时，出生日期将正确写入数据库。

一旦推出新的构建代码，您就需要立即更新db-services - 或者甚至在推出构建代码之前，我需要更新。

确定所有人都在使用新版本后，您只需从下一版registerNewUser2()中删除db-services。

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

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

1 个答案: