8

我创建了一个 PHP 网络应用程序。

我有 3 个环境：DEV、TEST、PROD。

什么是我将 PHP Web 应用程序代码从 DEV 移动到 TEST 到 PROD 环境的好工具/业务实践？

意识到我的 TEST 环境仍然只连接到我的 TEST 数据库；而我需要 PROD 环境才能连接到我的 PROD 数据库。所以代码几乎是相同的，除了我需要更改我的 TEST 代码一旦移入 PROD 以连接到 PROD 数据库而不是 TEST 数据库。

我听说有人关闭 Apache，它不允许新的连接，一旦所有现有连接都空闲，它只会关闭 Web 服务器。

然后人们手动复制代码，然后手动更新 PHP 应用程序的配置文件，使其也指向 PROD 实例。

这似乎非常危险。

是否存在最佳实践？

4

5 回答 5

8

1) 将配置与其余代码分开。然后，其余代码应该能够在所有 3 个位置上运行而无需修改。一个典型的配置文件可能是：

<? 
$db = "main_db"; $db_user="web1"; $db_pass = "xyz123"; 
$site ="example.com"; 
$htroot = "/var/www/prod/htdocs" 
?>

对于测试环境：

<? 
$db = "test_db"; $db_user="web1"; $db_pass = "xyz123"; 
$site ="test.example.com"; 
$htroot = "/var/www/test/htdocs" 
?>

不要在代码库中包含带有密码的配置文件。代码库可能会通过不安全的连接复制或稍后存储在第三方代码托管服务器上（见下文）。而且您可能不希望在代码的所有备份磁盘上都有密码。

您还可以创建一个配置文件并根据代码运行的环境使用开关：

<? 
$site = $_SERVER["HTTP_HOST"];

if ($site == "example.com"; ) {
  $db = "main_db"; $db_user="web1"; $db_pass = "xyz123"; 
  $htroot = "/var/www/prod/htdocs";
}
if ($site == "test.example.com") { 
  $db = "test_db"; $db_user="web1"; $db_pass = "xyz123"; 
  $htroot = "/var/www/test/htdocs";
}
?>

但是现在您可能会想将其放回代码库中，如上所述，这不太安全。如果你不把它放在那里，你必须更新 3 个文件，或者每台服务器使用一个固定位置，并且你必须确保代码在每台服务器上都能找到文件。我个人更喜欢上面的每个站点一个文件的解决方案。

2）您已经有“版本”。现在有一个版本在 prod 上运行。给它一个唯一的名称和编号，它永远不会再改变。您可以在备份代码时使用该版本名称，当您引用版本或将其移动到某个位置时，您可以命名将在版本之后包含它的子目录。

您将在不久的将来投入生产的版本是一个不同的版本，如果您再次进行更改，这也是一个不同的版本。

作为经验法则：当您移动或导出代码、在位置之间交换或交换或升级时、进行演示时、在每个功能或里程碑之后以及每次执行完整备份时，都增加版本号。

请注意，配置文件（3 个，一个用于 prod、test 和 dev）不是版本的一部分。因此，您可以“移动版本”，但不能“移动配置文件”。如果可以，请将配置文件与其余代码放在树之外，这样您就不需要将它们分开，并且在以后移动版本时要小心。您可以将配置“向上”移动一个目录并从如下文件中访问它们：

“包括../config.php”；

3) 如果你想使用版本控制系统，它们做得很好，但需要一些时间来适应它，如果你急于更新，现在可能不是开始使用它的合适时间。但我会在未来推荐使用最新一代的分布式版本控制系统。分布式意味着您不需要设置服务器以及更多优势。我将命名为bazaar，如果有必要通过 ftp 进行更新，它可以做到。请注意，版本控制系统使得版本交换非常快，因为只写入版本之间的差异。Bazaar有一个社区和文档，可以轻松上手。还有Git，它拥有最新的商业托管站点：http://github.com。您可以在线查看代码并在版本之间进行比较，还有更多有用的功能，即使您是唯一的编码员，但在一个组中它会更好。系统之间的选择并不容易。我不能推荐 CVS，它已经过时了。另外 SVN 不是最新一代的分布式版本控制系统，如果没有特定的原因，我不建议使用它，它会用特殊的子目录污染你的所有子目录，这可能很烦人。对于习惯它并且已经在其中编写代码的人来说，这很好，但对于初学者来说，我会说不要。

分布式和开源版本控制系统中还有Mercurial和Darcs 。Mercurial 还有一个用于协作和在线代码查看的出色商业网站 ( http://bitbucket.org )。

4）只要你不使用版本控制系统，使用符号链接怎么样？

您可以在服务器 src/versions/ 某处有一个目录，并将命名的版本放在那里，每个版本都在它们自己的子目录中。您只会添加版本（因为存在的版本不会被更改，如果您更改它就会成为新版本）

您可以使用 src/versions/v001/src/versions/v002/src/versions/v003/ 或您使用的任何命名方案。

现在技巧来了：/var/www/prod/htdocs 是 src/versions/v001/ 的符号链接

当您升级到 v002 时，您只需执行以下操作：

  • 关闭阿帕奇
  • 删除旧的符号链接 /var/www/prod/htdocs （此时 apache webroot 已经消失了！）
  • 创建新的符号链接 /var/www/prod/htdocs 作为 src/versions/v002 的链接
  • 启动阿帕奇

你也可以为此编写一个带有参数的脚本并像这样调用它：

upgrade-web prod 002

这使得间隙更短。

有时你必须做一个“回退”，当你发现新版本在生产中有错误，你必须回去。这很容易（因为您不删除旧目录，您只需停止 apache，删除符号链接并将其重新创建到以前的位置，在本例中为 src/versions/v001 ）

如果 test 和 dev 在同一台服务器上，您当然也可以符号链接相同的目录，因此不会有任何移动或复制。

5）如果你手动做没有符号链接，为什么不移动而不是复制？

（当文件还没有在同一台服务器上时，您可以将它们复制到附近的某个地方，然后开始迁移，这样您就不必停止服务器这么长时间）

如果项目的根级别有多个目录，您可以一次移动它们一个。确保不要移动配置文件。或者找一些策略给他们带来bakc。工作流程将是：

  • 停止阿帕奇
  • 移走根级别上的所有当前 prod 目录和文件，除了配置文件
  • 将所有新的产品目录和文件移动到根级别，除了配置文件
  • 启动阿帕奇

6）尝试找到你完美的个人文件和目录布局和完美的工作流程。这可能需要一些时间和一些思考，但它是值得的。在一张纸上做，直到找到最佳解决方案。这可能意味着您必须重构代码并更改服务器配置文件，但在未来，当您进行管理和升级时，您的生活会更轻松。根据我的经验：这一步不要等太久。您的布局应该使升级变得容易和安全。升级不是什么特别的事情，它是例行公事，应该安全且简单。

7）如果您命名您的服务器和工作站环境（我猜服务器的操作系统是 linux，但它是托管服务器还是根服务器，您是否有 ftp 访问权限或 shell (ssh) 访问权限或 sftp？您在哪里开发，在 Windows 机器上，还是在 Mac 上？）然后人们可以命名工具来进行复制和移动。也很有趣：测试和开发服务器是否是同一台机器，如果不是，它们是如何连接的，或者它们不是？如果没有，您将进行 3 向传输（将其复制到本地工作站，然后复制到服务器）。

8）考虑文件权限。如果您移动文件或复制它们，则文件权限可能会更改，并且如果应用程序依赖于其中的一些文件，则应该有一种方法来检查并且可能会更改。示例：某些应用程序需要可写目录，它们将上传的文件或会话文件或模板缓存放置在其中。其他应用程序不允许某些安全文件可写。

于 2010-04-29T15:30:25.180 回答
3

使用配置文件来确定您要连接的数据库。即有一个DEV配置文件，一个TEST配置文件，一个PROD配置文件。这通常是避免代价高昂和令人沮丧的错误的最佳方法。

于 2009-11-02T22:45:43.673 回答
3

实际上，我看不出为什么 TEST 环境应该在没有任何服务器关闭的情况下奇迹般地迁移到 PROD。TEST 生产应该用于测试目的。即使您实际上是在生产服务器上进行测试，请将其关闭（关闭 apache），更改主配置文件中的一行，即确定要使用的次要配置文件集）并再次启动（启动 apache）。这将花费不超过 1-3 分钟的时间来完成，而且由于您肯定不会每天这样做 12 次，所以您会没事的。

于 2009-11-03T16:05:02.760 回答
1

  1. 将您的代码放在版本控制系统中（我更喜欢 Subversion (svn)）。这使得保持 DEV、TEST 和 PROD 环境同步变得容易，您不必跟踪修改过的文件。一旦您对 DEV 上的修改感到满意，您将更改提交到 svn，然后在 TEST 上运行“svn update”，最终在 PROD 服务器上进行测试。大多数 linux 托管服务提供商都安装了 svn 客户端，或者您可以自己安装。

  2. 我不喜欢为每个站点使用不同版本的配置文件，因为它需要手动重命名一个文件并删除另外两个。我更喜欢在同一个配置文件中拥有 DEV、TEST 和 PROD 配置。在配置文件中，我通过检查主机名或请求 url 来确定代码在哪个服务器上运行。然后我可以使用“if”或“switch”语句来根据当前运行代码的服务器加载配置设置。

  3. 您可能还需要在服务器之间同步数据库结构。我为此使用了 sqlyog，它有一个内置的数据库结构同步工具，可以比较 2 个数据库结构并准备 SQL 来同步它们。

于 2009-11-03T06:51:56.407 回答
0

当我们实时推送更新时，我们不必经常重启 apache。这可能是没有高流量网站（每月< 100万页）的副作用。

我们有 3 个分支，用于开发/QA 的不同阶段：alpha（前沿，但可供非开发人员和测试人员查看）、beta（对于特定版本、最终 QA 阶段有些冻结）和 live（生产）。

为了从一个分支迁移到另一个分支，我们在 alpha 和 beta 之间执行合并，然后提交该合并。然后运行一个部署脚本，在我们的开发机器上从 SVN 更新分支，然后 rsync 的代码 Web 服务器到 beta 文档根目录。

正如其他人已经提到的，每个分支都可以包含自己的配置文件，并具有适当的设置以适应环境差异。

我们正在迁移到 git 以平滑分支合并过程，这在 SVN 中对于大型项目/版本可能有点创伤。

于 2010-04-29T16:08:08.223 回答