流程上,面對開發環境的需求

其實有更深層的問題

Posted by willsbor Kang on 2019-02-25

當需求被提出來的時候

前幾天開會,有位同事提出了一個需求:

Android 平台上,除了 staging server, production server 環境之外,還有 side server 環境,但是 iOS 卻沒有的 side server 的環境,希望 client 端和後台都能幫忙建立一下。

而我在一開始覺得這個功能在 client 上不會太難,而且既然 android 開發流程上都有,我也覺得沒什麼好不弄的。

不過 Server side 的同事 A,提出了一些質疑,聽完之後覺得還蠻有道理的。

「這個 side server 的環境,是介於 staging 和 production 之間,但是在正常的開發狀況下,應該要確保 staging 和 production 之間的環境是一致的,production 發生的問提能在 staging 複製出來。」

同事 A 這樣說

「而目前的 staging 其實比較像是 develop 環境,所以上面有很多開發或驗證過程中產生的髒資料。因此 QA 才會想要有 side server,在完整發佈之前,能先看看是否有修正問題。」

「比較健康的想法還是要讓 staging 更像 staging 才是。不過還是 case by case 啦」

同事 A 用了他慣用的口頭禪來結尾。

對!早在兩三年前,剛加入開發 client App 的時候,就有提出類似的疑問,為什麼開發的過程不是連 staging or develop 而是直接連 production server 呢?

「因為 staging 的資料不夠齊全,所以直接用 production 來看…」過去的同事這樣說

因此,產生了目前許多要修補的坑,像是資料庫內有重複的號碼,或是一些奇怪的回報資料,搞不清楚是 QA 測試加的,還是真的有使用這樣回覆。

沒有從根本把需要注意的事情改善,這樣的事情只會一再發生…

然而…除非是新的 api,看到許多同事,至今開發過程還是用 production 開發。

這個環境在 iOS 上不見得要預先處理,至少等到前端真的有需求,再幫忙設定都還來得及。只是我們都必須去思考最初的問題是什麼…