以下為譯文：

這是我「流行軟件開發(fā)實踐」系列文章中的第四部分，在本系列文章中，我計劃包含軟件工程師通過提升開發(fā)流程和實踐來改善軟件開發(fā)的一系列方法。我曾在 ThoughtWorks 擔(dān)任軟件顧問，現(xiàn)在我在德國一家大型的零售公司工作，這些方法都是我在職業(yè)生涯中學(xué)習(xí)并實踐驗證過的。

這么多年來，我參加過很多團隊活動，如足球、棒球、摔跤、籃球、足球、田徑……我基本上參加了所有與運動有關(guān)的團隊活動。有趣的是，我也加入過很多軟件開發(fā)團隊。

在這些團隊中，我注意到了一個共同點，優(yōu)秀的人才可以為團隊成功中做出重要的貢獻（如贏得比賽，高效開發(fā)需求并上線），但是他們并非團隊成功唯一的原因。

在運動項目中，訓(xùn)練很重要，但是并不是所有的訓(xùn)練都重要。真正有用的那些訓(xùn)練是那些看起來不像是訓(xùn)練的訓(xùn)練。所以，對運動項目來說，比賽才是最好的訓(xùn)練，對于軟件開發(fā)來說，在和生產(chǎn)環(huán)境幾乎一致的地方測試才是有效的。

這個觀點也是本文的重點，在和生產(chǎn)環(huán)境一樣的環(huán)境中，進行開發(fā)和測試的效果非凡。下面，我將用兩個我以前所呆過的團隊中的故事，來闡述這一觀點。

勤勞有限責(zé)任技術(shù)公司 —— 團隊一

這個公司名稱是虛構(gòu)的，但是團隊的工作情況和公司名字一致。

公司中有一個很大的前端項目，很多團隊都在上面貢獻這自己的努力，當(dāng)然，我們團隊也寫著其中一部分功能。這些團隊各自提供著自己的服務(wù)，并且這些服務(wù)也存在著各種相互依賴的關(guān)系。

當(dāng)?shù)谝惶斓焦镜臅r候，我們不得不在自己的新電腦上設(shè)置基礎(chǔ)的開發(fā)環(huán)境。這些環(huán)境不僅僅包含我們部門自己的依賴服務(wù)，還必須要包含很多其它部門需要依賴的服務(wù)。這就導(dǎo)致我很難在本地將整個應(yīng)用程序跑起來。

經(jīng)過我的努力，我花費了兩天時間，終于在我的電腦上跑起了整個應(yīng)用程序?qū)嵗５珦?jù)我所知，很多其他的程序員并沒有將本地環(huán)境跑起來，而是與其他人進行結(jié)對編程，共用同一個環(huán)境。

很多同事都不能在本地測試他們的代碼，這就意味著，他們需要將他們的修改發(fā)布到測試環(huán)境中去，才能知道他們修改是否能夠生效，是否能夠正常地與其它服務(wù)進行交互。

這在實際工作中，具有相當(dāng)大的挑戰(zhàn)，很多團隊并不能及時將所有的代碼更改推送到所有的環(huán)境中去。這將會有可能出現(xiàn)在測試環(huán)境中的測試結(jié)果與生產(chǎn)環(huán)境的結(jié)果不一致。

有一次，我們部門的一個程序員對一個功能進行修改，該功能需要與另外一個部門提供的服務(wù)進行數(shù)據(jù)交換，他很快就開發(fā)完成了，并在測試環(huán)境中進行測試，但在測試環(huán)境中，一直無法正常的跑通。但當(dāng)我們把修改發(fā)布到線上環(huán)境，卻發(fā)現(xiàn)能良好地運行起來。最后排查到問題原因是因為在測試環(huán)境與線上環(huán)境依賴的服務(wù)版本不一致。線上環(huán)境使用的是一個新版本（5.0.2），而測試環(huán)境卻是使用的一個舊版本（5.0.1）。

另外一件“有趣”的事是，我們的測試環(huán)境是一臺虛擬機，當(dāng)需要更新代碼的時候，我們需要登錄到那臺機器，在上面跑一個腳本，將最新的代碼拉到服務(wù)器上，并重啟應(yīng)用。并且，公司的虛擬機數(shù)量不足以提供給每一位開發(fā)者使用。

這些問題，也導(dǎo)致代碼部署到生產(chǎn)環(huán)境的過程非常漫長。所以為了減少部署所花費的時間，所以我們會每兩周在生產(chǎn)環(huán)境中（像測試環(huán)境那樣）進行一次部署。當(dāng)然，每當(dāng)有新東西（新功能、Bug 修復(fù)等）要發(fā)布到生產(chǎn)環(huán)境中時，都需要重復(fù)一次這個耗時的部署過程。

聰明有限責(zé)任技術(shù)公司 —— 團隊二

顯然，這個公司名稱也是虛構(gòu)的，但是其團隊的工作情況和公司名字一致。

就整個團隊而言，這個團隊和前文所述的團隊幾乎一致。我們也致力于多個微服務(wù)[1]的開發(fā)，我們也需要和其它做著類似事情的部門進行交互。我們通過 REST 接口接收請求，也發(fā)送請求到其他服務(wù)上。

當(dāng)?shù)谝惶斓焦镜臅r候，我再次開始設(shè)置我的基礎(chǔ)開發(fā)環(huán)境。在代碼庫中的 README.md 文件中，列出了配置開發(fā)環(huán)境的幾項說明：

• 安裝 Docker；

• 如何從團隊鏡像庫拉取和推送 Docker 鏡像；

• 如何在本地運行容器；

• 如何將本地修改關(guān)聯(lián)到容器中。

從我拿到項目權(quán)限，一個半小時后，我在本地跑起來了第一個服務(wù)，并且能夠?qū)⒈镜氐母膭油扑偷竭@個服務(wù)上。

這個團隊和前文所述的那個團隊一樣，也有測試環(huán)境、預(yù)發(fā)環(huán)境、生產(chǎn)環(huán)境。一旦代碼提交到主干上，CI/CD[2]上的任務(wù)會自動將代碼構(gòu)建成 Docker 鏡像，并開始跑測試用例，緊接著會給鏡像打上版本和標簽并將鏡像推送到鏡像庫中，還會將測試環(huán)境與預(yù)發(fā)環(huán)境中的鏡像替換成最新的版本。在必要的時候，通過手動觸發(fā)，將鏡像部署到生產(chǎn)環(huán)境。

整個過程，在最糟糕的一天，也最多花費 10 分鐘時間。

在這個公司中，所有的團隊都有類似的設(shè)置。

這些環(huán)境的區(qū)別在于，在測試環(huán)境中，使用的是測試數(shù)據(jù)，第三方的服務(wù)要么是被忽略掉，要么是被 mock 掉。在預(yù)發(fā)環(huán)境中，也是使用測試數(shù)據(jù)，但是其它的服務(wù)都是在正常運行狀態(tài)。

關(guān)鍵點

這兩個團隊中的差異，我在很多團隊都看到過，我能夠輕松地指出他們存在的問題。如果讓你選擇加入其中某一個團隊時，我相信大多數(shù)開發(fā)都會選擇同一個團隊。

• 容器化

第二個團隊將他們的服務(wù)進行了容器化，這給他們帶來了很多的好處。因為項目中所有的依賴都在容器中設(shè)置完成，所以在新的機器上部署非常的容易，不僅僅只有這一個優(yōu)點，容器化也使它們在生產(chǎn)環(huán)境中的部署變得非常容易。

容器化讓整個應(yīng)用程序變成了一塊，可以輕松、快速地進行更換（這也讓敏捷開發(fā)四個關(guān)鍵指標中的部署頻率提高了）。

容器化也能有助于實現(xiàn)多個環(huán)境的標準化。

• 標準化/一致性

在第一個團隊中，主要的挑戰(zhàn)就是源于他們沒有統(tǒng)一標準的環(huán)境。

每一個虛擬機都需要單獨去更新正確的程序包版本，如果忘記更新某一臺虛擬機時，這就有可能會引起問題，這些問題要么是功能問題，要么安全問題，這都非常的嚴重。

環(huán)境不一致也會影響測試的有效性，因為我們不知道在測試環(huán)境測試的結(jié)果是否與線上環(huán)境的結(jié)果保持一致。很多錯誤都是由于環(huán)境不一致引起的。

在第二個團隊中，使用容器化技術(shù)與自動化部署技術(shù)相結(jié)合，這樣能很容易保證生產(chǎn)環(huán)境與測試環(huán)境一致。當(dāng)然，即使環(huán)境一致也有可能會出現(xiàn)問題。不過，你也不必擔(dān)心，這種錯誤的出現(xiàn)會被極大的降低（敏捷開發(fā)四個關(guān)鍵指標中的變更失敗率）

用一句話總結(jié)：

使用容器化技術(shù)、CI/CD 能夠更加容易地讓開發(fā)環(huán)境、測試環(huán)境、預(yù)發(fā)環(huán)境、生產(chǎn)環(huán)境保持一致，也對測試和質(zhì)量保證有至關(guān)重要的作用。

朋友們，更聰明地工作，而不是更辛苦地工作。

[1] https:///

[2] https://levelup./heres-why-continuous-integration-and-deployment-is-so-important-to-the-software-development-c0caeead5881

英文：A Tale of Two Software Teams

原文：https://levelup./a-tale-of-two-software-teams-5cb6cebd28bb