1、開發人員需在個人電腦搭建LAMP環境測試開發好的網站代碼，並且在辦公室或IDC機房的測試環境測試通過，最好有專職測試人員。
2、程序代碼上線規定時間，由網站業務性質而定，原則就是影響用戶體驗最小。
3、代碼上線之前需備份，網站程序出了問題方便回退，另外，從上線技巧上將，上傳代碼時盡可能先傳到服務器網站臨時目錄，傳完整後一步mv過去，或者通過ln做軟連接。
線上更新代碼的思路。如果嚴格更新，把應用服務器從集群節點平滑下線，然後更新。
4、盡量由運維人員管理上線，對於代碼的功能性，開發人員更在意，而對於代碼的性能優化和上線後服務器的穩定，運維更在意服務器的穩定，因此，如果網站宕機問題歸運維管，就要讓運維上線，這樣更規範科學。否則，開發隨意更新，出了問題運維負責，這樣就錯了，運維永遠無法擡頭。

中型企業上線解決方案

一般是規範運維人員操作步驟，制定統一的上線操作腳本備份文件名稱、備份文件路徑。使操作人性化，統一化，自動化。
web代碼的上線流程：
1、開發組內部測試
2、測試組內外網測試
3.1、重要升級---》運維組備份
3.2、普通升級---》上線
4、回滾後上線----》運維組代碼回滾
1.2、用戶應用
1.2.2、有問題-----》運維組代碼回滾
1.2.3、上線

大型企業上線解決方案

ITIL,BSW規範。

大型企業java代碼上線流程圖

svn服務器上主要管理：

1.程序代碼
2.服務的配置
3.項目文檔，設計文檔，運維部署優化文檔1234

上線時，大型集群環境一般有數臺及其集群，因此，同時需要更新或者分批更新。

1.本地開發人員從svn中取代碼。當天上線的天機到trunk，否則，長期項目單開分支開發，然後再合並主線（trunk）
2.辦公內網開發測試時，由開發人員或配置管理員通過部署平臺jenkins實現統一部署，（即在部署平臺上控制開發及其從svn取代碼，編譯，打包，發布到開發機，包名如dep.war）
3.開發人員通知或和測試人員一起測試程序，沒有問題後，由配置管理員打上新的tag標記
4.配置管理員，根據上步的tag標記，checkout出上線代碼，並配置好IDC測試環境的所有配置，執行編譯，打包(maven,ant)(pho不需要)，然後發布到IDC內的統一分發服務器，這裏要註意，不同環境的配置文件是隨代碼同時發布的。
5.配置管理員或SA上線人員，把分發的程序代碼內容推送到相關測試服務器，然後通知開發及測試人員進行測試。如果有問題向上回退，繼續修改。
6.如果IDC測試沒有問題，繼續打好tag標記，此時，配置管理員，根據上步的tag標記，checkout出測試好的代碼，並配置好IDC正式環境的所有配置，執行編譯，打包（maven,ant），然後發布到IDC內的統一分發服務器主機，準備批量發布。
7.配置管理員或者SA上線人員，把分發的內容推送得到相關正式服務器，然後通知開發及測試人員進行測試。如果有問題直接發布回滾指令。
IDC正式上線的過程對於JAVA程序，可以是AB組上線的思路，即平滑下線一般的服務器，然後發布更新代碼，重啟然後測試，無問題後，掛上更新後的服務器，同時在平滑下線另一半的服務器，然後發布更新代碼測試（或者直接發布後，重啟，掛上線）

PHP程序代碼上線的具體方案

對於php上線方法：
發布代碼時（也需要測試流程）可以直接發布到正式臨時目錄，然後mv或更改link的方式發布到正式線目錄，不需要重啟http服務。

JAVA程序代碼上線的具體方案

較大公司需要分組平滑上線，例如，首先從負載均衡器上摘掉一半的服務器，發布代碼後，重啟服務器測試，沒問題後，掛上上好線的一半，再下另外一半。如果前端有DN智能解析，上線還可以分地區上線若幹服務器，逐漸普及得到全國的服務器，這個被稱為灰度發布。

代碼上線解決方案註意事項

1.上線的流程裏，版本測試環境--》IDC測試環境--》正式生產環境，所有的環境中的所有軟件均應版本統一，其次，盡量單一，否則將後患無窮，開發測試成功，IDCC測試就可能有問題。
例如：操作系統、web服務器，jdk，php，tomcat,resin等版本
2.開發團隊小組辦公室內部測試環境測試（該測試環境屬於開發小組維護，或定時自動更新代碼），代碼有問題返回給某開發人員重新開發。
3.有專門的測試工程師，程序有問題直接返回給開發人員（此時返回的一般為程序的bug，稱為bug庫），無問題進行IDC測試
4.IDC測試由測試人員和運維人員參與，叫IDCtest,進行程序的壓力測試，有問題直接返回給開發人員，無問題進行線上環境上線
5.數臺服務器代碼分發上線方案（java）:
5.1.假設同業務服務器有6臺，將服務器分為a、b兩組，a組三臺,b組三臺,先對a組進行從負載均衡器上平滑下線，b組正常提供服務，避免服務器因上線影響業務。
5.2.下線過程是通過腳本將a組服務器從rs池(lvs,nginx,haproxy,f5等均有平滑方案)中踢出，避免負載均衡器將請求發送給a組服務器（此時的時間應該為網站流量少時，一般為晚上）
5.3.將代碼分發到a組服務器的站點目錄下，對a組服務器上線並重啟服務，並由專業的測試人員進行訪問測試，測試成功後，掛上a組的服務器，同時下線b組服務器，b組代碼上線操作測試等和a組相同，期間也要觀察上線提供服務的服務器狀態，有問題時及時回滾。
6.如果是php程序，則上線可以簡單化，直接將上線代碼（最好全量）發布到所有上線服務器的特定目錄後，分發完成後，一次性mv或ln到站點目錄，當然測試也是少不了的，測試出了人員測試外，還有各種測試腳本測試各個相關業務接口
7.大多數門戶公司的前端頁面都已經靜態化或者cache了，因此，動態的部分訪問平時就不會特別多，流量低谷時就更少了，再加上是平滑上下線，因此基本上是對用戶體驗無影響的。
8.svn上包含代碼和配置
8.1 svn上存放程序代碼（不含資源，大公司網站資源和程序分離的），盡可能全量上線
8.2 存放所有服務的配置文件（lamp環境，如:apache的httpd.conf配置文件）
8.2.1 開發小組測試環境使用的配置文件
8.2.2 辦公測試環境使用的配置文件
8.2.3 IDC測試環境使用的配置文件
8.2.4 線上應用使用的配置文件
在上線不同環境時，由配置管理員協調上線

什麽是配置管理員？

就是在開發和運維中間起一個連接紐帶的一個職位，這個職位一般在大公司裏會設置，負責svn的管理，上線管理，申請，協調等工作

自動化部署和上線代碼管理平臺

對於門戶網站或重視規範或開發能力較強的公司也許會結合系統服務和web界面管理來更科學更自動的進行上線代碼管理，如開發一個自動化代碼上線部署平臺，其實就是一個web管理界面（界面底層調用相關腳本實現分發推送代碼以及重啟服務器），然後普通的初級上線人員就可以再平臺裏實現僅僅點鼠標、敲回車，就能實現平滑上線和平滑回滾代碼了。

開發自化部署平臺的思路很多，例如：可以通過nagiios的被動模式實現上線管理平臺原理思路：

實際上就是生成配置在分發服務器上執行命令請求，應用服務器，然後腳本在應用服務器處理完畢後回傳結果到web界面顯示

開發人員和運維人員業務變更管理平臺

業務變更管理平臺優點：

1.變更管理制度流程有利於業務穩定
2.保留變更業務歷史，便於核查發現的問題
3.故障跟蹤平臺，有利於跟蹤問題的解決進度，而不是半途而廢
4.相關常用軟件：
4.1 FIRA用戶缺陷跟蹤、客戶服務、需求收集、流程審批、任務跟蹤和敏捷管理等工作領域
4.2 mantis是一款php開源bug跟蹤系統，比較適合中小型項目的管理及跟蹤，具有多特性包括：易於安裝，易於操作，基於web，支持任何可運行php的平臺（windows,linux,max,solaris,as4000/i5等），已經被翻譯成68種語言，支持多個項目，為每一個項目設置不同的用戶訪問級別，跟蹤缺陷變更歷史，定制我的視圖頁面，提供全文搜索功能，內置報表生成功能（包括圖形報表），通過email報告缺陷，用戶可以監視特殊對待bug，附件可以保存在web服務器上或數據庫中（還可以備份到ftp服務器上）,自定義缺陷處理工作流，支持輸出格式包括csv、microsoftExcel、microsoftWord,集成源代碼控制(svn與cvs)，集成wiki知識庫與聊天工具（可選/不可選），支持多種數據庫（mysql,mssql,postgresq,oracle,db2）,提供webService(soap接口)，提供wap訪問

灰度：

專業名詞叫bucket test ,就是桶檢測，抽一部分用戶去檢測。這個有幾種方式，一個是按流量比例來抽，按流量比例來抽就是隨機命中的，有可能有百分之百的用戶有可能都會被命中。還有種情況是根據用戶來抽，比若說根據用戶的cookie來判斷是不是該進入到桶裏面。一般都是針對核心業務的。

代碼上線架構方案