Benjamin

新人工程師,偶爾分享工作心得(預計?

工作隨筆--層層把關的開發環境

敝公司的程式環境分成四種,local(簡稱L)、develop(簡稱D)、staging(簡稱S)、production(簡稱P),和git flow有點像,但是各分支的定義及名稱不太一樣。

除了L是指工程師自己開發用的電腦,無固定分支之外,其他三個都是專案的其中一個分支,並且在某台雲端的機器運行。

最好說明的是P,即為網站用戶使用的版本,可以想見被要求盡可能的穩定,以及維護用戶的個人資料,工程師沒有權限直接從資料庫查看及修改資料。

開發新功能時,我們會從D開一個新的分支,過程中在L確認功能的完整性,確保沒問題後將程式合併到D分支,同時D運行的機器也會重新執行程式,企劃在D環境測試功能是否完整達成企劃書要求,或者是中途發現未考慮到的情境。總之發現東西需要修改時通知工程師就對了,然後工程師再次從D開一個新的分支進行開發。

除此之外在D環境中,為了方便開發、找出錯誤,工程師擁有權限查看及手動修改資料庫內容。


大約兩週一次,主要的功能開發完成,企劃在D也初步驗收完成後,會安排將D合併到S分支,在S繼續驗收。畢竟是使用git,合併時沒辦法挑選哪些改動要上哪些不要,因此如果有未完成的功能會一起合併的話,需要在該部分程式外加上環境判斷,例如「如果環境是L或D才執行」這樣的條件,避免影響現有的已完成功能。

S環境的權限控管被設定為和P差不多,在S環境下工程師同樣沒有權限直接從資料庫查看及修改資料,如果真的有必要,必須照著一定的流程建立資料異動單,在其中註明使用原因以及讀寫資料庫的語法留作紀錄,並交由負責人執行。

因此S環境出錯時不容易找錯誤,只能從程式運作的log確認錯誤訊息,整理觸發錯誤的操作流程,然後回頭檢查對應的程式邏輯。


待S驗收完畢,就能將S合併到P,也就是正式上線了。上線之後還是會繼續使用測試帳號進行驗收,不過這時如果出錯就會真的影響到用戶,導致客服被打爆。

所以這時發現的問題,會走緊急修復的流程,在L開發完合併到D,確定解決該錯誤後,直接將修改的內容合併到P,當然其他不相干的程式還是要照著D→S→P的正常流程,逐步驗收完畢才能上線。


真的開始開發及維護服務後,就會了解到穩定運作的網頁背後需要下多少功夫,並對有時大更新後的大量bug更能諒解。

同時對於正常操作就能觸發的bug,感到驗收之鬆散進而火大。

發佈評論

看不過癮?

馬上加入全球最高質量華語創作社區,更多精彩文章與討論等著你。