[[419040]]

背景

在一次會議中，開發(fā)同學表達了希望能拿到執(zhí)行修改SIT環(huán)境MySQL schema的修改權限。也就是不經(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)境上進行Schema的修改。我舉一些常見的例子：

1. SIT環(huán)境的的users表中的name字段長度是50，而SIT環(huán)境的是100。上生產(chǎn)環(huán)境用，用戶設置了一個長度80的name值，這時，你在SIT環(huán)境中是無法重現(xiàn)的；

2. 有一天發(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ā)生，還會在構建環(huán)境層面、運維層面發(fā)生。

解決方案

SQL schema的不一致問題，我們通過code review+版本控制來解決。就是從SIT環(huán)境開始，每次SQL變更都必須經(jīng)過code review，每條SQL都進行版本控制。

這個版本控制不是說放到Git倉庫里就可以的，還必須明確的指定SQL的版本。這一點，我們可以通過Flyway實現(xiàn)。下圖是Flyway對于SQL文件的命名規(guī)范：

通過Flyway的方式，我們可以明確的知道不同環(huán)境的MySQL的schema的版本，環(huán)境一致不一致，可以很容易的知道。

以上是從技術上解決環(huán)境不一致的問題。除此之外，筆者還有別的考慮，即文化上的。

在工程化程度不高的團隊，你經(jīng)常會聽到這樣的話：

我在SIT測試是沒有問題的啊！為什么在生產(chǎn)環(huán)境就出問題？我在本地構建是可以的，為什么在Jenkins上就不行？

這樣的話，都有意無意地暗含著一層意思：我沒有問題，那是你的問題。不管你承認不承認。

這層意思會對團隊所帶來的影響是：環(huán)境一致性問題是運維的問題，不是開發(fā)的問題。開發(fā)人只管自己寫完代碼就什么可以不管了。說難聽點，就是只管自己隨地拉，讓別人來收拾。

這種將開發(fā)與運維完全隔離的方式，我們已經(jīng)知道是低效的了，不需要再討論。

但是，開發(fā)的同學會覺得按照以上方式——code review+版本控制——修改schema更低效。想想，你寫一個功能，不可能一次性能寫對，那么，就會反復的修改schema，每修改一次schema，都要進行一次 code review和版本控制，多麻煩。

開發(fā)的問題

說到底那是這個反復調試的過程，應該只出現(xiàn)在自己的本地開發(fā)環(huán)境，而不應該出現(xiàn)在對于大家都有影響的SIT環(huán)境。真實情況應該是你有90%以上的把握，正確完成了手頭上的工作后，再部署到SIT環(huán)境。集成測試環(huán)境應該是用于集成測試的，而不是用于調試開發(fā)的。說到底不少開發(fā)，分不清測試與調試之間的區(qū)別。

如果真的出現(xiàn)意外，那么，這時再“調試”。但是這種場景的出現(xiàn)應該是少數(shù)的。如果頻繁出現(xiàn)，那么應該定義成是開發(fā)人員自己的問題了。

但是，開發(fā)說：我本地啟動一應用來進行調試，就是要連各種依賴的啊，比如MySQL、其它服務、服務發(fā)現(xiàn)中間件等。怎么辦？

這時，一定會有人提出一個解決方案：我們應該還要搭建一個開發(fā)環(huán)境，可以讓開發(fā)盡情搞的環(huán)境。

為什么說“一定會有人”。是因為，這些年經(jīng)歷過5，6個團隊，每到一個團隊，團隊里的人都會提。其實，提出這個解決方案的人是在偷懶，自己不搭建，讓別人搭建。

筆者反對搭建這么一個開發(fā)環(huán)境，并不是因為搭建一個開發(fā)環(huán)境，會增加DevOps的工作。恰恰相反，能快速的搭建一個環(huán)境是DevOps的職責。

筆者真正的理由是：引入這么一個沒有版本控制的開發(fā)環(huán)境，其實是引入另一個環(huán)境不一致性問題。在上集成測試環(huán)境后出現(xiàn)問題，開發(fā)人員又會條件反射地說：我在開發(fā)環(huán)境好好的啊。

開發(fā)的問題，應該由開發(fā)自己解決

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

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

2. 提供方便本地開發(fā)的腳本，比如一個docker-compose.yaml能啟動所有的這個應用的依賴；

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

后記

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