代碼迭代的幾種方式

Simon_Zhou 發(fā)布于2019-06-27 15:38 / 2561人閱讀

摘要：直接替換代碼這種適用于自己的博客，多數(shù)是托管在虛擬空間上，沒有一類的進(jìn)行版本管理，一些很技術(shù)很低端的公司，也會(huì)這樣進(jìn)行迭代，在測試服務(wù)器上，數(shù)據(jù)正常了，然后在正式服務(wù)器上，直接覆蓋代碼，完成版本迭代。

1. 直接替換代碼
這種適用于自己的博客，多數(shù)是托管在虛擬空間上，沒有g(shù)it一類的進(jìn)行版本管理，一些很技術(shù)很低端的公司，也會(huì)這樣進(jìn)行迭代，在測試服務(wù)器上，數(shù)據(jù)正常了，然后在正式服務(wù)器上，直接覆蓋代碼，完成版本迭代。

這樣做除了增加自信，省時(shí)間，其他的基本都沒什么好處，不推薦。

延伸： 你甚至可以在服務(wù)器上，復(fù)制一份正式用的代碼，到一個(gè)htdocs下的新目錄，然后用一個(gè)端口或者新域名指向這個(gè)目錄，將準(zhǔn)備迭代的代碼覆蓋到這個(gè)目錄，測試沒有bug之后，在可以復(fù)制到正式的目錄，或者直接用apache/nginx指向此目錄。

2. git進(jìn)行分支控制

在測試服務(wù)器上，甚至是其他git倉庫，開發(fā)人員在本地開發(fā)，測試，然后將代碼提交到倉庫中，在正式服務(wù)器上，也有一個(gè)git，有兩個(gè)分支，用戶訪問的正式文件目錄是master分支，然后有一個(gè)develop分支，從develop分支遠(yuǎn)程pull代碼，再將develop分支的代碼合并到master分支，如果有bug，小bug可以在本地修復(fù)，執(zhí)行相同流程進(jìn)行合并到master分支，完成修復(fù)，如果有大型bug，可以回滾代碼，修復(fù)之后，執(zhí)行相同的合并流程，完成更新。

延伸： git是一種很強(qiáng)大的工具，可以有更多應(yīng)用，參加Git Flow http://blog.jobbole.com/76867/
高度使用git flow能解決更多情況，例如上線一個(gè)版本之后，下一個(gè)迭代計(jì)劃開發(fā)10個(gè)功能，在開發(fā)了2.5個(gè)功能的時(shí)候，線上代碼發(fā)現(xiàn)bug，需要修復(fù)，這種情況下，我們不能將開發(fā)中的2.5個(gè)功能合并到線上，所以單純的develop/master分支不能滿足需要，git flow可以解決這樣的問題。

3. nginx分發(fā)一部分流量，灰度上線
在大流量的網(wǎng)站，一般是多臺(tái)服務(wù)器，此時(shí)可以使用其中一臺(tái)服務(wù)器，進(jìn)行灰度上線，即將代碼提交到此服務(wù)器，然后使用nginx/apache控制，分發(fā)一部分流量到此服務(wù)器，檢測代碼運(yùn)行情況和日志，如果有bug,可以繼續(xù)用nginx/apache將流量從此臺(tái)服務(wù)器關(guān)停，修復(fù)bug之后，繼續(xù)給此服務(wù)器分發(fā)流量，無bug情況下，整體更迭。

其他我也不太熟悉了，這幾種情況都可以進(jìn)行很多詳細(xì)的操作和權(quán)限管理，防止破壞或者操作失誤導(dǎo)致問題。

來自http://river0314.lofter.com/p... 我的原創(chuàng)文章