第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 晚重新修改完成，請多多包涵