為什麼我不允許開發人員修改測試環境的MySQL Schema

背景

在一次會議中，開發同學表達了希望能拿到執行修改SIT環境MySQL schema的修改許可權。也就是不經過任何review，都可以隨意的在SIT環境執行任何的SQL。

根本問題

首先要說明下，SIT環境是整合測試環境。n 大於10。這個環境目前只允許通過自動化部署實現部署。UAT環境和PROD環境都採用同樣的方式部署。

接下來，我想說明我為什麼反對開發人員隨意在此環境上進行Schema的修改。我舉一些常見的例子：

1. SIT環境的的users表中的name欄位長度是50，而SIT環境的是100。上生產環境用，使用者設定了一個長度80的name值，這時，你在SIT環境中是無法重現的；

2. 有一天發現生產環境的某個功能很慢，從監控看，是某條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的職責。

筆者真正的理由是：引入這麼一個沒有版本控制的開發環境，其實是引入另一個環境不一致性問題。在上整合測試環境後出現問題，開發人員又會條件反射地說：我在開發環境好好的啊。

開發的問題，應該由開發自己解決

以上說的開發問題，我覺得對於團隊更高效的解決辦法是：

1. 推廣單元測試。這樣可以減少整合測試的需要；

2. 提供方便本地開發的指令碼，比如一個docker-compose.yaml能啟動所有的這個應用的依賴；

3. 使每個應用都應該能不依賴其它應用獨立執行的。比如正在A呼叫B這樣的關係，我們應該能做到A啟動時不應該於B也必須啟動。這要我們做到很好的解耦。

後記

環境的一致性的維持需要團隊中所有的人共同實現。不應該只是由環境的搭建者來維持。

希望瞭解更多的實踐，歡迎關注公眾號：持續交付實踐指南

往期好文：