DevOps最佳實踐之應用開發和部署

本系列內容是我們在不同專案的維護過程中總結的關於DevOps/SRE方面的最佳實踐，我們將致力於在專案上盡最大的努力來推行這些最佳實踐。我們希望這些最佳實踐能對專案的穩定運營提供幫助，也希望剛接觸DevOps/SRE的新人能透過學習這些最佳實踐來提升自己在這方面的水平。

因為DevOps/SRE涉及到的方方面面比較多，一次性完成的工作量太大，所以我們決定分階段來完成，這一次釋出的是“應用開發和部署”這個部分的內容，後續我們將逐步釋出“雲平臺與網路”，“作業系統和服務”，“使用者與許可權”，“監控與視覺化”，“資料與備份”，“敏感資料”，“故障與應急響應”這幾部分的內容。

所謂“最佳實踐”應該是最適合自己的實踐，而不一定是最先進的，而且每一種實踐本身也存在一定的侷限性，所以我們在描述了對應實踐的優點的同時，也把可能存在的缺點寫了出來，就是希望大家在看到它的好處的時候，也能知道可能存在的風險在那裡，理性地去評估到底是不是要採用相應的實踐，所以這裡總結的最佳實踐請適度取用，不要為了“最佳”而實踐。

我們深知自己在諸多方面存在一定的侷限性，相關的內容可能存在一些不足，而且最佳實踐本身會隨著技術更新等因素不停地變化，我們將會把藍皮書內容同步釋出在Github上（） ，希望引發更廣範圍的傳播和討論。也請使用PR或Issue的方式來提出你的不同的觀點和更好的建議，謝謝。

在傳統的運維環境中，由於條件的限制無法快速的提供新的基礎設施和環境，所以通常在業務的依賴環境如作業系統核心，服務，類庫，執行時版本等需要變化時，我們會根據需要在現有的環境上做持續性變更。而且我們還可能會在機器上執行一些臨時任務，做除錯和排錯等，很多的時候，這些操作對應的變化並不具有可追溯性，甚至不可以恢復到之前的狀態。這樣，剛開始統一配置的無差別的一批機器隨著時間的推移慢慢的就會變得各自具有一些獨有的特性。另外還有一些型別的服務，比如資料庫，儲存等，其業務本質就導致了叢集中的每一臺機器具有獨特的屬性。當我們在維護這些服務的時候，需要根據每臺機器的特性來做不同的管理和配置，而且一旦機器出現故障的時候，也很難去建立出一樣的機器來替代。因為這種情形和養寵物類似，比如我們會給寵物起一個名字，它也需要悉心照料，生病的時候要帶去看病，所以我們稱這種服務模式為寵物模式。

而在具有云原生能力的平臺上，我們可以按需定製基礎映象，也能快速的從這個基礎映象中建立出執行環境，我們的變更就可以基於基礎映象來做更新和版本迭代。這樣當某一臺機器發生了故障，我們可以快速的複製出一臺一模一樣的機器來替代。如果需要做一些臨行性的操作和變化，在任務結束之後，也可以銷燬這臺已經發生了變化的機器，使用一臺新的機器來替代，使整個叢集恢復到一個最初的收斂狀態。這個場景和我們現實生活中的規模化牲口養殖類似，對應的我們稱這種服務模式為牲口模式。

大家所熟知的無狀態應用，就是牲口模式的最常用的一種實現方式。在業務的設計和實施過程中，我們建議把邏輯和資料分離，在邏輯執行環境不要兼顧資料儲存工作，比如請求的session相關的資料，不要儲存在本地，而是把它放在一個共享資料服務中，從而達到無狀態的目的，這樣就可以對邏輯執行環境進行牲口化的管理方式。

優點：

1. 可隨時被銷燬或替換，結合自動化基礎設施和監控，自動完成對故障機器或節點的替換。

2. 配合自動化基礎設施和監控，可實現自動水平伸縮，從容應對業務峰谷，節約成本。

3. 在不影響服務穩定性的前提下可部署所需要版本的應用、進行系統升級或者打補丁。

4. 監控和管理的重心不再是具體的單一資源的使用率，而是整體的承載能力和更深層次的效能關注點。

缺點：

1. 需要基礎設施平臺具有相應的能力支撐，否則很難實現。

2. 不是所有的業務型別都能做牲口模式設計，比如資料庫。

實施要點：

1. 除計算和業務處理過程中的臨時產生的資料，資料的來源和最終的持久化應由外部服務來提供，如獨立的記憶體型資料庫或者關係型資料庫。

2. 可以使用客戶端Cookie、cache取代外部資料服務。如果有敏感資料，伺服器端可以加密後交由客戶端儲存，在之後的請求時發回伺服器解密使用。

3. 透過鎖或者冪等性設計，使得應用能正確、快速、自動地解決對同一份資料的競爭而導致的流程異常、資料不一致等問題。例如，多個定時任務同時處理一批資料。

向前相容指低版本的系統、程式或技術能優雅處理（例如：忽略其不理解的部分）高版本的系統、程式或技術。向前相容技術的目標是讓舊系統能夠識別為新系統生成的資料，簡單的說就是舊版本的系統可以接受新版本的資料，是舊版本對新版本的相容。

我們建議在做業務升級時候，設計你的業務具有向前相容的能力，以應對升級失敗時某一功能模組或者依賴無法隨之回滾的風險。比如說在有資料庫欄位變化的升級中，在正式對資料庫做變動之前，基於舊的業務流程做程式碼層面更新，使其可以相容資料庫將要發生的改動並加以部署。在資料庫升級完成之後，如果新的業務流程上線後不幸出現重大的問題等情況需要回滾時，回滾之後的程式碼仍然可以相容資料庫的變化，而不用對資料庫也進行回滾，畢竟資料庫的回滾成本非常高。

優點：

1. 可以在新版本出現不容易修復和存在重大的風險的時候快速地回滾到舊的版本，業務中斷的可能性會大大降低。

2. 即使整個系統中存在不可回滾的部分，但我們不用花費很多的精力去考慮和解決完全不可回滾的問題。

缺點：

1. 設計成本：要做到相容未來的變化。這聽起來就很難。一開始很難獲知所有用例、極端案例和業務理解。回顧過去並說這是一個錯誤的決定很容易，今天做出明天不會後悔的決定要困難得多。

2. 為了同時相容兩種資料格式，需要在程式碼中增加額外的處理邏輯，增加複雜度和投入的成本。

實施要點：

1. select語句只獲取需要的欄位，避免使用select * from語句，有效防止新增欄位對應用邏輯的影響，還能減少對效能的影響。

2. 對資料庫表結構變更透過新增欄位實現。

3. 儘量新增介面，避免對現有介面做修改，如需要修改現有介面，可嘗試在介面上增加版本標識。

當生成容器映象時，應當使用唯一性標識來給容器映象打標籤，唯一標識可以更好的標記當次生成的映象，避免出現多個同名標籤但不同的版本映象被使用的情況。例如多次部署都使用了latest標籤的映象，可能因為拉取和快取策略導致不同節點使用了不同版本的映象，從而導致功能上的不一致，在這種情況下，並不能很方便地判斷出某個節點部署的是哪一個版本。

唯一標識最好有一定的含義，不僅可以用來區分產物，還可以獲取到本次構建的關鍵資訊。比如git提交雜湊等關聯性比較強的標識。雖然時間戳也是一個唯一性比較強的標識，但是關聯性相對較差，如果長度不足，也有一定的機率產生碰撞。可以考慮使用組合型標籤，比如使用時間戳，build號，版本號等根據自己的需求來組合生成唯一標識，這樣的標籤本身就包含了很豐富的資訊。

不建議單純使用pipeline的build序號來作為映象的標籤，如果需要更換CI工具或者重建pipeline時，這個序號將會被重置而可能產生重複，除非在構建指令碼中加入偏移量。而且不同的CI工具獲取這個序號的方法也有所不同，對於遷移並不友好。雖然它的可追溯性看起來較好，但是單純的Build序號和程式碼之間並沒有直接的關聯。

如果不是需要對外公開發布的映象，並不建議對同一映象打上多個不同標籤。因為絕大部分的情況下，我們只會選用其中一個標籤在所有的地方使用，多個標籤的實際意義並不會很大。

如果製品庫支援immutable特性，強烈建議開啟這個功能，防止因為意外情況導致對已上傳的映象的覆蓋。

優點：

1. 可以準確對應的到原始碼具體版本，在溯源時可以對應到特定的提交而不是可能存在的多個提交。

2. 不需要使用SHA256等額外的資訊來區分同一標籤的不同版本。

缺點：

1. 一些型別的唯一性標識可讀性不是很高，比如git提交雜湊。

2. 一些型別的標識受時間影響，不能使用同一命令獲得一致結果，需要使用其他的方式來傳遞給後續階段，比如時間戳。

3. 製品庫immutable功能開啟之後，重跑已完成構建映象的pipeline會發生上傳映象失敗的錯誤，有可能會導致後續任務不能繼續。

實施示例：

在所有環境中使用同一個構建產物

應該在不同環境中使用相同的構建產物來部署，避免對不同的環境生成不同的構建產物，以確保環境的一致性，同時也保證部署在不同環境中的業務程式碼是測試和驗證透過的。比如某次的構建產物，在測試環境部署後經由測試人員和相關的自動化測試工具完成相關的測試驗證，如果沒有問題才會繼續部署到後續環境中，應繼續使用該產物部署後面的環境，不建議重新構建新的產物來做後續環境的部署，也不建議覆蓋之前的構建產物標識。因為在現有流行的語言和框架中，普遍存在大量的第三方依賴，即便是同一份原始碼，由於其依賴以及構建環境的不同，會有一定機率出現由於外部依賴的更新導致構建產物存在差異，從而產生非預期的情況出現。

優點：

1. 確保所有的環境部署的構建產物是一樣的，儘可能的保證環境的一致性。

2. 確保部署到生產環境的產物是測試驗證之後並無變化的，避免出現非預期的差異。

缺點：

1. 對於如前端這類純靜態資源的應用，由於不同的環境需要連線不同的後端服務地址，因此無法直接使用唯一的構建產物。可以考慮在業務啟動階段，用一些額外的啟動指令碼或命令配合傳入環境變數或引數來修改配置檔案，從而達到所有環境使用同一個構建產物的目的。下面例子展示了在使用nginx的容器映象裡，透過在CMD指令裡面先執行一段指令碼來對配置進行修改，來達到在容器執行時根據傳入的環境變數WEB_ENV的值來訪問對應環境的後端服務的目的。

   

1. 對於移動端app，也存在與前端應用類似的問題，需要開發人員做額外設計和開發，在app啟動時判斷需要進入什麼樣的執行模式。

實施要點：

1. 在設計CICD流水線時，將構建產物同步到製品庫時，給該產物打上唯一標識。

2. 如製品庫支援，開啟製品庫的immutable特性。

3. 將該唯一標識傳遞到在後面所有的部署流水線任務中，所有的部署任務都使用該唯一標識所指向的構建產物。

4. 如果需要在多個製品庫儲存同一個構建產物，建議在上傳成功之後對構建產物做完整性檢查。

一般情況下，指令碼都會或多或少的使用到一些外部工具。而我們的指令碼很有可能會執行在不同的環境中，不同環境中提供的工具也會有版本和用法的差異。如果需要在環境中維護某一工具的多個版本的，工具本身的版本管理，以及多個工具之間的依賴衝突和升級更新也會產生較高的管理和維護成本。

我們建議儘可能的減少所使用的工具對環境的依賴，尤其是系統不會預設安裝的工具。另外在編寫指令碼的時候，也儘量避免使用只有某些版本特有的語法特性。這些情況都會導致指令碼有可能出現一些不可預期的結果。我們建議使用容器化工具或者容器化環境管理工具如Batect來替代對應的需求。

優點：

1. CI/CD agent中只需要安裝容器執行時即可，可以減小agent的體積。 

2. 容器化的工具因為對環境的依賴非常低，所以不論是工具升級還是降級都非常簡單，同時也解耦了對agent特性的依賴，提高agent利用率。 

3. 最大化的保證環境一致性，使用容器化的工具消除了環境差異可能導致的非預期異常。 

4. 新人友好，新加入的團隊成員可以快速的配置好可執行的環境，無需過多的考慮具體工具的安裝，配置等。 

5. 解耦對CI/CD工具的依賴，雖然在實際專案中很少會有更換CI/CD工具的情況，但是如果需要遷移，我們也只需在新的工具環境中構建出容器執行環境即可，大大減少了切換工具工作量，提高遷移的速度。 

缺點：

1. 因為沒有預裝構建所需要的各種軟體，如果本地沒有映象快取，在執行容器化的工具時都需要去容器倉庫中獲取對應的工具映象，會有額外的頻寬壓力。 

2. 因為需要獲取工具映象，容器啟動也比二進位制的程式要慢，所以整個任務執行過程需要的時間會更長。 

3. 理論上來講，容器化技術效能損耗很小，工具的效能和二進位制程式的差別不會很大，但是在實際的使用中，我們發現因為容器引擎配置不當等原因會導致一些工具效能變差甚至無響應的情況出現。 

實施示例：

在使用 terraform 時，不同版本之間的 terraform 並不相容，那麼如何保證所有人與 CI 都使用相同的 terraform 版本就是一個非常麻煩的事情。那麼如果我們無論在 CI 還是本地都基於 docker 去執行 terraform 就可以解決這個問題。

auto/ACTION是我們在專案實踐中總結並希望可以廣泛推廣的一個經驗總結，在和客戶合作過程中，尤其是有很多團隊的大型專案上，我們從這個模式中受益匪淺。auto/ACTION模式的核心是使用統一語義能表明指令碼目的的ACTION來命名管理指令碼，如應用的測試(test)，驗證(validate)，打包(build)，釋出(deploy)等相關任務，統一把這些管理指令碼歸放在auto目錄下來維護。

因為類unix系統在執行的時候並不真正使用檔案字尾來識別檔案的型別，我們建議指令碼名字不要加字尾。這個建議是基於管理指令碼有可能會在多個地方被使用，而不同的開發和維護人員對於語言的偏好不同，如果在需要使用另外一種語言重寫指令碼的時候，使用這個指令碼的地方就不需要做更新，消除了因為檔名變化可能導致的自動化任務的錯誤和中斷。雖然沒有字尾可能會帶來一些不便，比如編輯器的語言型別識別錯誤等，但是相對於它帶來的優點，還是非常值得的。

優點：

1. 管理程式碼和業務程式碼放在同一程式碼庫，使用版本控制，便於進行更新，回退。

2. 每個指令碼只做一件事，職責單一，同時便於理解和管理。

3. 可以方便的知道所有可用的指令碼。如：

   

1. 如果跨團隊合作，或者團隊成員有輪換的時候，可以更快速的掌握業務管理的上下文。

缺點：

1. 每個專案都有一套自己的auto指令碼，如果有基礎性變化，改動成本較高，可以考慮使用git submodule等模式來管理。

2. 沒有字尾的檔名會帶來一些管理上的不便。

實施要點：

1. 指令碼滿足既可在本地執行，又能在CI流水線上執行，便於驗證。 

2. 指令碼中的變數內容儘可能從環境變數中讀取，避免向指令碼中傳入引數，方便執行。 

3. 專屬於CI/CD平臺的指令碼不要放在auto根目錄下，建議建立一個對應的子目錄，例如 .buildkite, .github, .travis來做管理。 

4. 可根據團隊的需求適當的擴充套件指令碼的名字使之更容易理解，建議使用-而非_ 來分隔單詞， 如auto/upload-image-to-ecr。 

我們的應用中一般都會有一些指令碼來做一些輔助性的工作。這些指令碼通常會和業務程式碼放在同一個程式碼倉庫，使用版本控制來進行管理。這些指令碼大致分為兩種：管理指令碼和業務指令碼。

管理指令碼是用來做應用打包，部署等管理相關工作工作，這種型別的指令碼是無需打包進業務執行所需的產出物中的；業務指令碼是輔助業務執行，比如說初始化環境和配置，結束時的清理工作等，這些指令碼需要打包到業務執行的產出物中。

我們建議除了一些有特殊要求的指令碼外，不要把指令碼放在根目錄。並且把這兩種不同型別的指令碼存放在不同的目錄中。

優點：

1. 在封裝映象時，業務指令碼和業務程式碼同等重要，需要封裝在映象中。將管理指令碼和業務指令碼分離可以減少映象中的檔案數量。

2. 在軟體開發過程中，針對業務執行和自動化管理關注資訊不一樣，將管理指令碼和業務指令碼分離，讓團隊成員更加清楚指令碼的型別和目的。

缺點：

1. 將管理指令碼和業務指令碼分離，會增加倉庫的層次結構。

實施要點：

1. 推薦將管理指令碼放置在auto目錄，將業務指令碼放置在scripts目錄。

2. 指令碼中的變數採用從環境變數中讀取，避免向指令碼中傳入引數，方便執行。

3. 推薦指令碼名稱即表明指令碼的作用，不建議使用auto/script這樣不表意的指令碼命名。

4. 不在檔名中使用檔案型別字尾。

基礎映象是業務映象的地基，其包含了我們業務和應用所必需的基礎庫、二進位制檔案和配置檔案等。一個良好維護的基礎映象通常會根據需要做更新，這些更新通常包含安全補丁，新功能或對作業系統或框架的改進等，我們建議及時的更新容器的基礎映象來保障業務的安全性。除非有特定原因需要繼續使用舊版本映象，否則應及時跟進使用經過充分評估和測試的最新版本映象。

在Dockerfile和compose等檔案中，可以透過指定映象中的標識和sha256值組合來指定基礎映象的版本。當映象有了更新之後，及時沿用瞭如latest或大版本號這類通用性比較高的標籤時，其sha256的值也會發生變化，透過更新這個組合可以更新使用最新版本的基礎映象。

優點：

1. 最新的映象通常帶有可以增強應用程式安全性的補丁修復，降低安全風險。

2. 最新的映象通常包括可以提高應用程式效能的新功能或改進功能。

缺點：

1. 新功能可能存在不可預期的bug。

2. 新的功能有非常小的機率存在未知的安全漏洞，如果有特殊的安全需求，請在安全部門的指導下升級。

實施示例：

可以使用dfresh或者類似的工具來檢查和更新基礎映象。

• 檢查基礎映象是否有更新

  

• 更新基礎映象 

  

• 回退方法 在需要回退基礎映象版本時，可從程式碼庫的提交找到上一個可用版本的相應資訊。

隨著 Bug 修復、新功能的開發或者其他更新，我們應用的依賴包可能會過時。此時應用的依賴項越多，就越難跟上這些更新。過時的依賴包可能對安全構成威脅，並對效能產生負面影響。最新的軟體包可防止漏洞，這意味著定期的依賴性檢查和更新很重要。我們建議定期的對應用的依賴包做更新和安全檢查，並升級到一個合適的版本。並且我們建議在應用的 pipeline 中加入這些檢查任務，並在常規的開發過程中及時發現和升級。如果應用已經處於維護階段，我們也建議定期執行這些檢查並在需要的時候加以升級。

優點:

1. 定期升級依賴可以讓應用的安全性和程式碼的可用性都有保障。

2. 定期升級依賴會讓解決依賴版本衝突和程式碼相容性變得容易。

3. 更新依賴項可以獲得新的依賴項版本提供的所有效能改進。這些改進可以有多種形式，例如修復以前的效能問題、改進了實現和演算法等。

4. 升級依賴項不僅可以改進現有功能，還可以使用到以前不存在的新功能。這些新功能最終可能讓我們更好的實現自己應用的新功能。

缺點:

1. 如果不及時更新依賴，將會使得產品難以維護，並可能導致開發人員的時間被常規的、無意義的工作佔用。

2. 如果長期不更新依賴，會使應用面臨無人問津的風險，之後在某一天需要進行改動的時候，面臨大量的依賴包過期無法獲取和版本升級造成的介面變化。這時就需要投入非常高的成本來讓程式碼重新變得可用，甚至完全無法更新而變成遺留系統。

3. 當進行大的版本升級時，需要對應用程式進行更多的更改才能與較新的庫相容。這使得付出代價比及時更新依賴大得多。

4. 如果忽略升級依賴項，那麼會面臨無法在自己喜歡的平臺上執行軟體的可能。例如，如果停止升級軟體中的資料庫驅動程式，那麼將無法使用舊版本的資料庫系統。這不僅會使應用變得過時且易受攻擊，而且甚至可能無法從該資料庫系統提供商處獲得任何支援。

5. 如果應用依賴於過時的依賴項而導致升級困難變得很難維護，會使得專案很難找到對這些舊技術有經驗的人，甚至失去現有的維護者。

實施示例:

1. 手動檢查

JS 篇

• npm-outdated & npm-update 

• npm outdated：可以使用 npm outdated 獲取當前需要升級的包的資訊。

• npm update: 會把所有的包升級到我們定義的需要的版本號。如果需要升級到最新的則需要使用@latest eg: npm update cypress@latest。

• npm-check-updates: 是一種更高階的檢查工具 

• 首先需要全域性安裝 npm-check-updates: npm install -g npm-check-updates ；

• ncu: 檢查需要升級的包資訊，這裡類似 npm outdated；

• ncu --upgrade/ncu -u: 將所有的包升級到最新版本，即便是包含重大更改，也會進行更新。注意：更新完成後不會自動執行 npm install，所以還需要再手動執行來更新 package-lock.json。

• ncu --interactive/ncu -i : interactive mode 安裝某個包。

• 小結：npm-outdated 和 npm-check-updates都可以用來做 JS專案的包檢查、升級。 

Java 篇

• 在 build.gradle中配置 owasp.dependency-check

• 執行./gradlew dependencyCheckAnalyze

• 檢視報告：專案根目錄>build>reports>dependency-check-report.html

2. CI Pipeline 整合

• npm-check-updates 與 Buildkite Pipeline 的整合由於 buildkite 沒有官方外掛支援 dependency-check。所以對於buildkite 推薦兩種方式：

  
  

• 自己開發對應功能的外掛，然後整合到 pipeline 的 step 中；

• 透過 docker-compose 的方式去執行對應的檢查，將其在 pipeline 的 step 中去執行（如果需要可以新增 block 來強制檢查 npm-check-updates 的結果）。

  

  

  

  

• jenkins pipeline 的整合：需要安裝 dependency-check Plugin。步驟如下： 

• 在 Jenkins Global Tool Configuration 安裝 dependency-check；

• 在 Jenkins builder 配置已經安裝好的 dependency-check；

• 在 Jenkins Publish 裡配置讀取 dependency-check 的 report ，透過對相關指標進行讀取，設定閾值，配置構建失敗或者警告等設定。

3. 工具整合檢查

如果專案 code 託管在 Github，我們可以使用 Dependabot 和 Renovate 工具和 Github 整合來做依賴檢查。這兩個工具都會做定期掃描，建立依賴版本升級的 PR。

配置 Dependabot 進行版本更新

• 在 GitHub 的程式碼倉庫的主頁，找到程式碼倉庫名稱下的 setting；

• 在邊欄的安全性部分中，單擊程式碼安全性和分析；

• 在程式碼安全和分析下，在Dependabot version updates右側，單擊啟用以開啟儲存庫 .github 目錄中的基本 dependabot.yml 配置檔案；

• 新增version；

• 新增 updates 部分，並輸入希望 Dependabot 監視的每個包管理器的條目；

• 對於每個包管理器，可使用：

• package-ecosystem 指定包管理器。

• directory 指定清單或其他定義檔案的位置。

• schedule.interval 指定檢查新版本的頻率。

• 在程式碼倉庫的根目錄建立.github目錄；

• 建立 dependabot.yml檔案並且儲存到.github目錄下。

示例 dependabot.yml

配置 Renovate

• 在 Github 的 App 裡面安裝 Renovate app ；

• 安裝並配置完成後可以在PR中看到一個自動生成的PR Configure Renovate，這個PR中包含一個 renovate.json 檔案，這個檔案中包含了 renovate 的一些預設設定；

• 可以根據文件 () 新增或者修改適合自身專案的具體配置項；

• merge 此 PR；

• Renovate 會根據你配置的 schedule 時間去自動的掃描並生成包升級 PR 提醒

在應用處於維護階段，如果業務不再會增加新的功能，抑或因為某些原因無法做定期的應用依賴升級，我們也建議你定期的重新部署這個應用，以應對平臺等更底層的變化帶來的部署失敗的風險。定期部署可以確保你的應用在新的平臺環境中也可以正常的部署，如果在週期性的部署過程中發現應用無法在新的環境部署，你也會有一個緩衝期來制訂應對策略，而不是在平臺完成升級之後的某一天，應用發生了問題才發現已經無法部署。

優點：

1. 定期部署應用是對部署工具和流程的有效驗證，CI/CD Agent的一些升級有可能會導致我們在部署流程中使用工具發生相容性問題，定期部署可以及早的發現這些問題。 

2. 定期部署應用也能夠有效縮短我們的依賴獲取未驗證的視窗期。雖然我們的應用依賴可以鎖定版本，也可以將依賴儲存到私有倉庫，但長時間沒有執行相關部署流程，我們無法保證應用的依賴能夠在需要的時候可正常獲取且可用。 

3. 現在的應用的基礎設施很多都基於各類雲平臺，服務提供商會定期的對自己的基礎設施做升級和換代，定期部署應用可以讓我們及早的獲知基礎設施變化帶來的相容性風險。