代碼迭代的幾種方式

1. 直接替換代碼
這種適用於本身的博客，多數是託管在虛擬空間上，沒有git一類的進行版本管理，一些很技術很低端的公司，也會這樣進行迭代，在測試服務器上，數據正常了，而後在正式服務器上，直接覆蓋代碼，完成版本迭代。

這樣作除了增長自信，省時間，其餘的基本都沒什麼好處，不推薦。

延伸： 你甚至能夠在服務器上，複製一份正式用的代碼，到一個htdocs下的新目錄，而後用一個端口或者新域名指向這個目錄，將準備迭代的代碼覆蓋到這個目錄，測試沒有bug以後，在能夠複製到正式的目錄，或者直接用apache/nginx指向此目錄。

2. git進行分支控制

在測試服務器上，甚至是其餘git倉庫，開發人員在本地開發，測試，而後將代碼提交到倉庫中，在正式服務器上，也有一個git，有兩個分支，用戶訪問的正式文件目錄是master分支，而後有一個develop分支，從develop分支遠程pull代碼，再將develop分支的代碼合併到master分支，若是有bug，小bug能夠在本地修復，執行相同流程進行合併到master分支，完成修復，若是有大型bug，能夠回滾代碼，修復以後，執行相同的合併流程，完成更新。

延伸： git是一種很強大的工具，能夠有更多應用，參加Git Flow http://blog.jobbole.com/76867/
高度使用git flow能解決更多狀況，例如上線一個版本以後，下一個迭代計劃開發10個功能，在開發了2.5個功能的時候，線上代碼發現bug，須要修復，這種狀況下，咱們不能將開發中的2.5個功能合併到線上，因此單純的develop/master分支不能知足須要，git flow能夠解決這樣的問題。

3. nginx分發一部分流量，灰度上線
在大流量的網站，通常是多臺服務器，此時可使用其中一臺服務器，進行灰度上線，即將代碼提交到此服務器，而後使用nginx/apache控制，分發一部分流量到此服務器，檢測代碼運行狀況和日誌，若是有bug,能夠繼續用nginx/apache將流量今後臺服務器關停，修復bug以後，繼續給此服務器分發流量，無bug狀況下，總體更迭。

其餘我也不太熟悉了，這幾種狀況均可以進行不少詳細的操做和權限管理，防止破壞或者操做失誤致使問題。

來自http://river0314.lofter.com/p... 個人原創文章