代码之家  ›  专栏  ›  技术社区  ›  Cosimo

如果在部署Web应用程序后发现问题,常见的做法是什么?

  •  4
  • Cosimo  · 技术社区  · 5 年前

    我最近遇到了一个问题,我的Java代码在我的本地机器上运行得很好,但是当我把它部署到Web服务器,尤其是DB部分时,它就不起作用了。最糟糕的是服务器不是我的机器。所以我不得不来回检查软件的版本、数据库帐户、设置等等……

    我必须承认,我在系统中的日志记录机制方面做得不好。然而,作为一个经验不足的新手程序员,我不得不接受我的学习曲线。因此,这里有一个非常普遍但重要的问题:

    根据您的经验,如果它在开发机器上工作得很好,但在生产机器上却完全让您吃惊,那么它最有可能出错的地方是哪里?

    感谢您分享您的经验。

    8 回复  |  直到 15 年前
        1
  •  5
  •   olly    15 年前

    生产中而非开发中出现问题的第一个绝对原因是 环境 .

    您的生产机器很可能与开发机器的配置非常不同。例如,您可能在Windows PC上开发Java应用程序,同时部署到基于Linux的服务器。

    尝试和开发与生产中部署的应用程序和库相同的应用程序和库是很重要的。以下是一个快速检查表:

    1. 确保开发中使用的JVM版本与生产计算机上的版本完全相同。( java -version )
    2. 确保应用服务器(如Tomcat、Resin)在生产中与开发中使用的版本相同。
    3. 确保您正在使用的数据库的版本在生产中与在开发中相同。
    4. 确保生产计算机上安装的库(例如数据库驱动程序)与开发中使用的库版本相同。
    5. 确保用户在生产服务器上具有正确的访问权限。

    当然,您不能总是得到相同的结果——现在很多Linux服务器都在64位环境中运行,但情况并非总是如此(还没有!)使用标准显影机。但是,规则仍然是这样的:如果你能让你的环境尽可能地接近,你将最小化出现这种问题的可能性。

    理想情况下,您将构建一个与生产服务器完全(或尽可能接近)具有相同环境的临时服务器(它可以是虚拟机,而不是真正的服务器)。

    如果您负担得起登台服务器,那么部署过程应该是这样的:

    • 确保应用程序在开发中本地运行,并确保所有单元和功能测试在开发中通过。
    • 部署到临时服务器。确保所有测试通过。
    • 一旦满意,就部署到生产中
        2
  •  4
  •   Brian Agnew    15 年前

    您很可能在其他用户帐户下运行。因此,您作为开发人员继承的环境将与生产用户(很可能是一个非常精简的环境)大不相同。您的路径/ld_库\路径(或Windows等效路径)将不同。权限将发生更改等,并且安装的软件将不同。

    我愿意 强烈地 建议维护使用与生产用户相同的软件、权限和环境设置的测试框和测试用户帐户。否则你真的不能保证什么。您真的需要管理和控制生产和测试服务器WRT。帐户/安装的软件等。您的开发框将始终是不同的,但您需要了解这些差异。

    最后,部署健全性检查总是一个好主意。我通常实现一个测试URL,它可以在部署应用程序后立即进行检查。它将执行数据库查询或任何其他需要的关键功能,并通过红绿灯机制明确报告工作/不工作的内容。

        3
  •  2
  •   TechZen    15 年前

    具体来说,您可以检查应用程序中的所有配置文件(*.xml/*.properties),并确保不会对应用程序中的任何路径/变量进行硬编码。

    您应该为每个env维护不同的配置文件。并验证env admin的安装指南。(如果存在)

    其他人描述的所有软件/依赖项列表等的版本除外。

        4
  •  1
  •   user151323    15 年前

    生产机器可能会错过开发机器上的一些库和工具。或者可能有旧版本的。在这种情况下,它可能会干扰正常的软件功能。

    数据库连接情况可能不同,这意味着用户和角色以及访问级别。

        5
  •  1
  •   Esko    15 年前

    一个常见的(尽管很容易检测到)问题是库之间存在冲突,特别是如果您使用Maven或Ivy进行依赖关系管理,并且在部署之前不至少检查一次所有托管依赖关系。

    在我们的测试部署环境中,我们有许多不兼容的日志框架版本,甚至servlet/jsp api.jar:s也有好几倍之多。另外,检查Tomcat/equivalent的shared libraries文件夹包含的内容总是一个好主意,因为有人将postgre的jdbc jar放在了共享文件夹中,所以我们遇到了一些数据库数据源类冲突,并且Project自带了用于jdbc连接的jar。

        6
  •  1
  •   bastianneu    15 年前

    我总是试图得到我的产品正在运行的服务器的精确副本。在一些应用程序之后,当然还有很多bug,我给自己列出了一个常见的bug/提示列表。我为上一个项目测试的另一个解决方案是在该服务器上获取正在运行的软件并尝试对其进行配置。会产生奇怪的效果^^

    最后但同样重要的是,我总是在不同的机器上测试我的应用程序。

        7
  •  1
  •   Shoban    15 年前

    根据我的经验,这个问题没有确切的答案。以下是我面临的一些问题。

    1. 在dev server(windows)中没有打开自动更新,而在生产服务器中打开了自动更新(首先是错误的!)。因此,我的一个Web应用程序由于应用了补丁而崩溃。

    2. 一些批处理作业正在生产应用服务器中运行,这更改了应用程序正在使用的某些数据。

    3. 不是我为我的公司进行部署,所以大多数时候部署人员会错过一些注册表项,或者添加了错误的注册表项。很简单但很难检测(可能对我而言;-)一次,我花了几个小时识别其中一个注册表值中的空间。现在,我们有一个非常长的发布文档,其中包含应用程序使用的所有服务器的所有详细信息,并且有一个“当前版本”的检查列表,部署应用程序的工程师会填写该列表。

    如果我还记得的话,我会再加一点的。

        8
  •  1
  •   Paul Keeble    15 年前

    除了临时服务器之外,确保部署到的环境相同的另一个策略是确保它们是自动设置的。那就是你使用的工具 Puppet 安装服务器拥有的所有依赖项,并在每次安装之前运行安装过程,以便重置所有配置。这样,您就可以确保在开发过程中将该框的配置设置为,并在源代码管理中配置生产环境。