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

敝公司的程式環境分成四種，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，感到驗收之鬆散進而火大。