為什么我不允許開發人員修改測試環境的MySQL Schema
背景
在一次會議中，開發同學表達了希望能拿到執行修改SIT環境MySQL schema的修改權限。也就是不經過任何review，都可以隨意的在SIT環境執行任何的SQL。
根本問題
首先要說明下，SIT環境是集成測試環境。n 大于10。這個環境目前只允許通過自動化部署實現部署。UAT環境和PROD環境都采用同樣的方式部署。
接下來，我想說明我為什么反對開發人員隨意在此環境上進行Schema的修改。我舉一些常見的例子：
-
SIT環境的的users表中的name字段長度是50，而SIT環境的是100。上生產環境用，用戶設置了一個長度80的name值，這時，你在SIT環境中是無法重現的；
-
有一天發現生產環境的某個功能很慢，從監控看，是某條SQL很慢。經分析發現該表沒有建索引。原來是開發人員發布生產環境時，忘記提供增加索引的SQL了。
以上例子，說到底就是環境不一致的問題。這些是軟件工程中非常常見的問題。環境不一致的問題除了在SQL層面發生，還會在構建環境層面、運維層面發生。
解決方案
SQL schema的不一致問題，我們通過code review+版本控制來解決。就是從SIT環境開始，每次SQL變更都必須經過code review，每條SQL都進行版本控制。
這個版本控制不是說放到Git倉庫里就可以的，還必須明確的指定SQL的版本。這一點，我們可以通過Flyway實現。下圖是Flyway對于SQL文件的命名規范：
通過Flyway的方式，我們可以明確的知道不同環境的MySQL的schema的版本，環境一致不一致，可以很容易的知道。
以上是從技術上解決環境不一致的問題。除此之外，筆者還有別的考慮，即文化上的。
在工程化程度不高的團隊，你經常會聽到這樣的話：
我在SIT測試是沒有問題的啊！為什么在生產環境就出問題？我在本地構建是可以的，為什么在Jenkins上就不行？
這樣的話，都有意無意地暗含著一層意思：我沒有問題，那是你的問題。不管你承認不承認。
這層意思會對團隊所帶來的影響是：環境一致性問題是運維的問題，不是開發的問題。開發人只管自己寫完代碼就什么可以不管了。說難聽點，就是只管自己隨地拉，讓別人來收拾。
這種將開發與運維完全隔離的方式，我們已經知道是低效的了，不需要再討論。
但是，開發的同學會覺得按照以上方式——code review+版本控制——修改schema更低效。想想，你寫一個功能，不可能一次性能寫對，那么，就會反復的修改schema，每修改一次schema，都要進行一次 code review和版本控制，多麻煩。
開發的問題
說到底那是這個反復調試的過程，應該只出現在自己的本地開發環境，而不應該出現在對于大家都有影響的SIT環境。真實情況應該是你有90%以上的把握，正確完成了手頭上的工作后，再部署到SIT環境。集成測試環境應該是用于集成測試的，而不是用于調試開發的。說到底不少開發，分不清測試與調試之間的區別。
如果真的出現意外，那么，這時再“調試”。但是這種場景的出現應該是少數的。如果頻繁出現，那么應該定義成是開發人員自己的問題了。
但是，開發說：我本地啟動一應用來進行調試，就是要連各種依賴的啊，比如MySQL、其它服務、服務發現中間件等。怎么辦？
這時，一定會有人提出一個解決方案：我們應該還要搭建一個開發環境，可以讓開發盡情搞的環境。
為什么說“一定會有人”。是因為，這些年經歷過5，6個團隊，每到一個團隊，團隊里的人都會提。其實，提出這個解決方案的人是在偷懶，自己不搭建，讓別人搭建。
筆者反對搭建這么一個開發環境，并不是因為搭建一個開發環境，會增加DevOps的工作。恰恰相反，能快速的搭建一個環境是DevOps的職責。
筆者真正的理由是：引入這么一個沒有版本控制的開發環境，其實是引入另一個環境不一致性問題。在上集成測試環境后出現問題，開發人員又會條件反射地說：我在開發環境好好的啊。
開發的問題，應該由開發自己解決
以上說的開發問題，我覺得對于團隊更高效的解決辦法是：
-
推廣單元測試。這樣可以減少集成測試的需要；
-
提供方便本地開發的腳本，比如一個docker-compose.yaml能啟動所有的這個應用的依賴；
-
使每個應用都應該能不依賴其它應用獨立運行的。比如正在A調用B這樣的關系，我們應該能做到A啟動時不應該于B也必須啟動。這要我們做到很好的解耦。
后記
環境的一致性的維持需要團隊中所有的人共同實現。不應該只是由環境的搭建者來維持。
