我应该如何将代码从开发转移到生产？

发布于 2024-08-10 09:14:20 字数 441 浏览 16 评论 0原文

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

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

对于我来说，将我的 PHP Web 应用程序代码从 DEV 转移到 TEST 再到 PROD 环境有什么好的工具/业务实践吗？

意识到我的 TEST 环境仍然只连接到我的 TEST 数据库；然而，我需要 PROD 环境来连接到我的 PROD 数据库。因此，代码大部分是相同的，只是在移入 PROD 后我需要更改 TEST 代码以连接到 PROD 数据库而不是 TEST 数据库。

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

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

这看起来非常危险。

是否存在最佳实践？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

孤独难免 2024-08-17 09:14:21

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）不是版本的一部分。因此，您可以“移动版本”，但不能移动配置文件。如果可以的话，将配置文件与其余代码一起放在树的外部，这样您就不需要将它们分开，并且在以后移动版本时要小心。您可以将配置“向上”移动一个目录并从文件中访问它们，如下所示：

“include ../config.php”；

3）如果您想使用版本控制系统，它们做得很好，但需要一些时间来适应它，如果您急于更新，那么现在可能不是开始使用它的正确时间。但我会在未来推荐使用最新一代的分布式版本控制系统。分布式意味着您不需要设置服务器以及更多优点。我将命名为bazaar，如果需要通过ftp更新它可以做到。请注意，版本控制系统使得版本交换变得非常快，因为只写入版本之间的差异。 Bazaar 有一个社区和文档，可以轻松启动。还有 Git，它拥有最新的商业托管网站：http://github.com< /a>.您可以在线查看代码并在版本之间进行比较，并且还有许多更有用的功能，即使您是唯一的编码人员，但在一个小组中它甚至更好。在系统之间进行选择并不容易。我不能推荐 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 时，你只需执行以下操作：

shutdown apache
删除旧的符号链接 /var/www/prod/htdocs (此时 apache webroot 已经消失了！）
创建新的符号链接 /var/www/prod/htdocs 作为 src/versions/v002 的链接
启动 apache

您还可以为此编写一个带有参数的脚本，并像这样调用它

upgrade-web prod 002

：使得差距变得更短。

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

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

5）如果您在没有符号链接的情况下手动执行此操作，为什么不移动而不是复制？

（当文件尚未位于同一服务器上时，您可以将它们复制到附近的某个位置，然后开始迁移，这样您就不必停止服务器这么长时间）

如果根级别上有多个目录项目的一部分，你可以一次移动它们一个。确保不要移动配置文件。或者找到一些策略来让他们恢复活力。工作流程是：

停止 apache
移走根级别上除配置文件之外的所有当前 prod 目录和文件
将所有新的 prod 目录和文件移至根级别（配置文件除外）
启动 apache

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

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

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

1) Separate configuration from the rest of the code. The rest of the code should then be able to run on all 3 locations without modifications. A typical config file could be:

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

And for the test environment:

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

Do not include the configuration files with the passwords in the code base. The code base may be copied through insecure connections or be stored on third party code hosting servers later (see below). And you maybe don't want your passwords on all your backup disks of the code.

You could also create one single config file and use a switch depending on the environment the code runs:

<? 
$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";
}
?>

But now you could be tempted to put it back into the code base, which is less secure as explained above. And if you do not put it there you have to update 3 files, or use one fixed location per server, and you have to make sure the code finds the file on each server. I personally prefer the one-file-per-site solution from above.

2) You have already "versions". There is one version running on prod now. Give it a unique name and number, which will never change again. You can use that version name when you backup the code and when you refer to the version or when you move it somewhere you name the subdiectory that will contian it after the version.

The version that you will put on prod in the near future is a different version, and if you make changes again this is also a different version.

As a rule of thumb: increase the version number when you move or export the code, when you swap or exchange or upgrade between locations, when you make a demo, and after each feature or milestone and each time when you do a full backup.

Please note that the config files (3, one for prod, test and dev) are NOT part of the versions. So you can "move the versions around" but the not the config files. If you can, put the config files OUTSIDE the tree with the rest of the code, so you do not need to separate them and take care when you move around the versions later. You could move the config one directory "up" and access them from the files like this:

"include ../config.php";

3) If you want to use version control systems, they do a great job but it needs some time to get used to it and if you are in a hurry with your update it is probaby not the right time to start live with it now. But I would for the future recommend to use a latest generation distributed version control system. Distributed means you do not need to setup a server and many more advantages. I will name bazaar, if it is necessary to update over ftp it can do. Please note that a version control system makes exchanging a version very fast, because only the differences between the versions are written. Bazaar has a community and documentation which makes it easy to start. There is also Git, which has the most up to date commercial hosting site: http://github.com. You can view the code online and compare between the versions and there are many more helpful features, even if you are the only coder, but in a group it is even better. The choice between the systems is not easy. I can not recommend CVS, which is outdated. Also SVN is not the latest generation of distributed version control system, I would not recommend to use it if there is not a specific reason, and it will pollute all your subdirs with special subdirs, which can be annoying. For peolple who are used to it and have already code in it it is fine, but for a starter I would say don't.

There is also Mercurial and Darcs among the distributed and open source version control systems. Mercurial also has a great commercial site for collaboration and online code view (http://bitbucket.org).

4) As long as you do not use a version control system, how about using symlinks?

You could have a directory on the server src/versions/ somewhere and put the named versions in there, each one in their own subdirectory. You will only add versions (because a version that exists will not be changed, if you change it it becomes a new version)

You could have src/versions/v001/ src/versions/v002/ src/versions/v003/ or whatever naming scheme you use.

Now here comes the trick: /var/www/prod/htdocs is a symlink to src/versions/v001/

When you upgrade to v002 you just do the following:

shutdown apache
remove the old symlink /var/www/prod/htdocs (at this point the apache webroot is gone!)
create the new symlink /var/www/prod/htdocs being a link to src/versions/v002
start apache

You can also write a script for this with parameters and call it like this:

upgrade-web prod 002

This makes the gap even shorter.

Sometimes you have to do a "fallback", when you find out that the new version has errors in production and you have to go back. This would be easy (because you do not remove the old directories, you just stop apache, delete the symlink and re-create it to the former location, in this case src/versions/v001 )

And if test and dev is on the same server, you can of course also symlink the same directories, so there would be no any for move or copy.

5) If you do it manually without symlinks, why not move instead of copy?

(When the files are not yet on the same server, you can copy them somewhere near, and then start with the migration, so you do not have to stop the server for such a ling time)

If there are several directories on the root level of the project you could move them one at time. Be sure to NOT MOVE the config files. Or find some strategy to bring them bakc. Workflow would be:

Stop apache
Move away all current prod directories and files on the root level except config file(s)
Move all new prod directories and files to the root level except config file(s)
Start apache

6) try to find your perfect individual file and directory layout and perfect workflow. This takes maybe some time and some thinking, but it pays. Do it on a piece of paper until you find the best solution. This could mean that you have to refactor your code and change server config files, but for the future your life is easier when you do administration and upgrades. From my experience: do not wait so long with this step. Your layout shoudl nmake it easy and safe to upgrade. Upgrading is not somehting extraordinary, it is routine and it should be safe and simple to do.

7) If you name your server and workstation environments (operating system of server is linux I guess, but is it a hosted or a root server, do you have ftp acces or also shell (ssh) access, or sftp? where do you develop, on a windows machine, or a mac?) then people can name tools to do the copying and moving. Also interesting: Is the test and dev server the same machine, if not, how they are connected, or they aren't? If not, you would make a 3-way transfer (Copy it to your local workstation and then to the server).

8) Think of file permissions. If you move files around or copy them, maybe the file permissions change, and if the application depends on some of them there should be a way to check and maybe chang. Example: Some applications need writable directories where they put uploaded files or session files or template caching. Other applications do not allow some files for security to be writable.

回复收藏 0 原文

梦幻之岛 2024-08-17 09:14:21

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

回复收藏 0 原文

半仙 2024-08-17 09:14:21

实际上，我不明白为什么测试环境应该在没有任何服务器关闭的情况下奇迹般地迁移到生产环境。 TEST 生产应该用于测试目的。即使您实际上正在生产服务器上进行测试，请将其关闭（关闭 apache），更改主配置文件中的一行，即确定要使用哪一组次要配置文件），然后再次启动（启动 apache）。完成此操作不会超过 1-3 分钟，而且您肯定不会每天执行十二次，因此不会有问题。

回复收藏 0 原文

小霸王臭丫头 2024-08-17 09:14:21

将您的代码放在修订控制系统中（我更喜欢 Subversion (svn)）。这使得您可以轻松保持开发、测试和生产环境同步，您不必跟踪您修改的文件。一旦您对 DEV 上的修改感到满意，就可以将更改提交到 svn，然后在 TEST 上运行“svn update”，最终在 PROD 服务器上测试后运行。大多数 Linux 托管提供商都安装了 svn 客户端，或者您可以自己安装。
我不喜欢每个站点都有不同版本的配置文件，因为它需要手动重命名一个文件并删除其他两个文件。我更喜欢在同一个配置文件中包含 DEV、TEST 和 PROD 配置。在配置文件中，我通过检查主机名或请求 URL 来确定代码在哪个服务器上运行。然后我可以使用“if”或“switch”语句来根据当前运行代码的服务器加载配置设置。
您可能还需要在服务器之间同步数据库结构。我使用 sqlyog 来实现此目的，它有一个内置的数据库结构同步工具，可以比较 2 个数据库结构并准备 SQL 来同步它们。

回复收藏 0 原文