检测开发到生产服务器路径问题

时间:2010-08-11 06:14:58

标签: php deployment

我们在开发LAMP应用程序时使用了一个开发服务器。

我们还有一个部署了我们网站的生产服务器。

有时,在生产服务器上部署网站时,我们忘记更新某些路径。有时,我们发现生产网站仍然在开发服务器上引用图像,脚本和样式表。检测这些路径问题可能很棘手,我正在寻找创造性的方法来帮助检测这些不正确的路径。

1)我们可以阻止从开发服务器到生产服务器的所有访问。这将使我们能够更容易地检测到错误的路径,因为它会导致错误或图像损坏,而不是显得正常。

2)另一个选择是我们可以阻止任何外部网站链接到开发服务器上的图像。 (http://altlab.com/htaccess_tutorial.html)。 任何指向开发服务器上图像的链接都可以替换为带有“INCORRECT PATH”之类的图像。

还有哪些其他选择?

(注意:我同意目标是首先在生产服务器上防止出现这些路径问题,这可以使用代码版本控制和部署工具等完成。但是,在此对话中我特意寻找检测这些路径问题的方法。这是我正在寻找的额外质量控制层......)

8 个答案:

答案 0 :(得分:1)

您必须将依赖于环境的设置放入虚拟主机配置中。 放置此

SetEnv IMAGE_PATH = '/var/www/images/'

生产服务器上的虚拟主机内部。

在PHP代码中,使用

getenv('IMAGE_PATH')

获取路径

当然,在本地环境中,虚拟主机上的值必须不同。

完成此操作后,任何部署都不需要任何站点更新。 如果您有很多要求,则只能创建一个变量,并使用它在运行时加载两个不同的配置文件之间切换

答案 1 :(得分:0)

最好在服务器上的配置文件中有一个选项,这将允许您在dev和prod环境之间切换。

答案 2 :(得分:0)

我认为处理路径的最简单方法是在两个服务器中使用相同的确切代码。无论何时需要提供完整的绝对路径,请定义适当的常量:

<?php

include_once(FS_ROOT . 'lib/foo.php');
echo '<link href="' . WEB_ROOT . 'css/bar.css" rel="stylesheet" type="text/css">';

?>

可以在未版本控制的文件中设置这些常量:

define('FS_ROOT', '/home/project/htdocs/');
define('WEB_ROOT', '/');

...或者可以使用__FILE__$_SERVER['DOCUMENT_ROOT']dirname()等动态计算。

答案 3 :(得分:0)

Apache Logs

要诊断已经发生这种情况的位置,您应该能够检查开发服务器上的服务器日志,以查看从意外位置请求的文件。使用日志分析可以帮助您识别需要修复的特定情况,而不会中断服务。

基本apache日志应该具有请求每台服务器上的文件的计算机的IP。您应该能够筛选出您或您的团队正在使用的任何IP,并查看外部IP提取服务器上的哪些文件。

更强大的日志分析工具可能能够帮助您确定哪些请求来自另一个域。您可能希望查找旨在防止热链接的工具。

反思

我认为有两种合理的选项来审核您的代码以找到问题。

第一个选项是在代码上使用搜索工具(grepgrepwin),然后在代码中搜索开发域。如果你使用一些复杂的代码将域拼接在一起,这可能不起作用,但如果你只是在所有地方硬编码值,这可能是神奇的子弹。

第二个选项是抓取您自己的网站并在呈现的HTML中搜索坏域。这样做的好处是你可以立即看到实际问题,但不足的是,如果蜘蛛不能或不能访问某些页面,你可能会错过一些。

答案 4 :(得分:0)

我通常会确保开发工作站和登台/测试服务器上的路径不一样。例如,在开发工作站上,它是localhost / websitename / path,并且正在暂存它的websitename / path。

当你从localhost转到staging / testing时,这会导致所有类型的东西明显中断 - 这样你就可以确保你的路径被动态嗅探或使用适当的常量。

是的我正在假设版本控制,部署程序等。

是查找/替换,grep,蜘蛛都是你的朋友来修复你开始使用Firebug .NET标签的鼠窝也是有帮助的

答案 5 :(得分:0)

如果你不能为资源使用相对路径(例如,因为静态文件是从不同的主机名提供的),那么确保你不是硬编码绝对路径除了单个配置文件之外的任何地方都是一个好主意。包含在您的网络应用初始化位置的顶部附近。

答案 6 :(得分:0)

我同意banzaimonkey,但我会从爬虫开始。使用Web服务器日志假定正在定期访问问题图像,样式表等。位于网站深处或很少访问过的网页上的网页或链接很容易被遗漏。抓取页面应该可靠地找到它们。

我绝不是专家,但我一直在研究一个类似的问题。我的解决方案是使用Perl和WWW :: Mechanize模块来抓取整个站点并记录页面的各个方面。就我而言,我想要一个坏链接列表,特定表单,多媒体对象以及其他五件事。我能够构建脚本,因此它将特定主机视为“本地”(在许多域中有大约80个站点)。你应该能够通过识别“坏”链接来反过来做同样的事情。这假设您在部署生产站点后进行测试。您可能会做一些允许在部署之前进行检查的变体。

另一种选择是查看已编写的爬虫,并查看其结果。 Internet Archive已生成Heritrix,可在网站上抓取,存档和报告。这可能有点矫枉过正了。类似LinkChecker的选项可以与详细选项一起使用,然后输出为开发服务器名称/ IP地址的实例进行grepped。我确信这条线上还有很多其他选择。

我提到这些主要是因为我认为你想要的东西比手动检查每个页面更能自动化过程。这些工具可能需要一些时间才能完成,因为它们遍历整个站点,但它们可以提供完整的图像。我的处理不好的主要事情是javascript和表单。 Heritrix实际上处理了一些JavaScript链接,但仍然无法处理表单。

也就是说,WWW :: Mechanize和其他模块可以以编程方式提交表单,但需要给出特定的值。在您的情况下,如果您有一个大型数据库,您可能只需要提交一个或两个表单值来验证图像等,而不是来自开发服务器。从好的方面来说,您还可以检查返回的内容以确保表单正常工作。我今天遇到了分页导航问题 - 无论选择哪个页面,该页面都提供相同的20个结果。通过测试结果集中的特定字符串可以自动检查这一点(这是进入测试驱动开发的领域)。

另一件事 - Heritrix实际上创建了档案。它是Internet Archive上WayBack Machine的基础。如果您或您的组织感兴趣保留多个版本的网站,您可能会获得附加利益。

答案 7 :(得分:0)

不要等错。

有一些免费实用程序,用于一次搜索多个文件上的特定文本,包括子文件夹。他们可以返回包含您要查找的搜索文本的每个文件和行的日志。找到其中一个实用程序,并搜索错误的域,它将提取每个实例的列表。

您甚至可以使用相同的实用程序进行替换。