|
本文作者用對比非常鮮明的兩個開發團隊的故事，講解了敏捷開發之道 —— 如果你的團隊缺乏統一標準的環境，那么即使勤勞努力，不僅會極其耗時而且成果甚微，使用容器化技術、CI/CD，不僅能讓開發環境、測試環境、預發環境、生產環境保持一致，同時也對測試和質量保證有至關重要的作用。 以下為譯文： 這是我「流行軟件開發實踐」系列文章中的第四部分，在本系列文章中，我計劃包含軟件工程師通過提升開發流程和實踐來改善軟件開發的一系列方法。我曾在 ThoughtWorks 擔任軟件顧問，現在我在德國一家大型的零售公司工作，這些方法都是我在職業生涯中學習并實踐驗證過的。 這么多年來，我參加過很多團隊活動，如足球、棒球、摔跤、籃球、足球、田徑……我基本上參加了所有與運動有關的團隊活動。有趣的是，我也加入過很多軟件開發團隊。 在這些團隊中，我注意到了一個共同點，優秀的人才可以為團隊成功中做出重要的貢獻（如贏得比賽，高效開發需求并上線），但是他們并非團隊成功唯一的原因。 在運動項目中，訓練很重要，但是并不是所有的訓練都重要。真正有用的那些訓練是那些看起來不像是訓練的訓練。所以，對運動項目來說，比賽才是最好的訓練，對于軟件開發來說，在和生產環境幾乎一致的地方測試才是有效的。 這個觀點也是本文的重點，在和生產環境一樣的環境中，進行開發和測試的效果非凡。下面，我將用兩個我以前所呆過的團隊中的故事，來闡述這一觀點。 勤勞有限責任技術公司 —— 團隊一 這個公司名稱是虛構的，但是團隊的工作情況和公司名字一致。 公司中有一個很大的前端項目，很多團隊都在上面貢獻這自己的努力，當然，我們團隊也寫著其中一部分功能。這些團隊各自提供著自己的服務，并且這些服務也存在著各種相互依賴的關系。 當第一天到公司的時候，我們不得不在自己的新電腦上設置基礎的開發環境。這些環境不僅僅包含我們部門自己的依賴服務，還必須要包含很多其它部門需要依賴的服務。這就導致我很難在本地將整個應用程序跑起來。 經過我的努力，我花費了兩天時間，終于在我的電腦上跑起了整個應用程序實例。但據我所知，很多其他的程序員并沒有將本地環境跑起來，而是與其他人進行結對編程，共用同一個環境。 很多同事都不能在本地測試他們的代碼，這就意味著，他們需要將他們的修改發布到測試環境中去，才能知道他們修改是否能夠生效，是否能夠正常地與其它服務進行交互。 這在實際工作中，具有相當大的挑戰，很多團隊并不能及時將所有的代碼更改推送到所有的環境中去。這將會有可能出現在測試環境中的測試結果與生產環境的結果不一致。 有一次，我們部門的一個程序員對一個功能進行修改，該功能需要與另外一個部門提供的服務進行數據交換，他很快就開發完成了，并在測試環境中進行測試，但在測試環境中，一直無法正常的跑通。但當我們把修改發布到線上環境，卻發現能良好地運行起來。最后排查到問題原因是因為在測試環境與線上環境依賴的服務版本不一致。線上環境使用的是一個新版本（5.0.2），而測試環境卻是使用的一個舊版本（5.0.1）。 另外一件“有趣”的事是，我們的測試環境是一臺虛擬機，當需要更新代碼的時候，我們需要登錄到那臺機器，在上面跑一個腳本，將最新的代碼拉到服務器上，并重啟應用。并且，公司的虛擬機數量不足以提供給每一位開發者使用。 這些問題，也導致代碼部署到生產環境的過程非常漫長。所以為了減少部署所花費的時間，所以我們會每兩周在生產環境中（像測試環境那樣）進行一次部署。當然，每當有新東西（新功能、Bug 修復等）要發布到生產環境中時，都需要重復一次這個耗時的部署過程。 聰明有限責任技術公司 —— 團隊二 顯然，這個公司名稱也是虛構的，但是其團隊的工作情況和公司名字一致。 就整個團隊而言，這個團隊和前文所述的團隊幾乎一致。我們也致力于多個微服務[1]的開發，我們也需要和其它做著類似事情的部門進行交互。我們通過 REST 接口接收請求，也發送請求到其他服務上。 當第一天到公司的時候，我再次開始設置我的基礎開發環境。在代碼庫中的 README.md 文件中，列出了配置開發環境的幾項說明：
從我拿到項目權限，一個半小時后，我在本地跑起來了第一個服務，并且能夠將本地的改動推送到這個服務上。 這個團隊和前文所述的那個團隊一樣，也有測試環境、預發環境、生產環境。一旦代碼提交到主干上，CI/CD[2]上的任務會自動將代碼構建成 Docker 鏡像，并開始跑測試用例，緊接著會給鏡像打上版本和標簽并將鏡像推送到鏡像庫中，還會將測試環境與預發環境中的鏡像替換成最新的版本。在必要的時候，通過手動觸發，將鏡像部署到生產環境。 整個過程，在最糟糕的一天，也最多花費 10 分鐘時間。 在這個公司中，所有的團隊都有類似的設置。 這些環境的區別在于，在測試環境中，使用的是測試數據，第三方的服務要么是被忽略掉，要么是被 mock 掉。在預發環境中，也是使用測試數據，但是其它的服務都是在正常運行狀態。 關鍵點 這兩個團隊中的差異，我在很多團隊都看到過，我能夠輕松地指出他們存在的問題。如果讓你選擇加入其中某一個團隊時，我相信大多數開發都會選擇同一個團隊。
第二個團隊將他們的服務進行了容器化，這給他們帶來了很多的好處。因為項目中所有的依賴都在容器中設置完成，所以在新的機器上部署非常的容易，不僅僅只有這一個優點，容器化也使它們在生產環境中的部署變得非常容易。 容器化讓整個應用程序變成了一塊，可以輕松、快速地進行更換（這也讓敏捷開發四個關鍵指標中的部署頻率提高了）。 容器化也能有助于實現多個環境的標準化。
在第一個團隊中，主要的挑戰就是源于他們沒有統一標準的環境。 每一個虛擬機都需要單獨去更新正確的程序包版本，如果忘記更新某一臺虛擬機時，這就有可能會引起問題，這些問題要么是功能問題，要么安全問題，這都非常的嚴重。 環境不一致也會影響測試的有效性，因為我們不知道在測試環境測試的結果是否與線上環境的結果保持一致。很多錯誤都是由于環境不一致引起的。 在第二個團隊中，使用容器化技術與自動化部署技術相結合，這樣能很容易保證生產環境與測試環境一致。當然，即使環境一致也有可能會出現問題。不過，你也不必擔心，這種錯誤的出現會被極大的降低（敏捷開發四個關鍵指標中的變更失敗率） 用一句話總結： 使用容器化技術、CI/CD 能夠更加容易地讓開發環境、測試環境、預發環境、生產環境保持一致，也對測試和質量保證有至關重要的作用。 朋友們，更聰明地工作，而不是更辛苦地工作。 [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 作者：Tylor Borgeson，全棧軟件開發者，對機器學習、AI、基礎架構、DevOps 及敏捷等擁有強烈興趣。 |
|
|
