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

語言: CN / TW / HK

背景

在一次會議中,開發同學表達了希望能拿到執行修改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也必須啟動。這要我們做到很好的解耦。

後記

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

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

往期好文: