1

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

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

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

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

  • 我们可以将用户的构建标签保留在他们的会话中（在他们发出第一个请求时设置），并且仅在注销并再次登录后切换到更新的构建标签。这显然很糟糕，因为如果数据库架构发生变化或要写入磁盘的文件格式在较新的版本中发生变化，则无法协调这一点。

  • 我们强制所有新请求使用新的构建标签，但是如果我们立即强制所有有会话的人使用新的构建标签，我们可能会更改客户端 javascript 并且会破坏很多事情。

显然，我们推送的每个构建都不会发生上述情况，希望不会发生很多，但我们希望构建一个万无一失的流程，以便可以部署通过我们测试的每个构建。同时，我们希望确保每个已部署和通过测试的构建不会无意中在运行会话的客户端中中断，从而导致一大堆问题。

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

鉴于现在使用 AJAX 和本地数据的应用程序非常普遍，有哪些更智能的方法可以处理这种情况，从而将对用户/客户的干扰降至最低？

4

1 回答 1

0

让我在阅读您的帖子之前先说一下我从未想过持续部署，但这听起来确实是个好主意！我有几个例子，这会很好。

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

在您的应用程序中实现一个 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);
}

新的构建标签将更改为 call registerNewUser3()，而之前的构建标签仍在使用registerNewUser2()。

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

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

一旦您确定每个人都在使用新版本，您就可以registerNewUser2()从下一个版本中删除db-services.

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

于 2013-03-15T06:38:20.830 回答