[[419040]]

背景

在一次會(huì)議中，開(kāi)發(fā)同學(xué)表達(dá)了希望能拿到執(zhí)行修改SIT環(huán)境MySQL schema的修改權(quán)限。也就是不經(jīng)過(guò)任何review，都可以隨意的在SIT環(huán)境執(zhí)行任何的SQL。

根本問(wèn)題

首先要說(shuō)明下，SIT環(huán)境是集成測(cè)試環(huán)境。n 大于10。這個(gè)環(huán)境目前只允許通過(guò)自動(dòng)化部署實(shí)現(xiàn)部署。UAT環(huán)境和PROD環(huán)境都采用同樣的方式部署。

接下來(lái)，我想說(shuō)明我為什么反對(duì)開(kāi)發(fā)人員隨意在此環(huán)境上進(jìn)行Schema的修改。我舉一些常見(jiàn)的例子：

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

2. 有一天發(fā)現(xiàn)生產(chǎn)環(huán)境的某個(gè)功能很慢，從監(jiān)控看，是某條SQL很慢。經(jīng)分析發(fā)現(xiàn)該表沒(méi)有建索引。原來(lái)是開(kāi)發(fā)人員發(fā)布生產(chǎn)環(huán)境時(shí)，忘記提供增加索引的SQL了。

以上例子，說(shuō)到底就是環(huán)境不一致的問(wèn)題。這些是軟件工程中非常常見(jiàn)的問(wèn)題。環(huán)境不一致的問(wèn)題除了在SQL層面發(fā)生，還會(huì)在構(gòu)建環(huán)境層面、運(yùn)維層面發(fā)生。

解決方案

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

這個(gè)版本控制不是說(shuō)放到Git倉(cāng)庫(kù)里就可以的，還必須明確的指定SQL的版本。這一點(diǎn)，我們可以通過(guò)Flyway實(shí)現(xiàn)。下圖是Flyway對(duì)于SQL文件的命名規(guī)范：

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

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

在工程化程度不高的團(tuán)隊(duì)，你經(jīng)常會(huì)聽(tīng)到這樣的話(huà)：

我在SIT測(cè)試是沒(méi)有問(wèn)題的??！為什么在生產(chǎn)環(huán)境就出問(wèn)題？我在本地構(gòu)建是可以的，為什么在Jenkins上就不行？

這樣的話(huà)，都有意無(wú)意地暗含著一層意思：我沒(méi)有問(wèn)題，那是你的問(wèn)題。不管你承認(rèn)不承認(rèn)。

這層意思會(huì)對(duì)團(tuán)隊(duì)所帶來(lái)的影響是：環(huán)境一致性問(wèn)題是運(yùn)維的問(wèn)題，不是開(kāi)發(fā)的問(wèn)題。開(kāi)發(fā)人只管自己寫(xiě)完代碼就什么可以不管了。說(shuō)難聽(tīng)點(diǎn)，就是只管自己隨地拉，讓別人來(lái)收拾。

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

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

開(kāi)發(fā)的問(wèn)題

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

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

但是，開(kāi)發(fā)說(shuō)：我本地啟動(dòng)一應(yīng)用來(lái)進(jìn)行調(diào)試，就是要連各種依賴(lài)的啊，比如MySQL、其它服務(wù)、服務(wù)發(fā)現(xiàn)中間件等。怎么辦？

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

為什么說(shuō)“一定會(huì)有人”。是因?yàn)椋@些年經(jīng)歷過(guò)5，6個(gè)團(tuán)隊(duì)，每到一個(gè)團(tuán)隊(duì)，團(tuán)隊(duì)里的人都會(huì)提。其實(shí)，提出這個(gè)解決方案的人是在偷懶，自己不搭建，讓別人搭建。

筆者反對(duì)搭建這么一個(gè)開(kāi)發(fā)環(huán)境，并不是因?yàn)榇罱ㄒ粋€(gè)開(kāi)發(fā)環(huán)境，會(huì)增加DevOps的工作。恰恰相反，能快速的搭建一個(gè)環(huán)境是DevOps的職責(zé)。

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

開(kāi)發(fā)的問(wèn)題，應(yīng)該由開(kāi)發(fā)自己解決

以上說(shuō)的開(kāi)發(fā)問(wèn)題，我覺(jué)得對(duì)于團(tuán)隊(duì)更高效的解決辦法是：

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

2. 提供方便本地開(kāi)發(fā)的腳本，比如一個(gè)docker-compose.yaml能啟動(dòng)所有的這個(gè)應(yīng)用的依賴(lài)；

3. 使每個(gè)應(yīng)用都應(yīng)該能不依賴(lài)其它應(yīng)用獨(dú)立運(yùn)行的。比如正在A(yíng)調(diào)用B這樣的關(guān)系，我們應(yīng)該能做到A啟動(dòng)時(shí)不應(yīng)該于B也必須啟動(dòng)。這要我們做到很好的解耦。

后記

環(huán)境的一致性的維持需要團(tuán)隊(duì)中所有的人共同實(shí)現(xiàn)。不應(yīng)該只是由環(huán)境的搭建者來(lái)維持。