我最近有一個問題，我的java代碼在我的本地機器上工作得很好，但是當我將它部署到Web服務器上，尤其是數據庫部分時，它不起作用。最糟糕的部分是服務器不是我的機器。所以我不得不來回查看軟件版本，數據庫賬戶，設置等...如果我們在部署Web應用程序後發現問題，通常的做法是？
我不得不承認，我沒有做好日誌記錄機制的工作。系統。但作爲一個經驗不多的新手程序員，我不得不接受我的學習曲線。因此，這裏有一個非常普遍但很重要的問題：根據你的經驗，當它在開發機器上完美工作時，最有可能出錯的地方是什麼，但在生產機器上完全令你感到驚訝？
謝謝你分享你的經驗。
生產中發生的問題的絕對首要原因是環境。
您的生產機器配置與開發機器配置的可能性大不相同。例如，您可能正在Windows PC上開發Java應用程序，同時部署到基於Linux的服務器。
嘗試和開發相同的應用程序和庫，這一點很重要，因爲您將在生產環境中進行部署。這裏有一個快速清單：
java -version）。當然，你不能總是得到一切 - 很多Linux服務器現在都在64位環境下運行，而標準開發人員機器並不總是這樣（還！）。但是，規則仍然認爲，如果你能夠讓你的環境儘可能地匹配，你會盡量減少這類問題的可能性。
理想情況下，您應該構建一個與生產服務器完全（或儘可能接近）相同環境的臨時服務器（可以是虛擬機，而不是真實服務器）。
如果你能買得起臨時服務器，部署過程應該是這樣的：
令人驚歎的評論和清單，謝謝。 – 2009-08-25 09:59:25
非常詳細的答案，很棒的工作！ – javashlook 2009-08-25 18:13:06
生產機器可能會遺漏您開發機器上的一些庫和工具。或者可能有更舊的版本。在某些情況下，它可能會干擾正常的軟件功能。
數據庫連接情況可能不同，意味着用戶和角色以及訪問級別。
你很可能在不同的用戶帳戶下運行。因此，作爲開發人員繼承的環境與生產用戶（可能是非常低的環境）大不相同。您的PATH/LD_LIBRARY_PATH（或Windows等效項）將有所不同。權限將發生變化等。另外，安裝的軟件將有所不同。
我會強烈建議維護一個測試框和一個測試用戶帳戶，該帳戶使用與生產用戶相同的軟件，權限和環境進行設置。否則，你真的不能保證任何東西。您確實需要管理和控制生產和測試服務器。賬戶/已安裝的軟件等等。你的開發箱總是會有所不同，但你需要了解它們之間的差異。
最後，部署健全性檢查總是一個好主意。我通常會實施一個測試網址，只要部署該應用程序，就可以進行檢查。它將執行數據庫查詢或任何其他必需的按鍵功能，並通過交通燈機制明確報告哪些工作/不工作。
是的，創建一個與生產環境完全相同的開發環境是一個非常好的做法。 – 2009-08-25 09:45:53
嗯，你不能那樣做，因爲你在開發盒上會有開發工具。例如JDK與JRE等。因此，測試盒的要求。 – 2009-08-25 09:46:38
哦，是的。抱歉。我在最後的評論中沒有得到「測試盒」的含義，我正在考慮製作相同的環境。謝謝。下次我運行一個項目時，我肯定會設置一個「測試框」。 – 2009-08-25 09:56:34
根據我的經驗，這個問題沒有明確的答案。以下是我遇到的一些問題。
自動更新未在開發服務器（Windows）中打開，並且它在生產服務器（首先是錯誤的！）中打開。所以我的一個Web應用程序由於應用了一個補丁而變得很糟糕。
某些批處理作業正在生產應用程序服務器中運行，該服務器更改了我的應用程序使用的某些數據。
不是我爲我的公司進行部署，所以大部分時間部署的人都會錯過某些註冊表項或添加錯誤的註冊表項。簡單但很難察覺（可能對我來說;-)）一旦我花了幾個小時來確定一個註冊表值中的空格。現在我們有一個非常長的發佈文檔，其中包含應用程序使用的所有服務器的所有詳細信息，並且有一個「當前發佈」的檢查列表，供部署應用程序的工程師填寫。
威爾加了更多，如果我記得任何。
一個常見的（雖然不易察覺）問題是相互矛盾的圖書館，特別是如果你使用Maven或常春藤依賴管理，不仔細檢查所有的管理依賴至少部署一次之前。
我們已經有很多不兼容的日誌框架版本，甚至在我們的測試部署環境中，有很多次都是Servlet/JSP API .jar：此外，檢查tomcat /等價物的共享庫文件夾是否是一個好主意，我們有一些數據庫數據源類衝突，因爲有人把postgre的jdbc jar放到了共享文件夾中，並且項目帶有自己的jdbc連接jar 。
我總是嘗試獲取我的產品正在運行的服務器的精確副本。經過一些應用程序，當然還有很多Bug，我自己創建了一個常見的Bug /提示列表。我爲最後一個項目測試的另一個解決方案是在該服務器上運行軟件並嘗試對其進行配置。奇怪的影響可以發生在那^^
最後但並非最不重要..我總是在不同的機器上測試我的應用程序。
除了臨時服務器外，確保部署環境相同的另一種策略是確保它們是自動設置的。那就是使用類似Puppet這樣的工具來安裝服務器所具有的所有依賴關係，並在每次安裝之前運行安裝過程，以便重置所有配置。通過這種方式，您可以確保配置框是您在開發過程中設置的配置，並在源代碼管理中配置生產環境。
具體而言，您可以檢查應用程序中的所有配置文件（* .xml/* .properties），並確保您沒有在應用中編寫任何路徑/變量的硬編碼。
您應該爲每個env維護不同的配置文件。並從env admin驗證安裝指南。 （如果存在）
除了其他版本所描述的所有軟件/依賴列表等版本。
謝謝。這個問題的目的是從經驗豐富的程序員那裏收集他們認爲在生產混亂時可能會出錯的想法，但是開發並沒有線索。 但是，你是絕對正確的。這個問題有很多可能的答案，因爲它是普遍的。 – 2009-08-25 09:52:40