網頁代碼上線詳解

第1章 代碼上線

1.1 早期手動部署代碼

純手動scp上傳代碼

純手動登錄，Git pull或者SVN update

純手動xftp上傳代碼

開發發送壓縮包，rz上傳，解壓部署代碼

1.1.1 缺點

全程運維參與，佔用大量時間

若是節點多，上線速度慢

人爲失誤多，目錄管理混亂

回滾不及時，或者難以回退

SVN目錄組織結構說明：

1 tree /home/oldboy/svn/

2 home /oldboy/svn/

3 |–branch #分支爲測試使用，幾個以上的項目必須開分支，測試須要本分支經過，主線合併到分支經過，才能合併到主線進行測試

4 |–tags #版本記錄用 5 –trunk #主線，與正式先相對應，當天不上線文件不容許提交 

以上爲SVN開發人員目錄狀況

1.2 小型公司代碼上線案例

 

1.2.1 現狀分析

小型公司通常只有幾個開發人員，且網站核心程序大多數都是PHP語言開發。爲了方便會直接經過FTP直接上傳程序代碼到線上服務器，隨時隨地上線更新

1.2.2 特色問題

01.發佈快且及時，隨時隨地就能夠發佈代碼

02.開發人員發佈的代碼不通過測試人員的測試，且用戶訪問頁面刷新頁面即改變，也可能刷新瞬間程序在更新，到時沒法訪問，對網站用戶的體驗比較差，若是開發寫錯了代碼，形成的影響就更大了，這是拿用戶做爲測試的上線方案

03.據統計，網站中50%以上的故障是開發和開發程序的代碼有關(開發寫錯了一個循環代碼致使了死循環，此時大量的用戶訪問這個程序，就能把服務器資源耗盡，搞死服務器)

04.在中小公司，網站出了問題，通常是運維人員的問題(如網站宕機)但這種狀況呢下，問題大多可能由開人員或者代碼引發的，這裏比較好的策略是開發項目負責制思想

1.2.3 架構方案建議(項目負責制)

01.開發人員需在我的電腦搭建LNMP環境[xampp 一鍵化集成lamp包]測試開發好的網站代碼，並在辦公室或IDC機房的測試環境測試經過，最好有專職測試人員

02.程序代碼上線規定時間如三天上線一次，若網站需常常更新可天天下午17點上線，這個看網站業務性質而定，原則即影響用戶體驗最小(用戶體驗最好)

03.代碼上線以前需備份，網站程序出了問題方便回退；另外上傳代碼時儘量先傳到服務器網站臨時目錄，傳完整後一步mv過去，或經過ln作軟連接

04.儘可能由運維人員管理上線，由於開發人員更在乎代碼的功能性，而運維更在乎服務器的穩定。故網站宕機歸運維管就要讓運維上線，不然開發隨意更新，出了問題運維負責，運維將沒法擡頭

1.3 中型公司代碼上線案例

 

1.3.1 現狀分析

中型企業上線，通常是規範運維人員操做步驟，指定統一的上線操做腳本，備份文件名稱，備份文件路徑，使操做人性化、統一化、自動化

1.4 大型公司代碼上線案例

大型企業上線通常制度和流程控制較多，比較嚴謹，下圖爲某大型企業上線解決方案

 

上線分爲兩部分：

 

1.4.1 架構方案建議

1)上線的流程裏，辦公室測試環境-->IDC測試環境-->正式生產環境，全部環境中的全部軟件均應版本統一，其次儘可能單一不然將後患無窮。開發測試成功，IDC測試就可能有問題(如操做系統，web服務器，jdk,php,tomcat,resin等版本)

2)開發團隊小組辦公內部測試環境測試，代碼有問題返回給某開發人員從新開發

3)有專門的測試工程師，程序有問題直接返回給開發人員(此時返回的通常爲程序的BUG，稱爲BUG庫)，無問題進行IDC測試

4) IDC測試由測試人員和運維人員參與，叫IDCtest,進行程序的壓力測試，有問題直接返回給開發人員，無問題進行線上環境上線。

5)數臺服務器代碼分發上線方案舉例(JAVA程序)

A:假設同業務服務器有6臺，將服務器分爲A,B兩組，A組三臺，B組三臺，先對A組進行從負載均衡器上平滑下線，B組正常提供服務，避免服務器因上線影響業務。

B:下線過程是經過腳本將A組服務器從RS池(LVS,NGINX,HAPROXY,F5等均有平滑方案)中踢出，避免負裁均衡器將請求發送給A組服務器(此時的時間應該爲網站流量少時，通常爲晚上)

C:將代碼分發到A組服務器的站點目錄下，對A組服務器上線並重啓服務，並由專業的測試人員進行訪問測試，測試成功後，掛上A組的服務器，同時下線B組服務器，B組代碼上線操做測試等和A組相同，期間也要觀察上線提供服務的服務器情況，有問題及時回滾。

6)特別說明：若是是PHP程序，則上線能夠簡單化，直接將上線代碼全量發佈到全部上線服務器的特定目錄後，分發完成後，一次性mv或ln到站點目錄，固然測試也是少不了的。測試除了人員測試外，還有各類測試腳本測試各個相關業務接口

7)大多數門戶的前端頁面都已經靜態或者cache了，因上經動態的部分訪問平時就不會特別多

1.5 其餘程序代碼上線案例

1.5.1 Java程序代碼上線的具體方案

較大的公司須要分組平滑上線，如先從負載均衡器上摘掉一半的服務器，發佈更新代碼後重啓服務器測試，確認沒有問題後掛上更新後的服務器；同時再下線另外一半的服務器，而後發佈更新代碼測試(或直接發佈後重啓，掛上線)

若是前段有DNS智能分析，上線能夠分地區上線若干服務器，逐漸普及到全國的服務器，即爲灰度發佈

1.5.1.1  IDC正式上線環節

分組上線：A、B兩線

1 以Nginx爲例，三套配置文件：
2   一套是所有服務器的配置文件
3   一套是A的配置文件
4   一套是B的配置文件
5 須要哪一套配置文件，直接cp後reload nginx服務便可

注意：開發環境、測試環境、生產環境統一系統、軟件版本、統一路徑、IP、主機名等

1.5.1.2 架構方案建議

1)本地開發人員取svn代碼。當天上線提交到trunk，不然，長期項目單開分支開發，而後在合併主線(trunk)

2)辦公內網開發測試時，由開發人員或配置管理員經過部署平臺jenkins實現統一部署(即在部署平臺上控制開發機器從svn取代碼，編譯，打包，發佈到開發機，包名如idc_dep.war)

3)開發人員通知或和測試人員一塊兒測試程序，沒有問題後，由配置管理員打上新的tag標記。這裏要注意：不一樣環境的配置文件是隨代碼同時發佈的。

4)配置管理員，根據上一步的tag標記，checkout出上線代碼，並配置好IDC測試環境的全部配置，執行編譯，打包[mvn,ant] (php不須要打包)，而後發佈到IDC內的統一分發服務器

5)配置管理員或SA上線人員，把分發的程序代碼內容推送到相關測試服務器(包名如idc_test.war)，而後通知開發及測試人員進行測試。若是有問題向上回退，繼續修改

6)若是IDC測試沒有問題，繼續打好tag標記，此時，配置管理員，根據上步的tag標記，checkout出測試好的代碼，並配置好IDC正式環境的全部配置，執行編譯，打包[mvn,ant] (php不須要打包)，而後發佈到IDC內的統一分發服務器主機，準備批量發佈

7)配置管理員或SA上線人員，把分發的內容推送到相關正式服務器(包名如idc_product.war)，而後通知開發及測試人員進行測試，若是有問題直接發佈回滾指令

若是是大型門戶網站，全國上線，使用灰度發佈

1.5.2 php程序代碼上線的具體方案

發佈代碼時(也須要測試流程)能夠直接發佈到正式線臨時目錄，而後mv或更改link的方式發佈到正式上線目錄，不須要重啓http服務。這是新朗，趕集的上線方案

 

參考文獻https://mp.weixin.qq.com/s?__biz=MzAxOTE5NjQwOA==&mid=2650113445&idx=1&sn=ca4231f30a39872db9fb6893d5740d49&chksm=83cb9532b4bc1c242bba69d52c96e188c43117c3c29fc9b47830e9d390514a3ff26f812e19a6&mpshare=1&scene=23&srcid=0718al9lUYSe5sPlxbcnTn7t#rd

 

 

此筆記是本人學習摘記整理而成，此爲終稿(尚有諸多不完善之處)，原創做品容許轉載，轉載時請務必以超連接形式標明文章原始出處，做者信息和本聲明，不然將追究法律責任。http://www.cnblogs.com/bananaaa/

於2017.12.18 晚從新修改完成，請多多包涵