我有3个环境：DEV,TEST,PROD.
对于我来说,将我的PHP Web应用程序代码从DEV移动到TEST到PROD环境,有什么好的工具/业务实践？
意识到我的TEST环境仍然只连接到我的TEST数据库;然而,我需要PROD环境连接到我的PROD数据库.所以代码大致是相同的,除了我需要更改我的TEST代码一旦移入PROD连接到PROD数据库而不是TEST数据库.
我听说人们在这样的情况下取消了Apache,它不允许新的连接,一旦所有现有的连接都空闲,它就会关闭Web服务器.
然后人们手动复制代码,然后手动更新程序的配置文件,以指向PROD实例.
这似乎非常危险.
是否存在最佳实践？
<? $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.您可以在线查看代码并在版本之间进行比较,还有更多有用的功能,即使您是唯一的编码器,但在一个组中它甚至更好.系统之间的选择并不容易.我不推荐过时的CVS.另外SVN不是最新一代的分布式版本控制系统,如果没有特殊原因我不建议使用它,并且它会污染所有带有特殊子目录的子目录,这可能很烦人.对于习惯它并且已经编码的人来说它很好,但是对于初学者我会说没有.
在分布式和开源版本控制系统中还有Mercurial和Darcs. Mercurial还拥有一个很棒的商业网站,可以进行协作和在线代码查看(http://bitbucket.org).
4)只要你不使用版本控制系统,如何使用符号链接？
您可以在服务器src / versions / somewhere上有一个目录,并将命名版本放在那里,每个目录都在它们自己的子目录中.您只会添加版本(因为存在的版本不会更改,如果您更改它将成为新版本)
您可以使用src / versions / v001 / src / versions / v002 / src / versions / v003 /或您使用的任何命名方案.
现在来了解诀窍：/ var / www / prod / htdocs是src / versions / v001 /的符号链接
升级到v002时,只需执行以下操作：
>关闭apache
>删除旧的symlink / var / www / prod / htdocs(此时apache webroot已经消失！)
>创建新的symlink / var / www / prod / htdocs作为src / versions / v002的链接
>启动apache
您还可以使用参数为此编写脚本,并将其调用如下：
upgrade-web prod 002
这使得差距更短.
有时你必须做一个“后备”,当你发现新版本在生产中有错误,你必须回去.这很容易(因为您不删除旧目录,只需停止apache,删除符号链接并将其重新创建到以前的位置,在本例中为src / versions / v001)
如果test和dev在同一台服务器上,你当然也可以对相同的目录进行符号链接,因此不会有任何移动或复制.
5)如果你在没有符号链接的情况下手动完成,为什么不移动而不是复制？
(当文件尚未在同一服务器上时,您可以将它们复制到附近,然后从迁移开始,这样您就不必停止服务器这么长的时间)
如果项目的根级别上有多个目录,则可以一次移动它们.请务必不要移动配置文件.或者找一些策略来为他们带来bakc.工作流程将是：
>停止apache
>移除除根配置文件以外的所有当前prod目录和文件
>将所有新的prod目录和文件移动到根级别,但配置文件除外
>启动Apache
6)尝试找到完美的个人文件和目录布局以及完美的工作流程.这需要一些时间和一些思考,但它付出了代价.在找到最佳解决方案之前,先在纸上进行.这可能意味着您必须重构代码并更改服务器配置文件,但是对于将来,当您进行管理和升级时,您的生活将更加轻松.根据我的经验：不要等这么久这一步.您的布局可以让您轻松安全地升级.升级并不是特别的,它是常规的,它应该是安全和简单的.
7)如果你命名你的服务器和工作站环境(服务器的操作系统是linux我猜,但它是托管服务器还是root服务器,你有ftp access还是shell(ssh)访问,还是sftp？你在哪里开发,在Windows机器上,或Mac？)然后人们可以命名工具来进行复制和移动.同样有趣的是：测试和开发服务器是否是同一台机器,如果没有,它们是如何连接的,或者它们不是？如果没有,您将进行3向传输(将其复制到本地工作站,然后复制到服务器).
8)考虑文件权限.如果您移动文件或复制它们,可能会更改文件权限,如果应用程序依赖于其中一些应该有一种方法来检查并可能更改.示例：某些应用程序需要可写目录,用于放置上载的文件或会话文件或模板缓存.其他应用程序不允许某些安全文件可写.
