說明
在工作中漓库，代碼上線是很重要的，而作為上線人員园蝠，對流程要嚴格把控渺蒿，對需要上線代碼的更新是需要仔細研究！彪薛！
向持續(xù)交付前行
在保證上線質(zhì)量的前提下茂装，如何提高上線效率怠蹂，做到自動化部署，持續(xù)交付少态，這是一個值得深入和持久關(guān)注的問題褥蚯。
代碼上線流程
svn代碼更新-->測試環(huán)境上線測試-->測試OK后發(fā)送郵件告知測試結(jié)果給運維，并說明可以上線代碼svn_revision -->上線前記錄svn_revision况增，對比上次上線時的改動，判斷對各服務(wù)連接有無影響训挡，注意配置文件的修改-->匯報上級（確定上線后）-->上線需將所有測試OK的所有代碼統(tǒng)一上線（提前做好備份澳骤，方便出現(xiàn)問題回滾。注意配置文件的變動澜薄，防止更新后各服務(wù)不通）-->對上線后的功能進行測試（通知公司人員進行測試）-->OK郵件通知全員为肮。
注：打標簽(svn tag)是一個更通用的做法。
代碼中運維需要處理的配置
<?php
return [
//緩存中無數(shù)據(jù)時肤京，是否從db中讀取數(shù)據(jù)
'read_data_from_db'=>true,
//用戶頭像
'user_avatar' =>[
//默認的用戶頭像颊艳，不包含域名
'default_avatar' => 'default.jpg',
],
//經(jīng)紀人頭像
'broker_avatar' =>[
//默認的經(jīng)紀人頭像，不包含域名
'default_avatar' => 'default.jpg',
//經(jīng)紀人頭像域名
]
];
保持項忘分，key和svn中的一致性
其中對應(yīng)的項棋枕、key的前后順序保持和svn中的一樣，這樣對于開發(fā)人員妒峦、測試人員來說重斑，出現(xiàn)問題后便于對比。對于運維來說肯骇，僅需要修改對應(yīng)key下的value即可窥浪，根據(jù)線上的實際情況進行修改。對相應(yīng)的注釋笛丙，項和key不要隨意修改漾脂，也不要調(diào)整其前后順序，如果需要調(diào)整胚鸯，則需要到svn中進行調(diào)整骨稿，并且和開發(fā)人員進行交流核實。
** 上線中遇到的問題 **
下面列舉一個上線遇到的問題蠢琳，再次記錄啊终，避免下次出錯：
昨日通知上線后病梢，首先我將svn代碼進行更新绒怨，記錄svn_flag位置點為1392，詢問上傳代碼人員無誤并無嚴重修改后兵迅，更新代碼上線泰讽，因為是首次上線例衍，所以將所有代碼一次性部署到線上昔期，完成后測試無問題。結(jié)束報告佛玄。
在回到家中硼一，公司人員反映，出現(xiàn)問題梦抢，無法登陸般贼，便上去查看api日志訪問日志，發(fā)現(xiàn)有error奥吩，但無處理結(jié)果哼蛆，次日到公司商議解決。
來后霞赫，詢問編寫代碼人員腮介，查看api日志發(fā)現(xiàn)此error后，發(fā)現(xiàn)有一個配置文件仍然是舊版本端衰，進行核對后重新上線代碼叠洗。問題得到解決！
** 簡述原因 **
因為代碼中有一個config目錄旅东，在上線后運維需在config目錄下修改配置灭抑，連接mysql及redis，所以在上代碼前我提前將舊版本和此目錄做好備份抵代，待新代碼上線后名挥，將config目錄替換，本以為一切配置無改變主守。
但是在日志中發(fā)現(xiàn)禀倔，api接口調(diào)用錯誤，返回配置文件發(fā)現(xiàn)参淫，雖然我將舊的config目錄替換救湖，但是此目錄下也做了更新，所以上線并沒有做到同步涎才。
錯誤總結(jié)
通過此次的錯誤鞋既，認識問題的嚴重性，如果當次類問題發(fā)生在正式產(chǎn)品線上耍铜，后果很嚴重邑闺，所以需要嚴格反思，總結(jié)文檔棕兼，提高警惕陡舅，避免以后出現(xiàn)同樣的錯誤。
