Web應用程序部署到有限的用戶人口

Question

我試圖確定部署已建立的Web應用程序的新版本的最佳方式。過去，我已經完成了兩種不同的方式，但這次我們希望做一些不同的更好的事情。

我們正在使用開發/登臺/生產服務器。開發完成並測試了基本功能後，我們使用升級服務器上的升級生產數據庫運行開發代碼。如果我們的內部質量檢查在分段環境中沒有發現問題，我們將實施這些更改。

這最後一步在以下兩個方面已經完成：

1. 升級代碼，並在低使用率的時間數據庫 模式，做一個 位的測試，以確保 升級然後交叉手指 ，並希望用戶找不到一些 錯誤，表明QA錯過了，總是準備好 撲滅火災或在 主要失敗的情況下恢復到以前的版本 。

2. 在另一個URL上創建新版本的 應用程序。將 生產數據庫複製到新的 版本，將其清空，然後複製 爲選定用戶提供的數據，並讓 他們使用新的URL。即，他們 將訪問來自 www2.example.com而不是 www.example.com的應用程序。將每個 用戶緩慢移至新版本，然後切換 這個網址。

這次我正在看做兩種方法的組合。基本上，我正在考慮將少量用戶移至新服務，同時保持相同的網址。

以下是我正在考慮在虛擬主機中執行的操作。當新用戶移動時，Map.txt會被生成/更新。 （我看着使用PRG重寫地圖，恐怕阿帕奇掛等待腳本。）

<VirtualHost *:80> 
ServerAdmin webmaster@lotsa.net 
DocumentRoot /web/www.example.com 
ServerName www.example.com 

RewriteEngine on 

RewriteMap deploymentmap txt:/web/map.txt 

RewriteRule ^/id/([0-9]+)/(.*)$ ${deploymentmap:$1}/id/$1/$2 

</VirtualHost> 

map.txt: 

10001 /web/www2.example.com/ 
10002 /web/www2.example.com/ 
10003 /web/www2.example.com/ 
10004 /web/www2.example.com/ 
10005 /web/www2.example.com/ 

是否有此部署策略的任何明顯的缺陷？我錯過了一些簡單而有效的，不太痛苦的升級方法嗎？

感謝您的任何援助。

- 保羅

Answer 1

沒有人回答，所以我會回答自己的後代。 :-)

這種方法在舊代碼庫上分階段部署新代碼庫時效果很好。在我們的特定情況下，我們使用類似於上述的方法進行了推廣。最初，所有用戶都是從舊系統開始的，重寫映射文件的大小約爲800K。由於新的重寫指令，服務器提供了超過10萬個頁面，速度沒有明顯的差異。

我感到驚訝的是，在進行更改以從文件中刪除條目後，Apache不必重新啓動（文檔意味着此文件在啓動時只能讀取）。阿帕奇馬上接受了對地圖的更改，因此它必須在每次請求時查看它，或者更可能檢查時間戳/校驗和以查看它是否不同。

類似的技術不僅可以用於部署，還可以用於A/B測試，尤其是在數據結構不變的情況下。