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