程式設計師為什麼千萬不要瞎努力？

本文作者用對比非常鮮明的兩個開發團隊的故事，講解了敏捷開發之道 —— 如果你的團隊缺乏統一標準的環境，那麼即使勤勞努力，不僅會極其耗時而且成果甚微，使用容器化技術、ci/cd，不僅能讓開發環境、測試環境、預發環境、生產環境保持一致，同時也對測試和質量保證有至關重要的作用。

作者 | tylor borgeson，已獲作者翻譯授權

譯者 | 羅昭成

原文 | a tale of two software teams

這是我「流行軟體開發實踐」系列文章中的第四部分，在本系列文章中，我計畫包含軟體工程師通過提公升開發流程和實踐來改善軟體開發的一系列方法。我曾在 thoughtworks 擔任軟體顧問，現在我在德國一家大型的零售公司工作，這些方法都是我在職業生涯中學習並實踐驗證過的。

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

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

在運動專案中，訓練很重要，但是並不是所有的訓練都重要。真正有用的那些訓練是那些看起來不像是訓練的訓練。所以，對運動專案來說，比賽才是最好的訓練，對於軟體開發來說，在和生產環境幾乎一致的地方測試才是有效的。

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

公司中有乙個很大的前端專案，很多團隊都在上面貢獻這自己的努力，當然，我們團隊也寫著其中一部分功能。這些團隊各自提供著自己的服務，並且這些服務也存在著各種相互依賴的關係。

當第一天到公司的時候，我們不得不在自己的新電腦上設定基礎的開發環境。這些環境不僅僅包含我們部門自己的依賴服務，還必須要包含很多其它部門需要依賴的服務。這就導致我很難在本地將整個應用程式跑起來。

經過我的努力，我花費了兩天時間，終於在我的電腦上跑起了整個應用程式例項。但據我所知，很多其他的程式設計師並沒有將本地環境跑起來，而是與其他人進行結對程式設計，共用同乙個環境。

很多同事都不能在本地測試他們的**，這就意味著，他們需要將他們的修改發布到測試環境中去，才能知道他們修改是否能夠生效，是否能夠正常地與其它服務進行互動。

這在實際工作中，具有相當大的挑戰，很多團隊並不能及時將所有的**更改推送到所有的環境中去。這將會有可能出現在測試環境中的測試結果與生產環境的結果不一致。

有一次，我們部門的乙個程式設計師對乙個功能進行修改，該功能需要與另外乙個部門提供的服務進行資料交換，他很快就開發完成了，並在測試環境中進行測試，但在測試環境中，一直無法正常的跑通。但當我們把修改發布到線上環境，卻發現能良好地執行起來。最後排查到問題原因是因為在測試環境與線上環境依賴的服務版本不一致。線上環境使用的是乙個新版本（5.0.2），而測試環境卻是使用的乙個舊版本（5.0.1）。

另外一件「有趣」的事是，我們的測試環境是一台虛擬機器，當需要更新**的時候，我們需要登入到那台機器，在上面跑乙個指令碼，將最新的**拉到伺服器上，並重啟應用。並且，公司的虛擬機器數量不足以提供給每一位開發者使用。

這些問題，也導致**部署到生產環境的過程非常漫長。所以為了減少部署所花費的時間，所以我們會每兩周在生產環境中（像測試環境那樣）進行一次部署。當然，每當有新東西（新功能、bug 修復等）要發布到生產環境中時，都需要重複一次這個耗時的部署過程。

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

就整個團隊而言，這個團隊和前文所述的團隊幾乎一致。我們也致力於多個微服務[1]的開發，我們也需要和其它做著類似事情的部門進行互動。我們通過 rest 介面接收請求，也傳送請求到其他服務上。

當第一天到公司的時候，我再次開始設定我的基礎開發環境。在**庫中的 readme.md 檔案中，列出了配置開發環境的幾項說明：

從我拿到專案許可權，乙個半小時後，我在本地跑起來了第乙個服務，並且能夠將本地的改動推送到這個服務上。

這個團隊和前文所述的那個團隊一樣，也有測試環境、預發環境、生產環境。一旦**提交到主幹上，ci/cd[2]上的任務會自動將**構建成 docker 映象，並開始跑測試用例，緊接著會給映象打上版本和標籤並將映象推送到映象庫中，還會將測試環境與預發環境中的映象替換成最新的版本。在必要的時候，通過手動觸發，將映象部署到生產環境。

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

在這個公司中，所有的團隊都有類似的設定。

這些環境的區別在於，在測試環境中，使用的是測試資料，第三方的服務要麼是被忽略掉，要麼是被 mock 掉。在預發環境中，也是使用測試資料，但是其它的服務都是在正常執行狀態。

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

第二個團隊將他們的服務進行了容器化，這給他們帶來了很多的好處。因為專案中所有的依賴都在容器中設定完成，所以在新的機器上部署非常的容易，不僅僅只有這乙個優點，容器化也使它們在生產環境中的部署變得非常容易。

容器化讓整個應用程式變成了一塊，可以輕鬆、快速地進行更換（這也讓敏捷開發四個關鍵指標中的部署頻率提高了）。

容器化也能有助於實現多個環境的標準化。

在第乙個團隊中，主要的挑戰就是源於他們沒有統一標準的環境。

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

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

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

用一句話總結：

使用容器化技術、ci/cd 能夠更加容易地讓開發環境、測試環境、預發環境、生產環境保持一致，也對測試和質量保證有至關重要的作用。