通往成功DevOps的六大障礙
一、背景
在現今的社會中，每個公司都是軟件公司，無論是通過臺式機、雲服務還是移動設備，軟件都已成爲世界各地、各個公司日常工作的工具。例如，汽車是帶輪子的計算機，空調是數據終端，而銀行在手機中提供服務，等等。
在這個新的世界中，軟件更新可以滿足客戶的需求。每一個交付都是您更新，或破壞，與客戶間信任的機會。如何才能保證您的每個更新都以最快的速度提供一流的服務？
這就是爲什麼DevOps對您的公司很重要。當您加快高質量軟件的交付速度時，客戶會大呼過癮，並且您可以對市場需求的變化迅速做出反應。DevOps通過減少在測試、評估和發佈等各階段之間，以及與相關干係人之間的摩擦，來加快高質量軟件的交付速度。識別並解決這個過程中的痛點可以推進DevOps的成功建設。
良好的製品倉庫可以促進軟件在DevOps流程中的運轉。它存儲了過程中所有的二進制製品（artifacts，也稱爲工件），同時也保留了有關它們的信息，從而減少了不確定性，並使自動化工具能夠自由、快速地運行。
在加速軟件交付的過程中通常會遇到下述的六大障礙，而良好的製品倉庫可以幫助解決它們，以實現從代碼到客戶的快速、持續的軟件更新與發佈。
二、障礙一，您瞭解您所有的構建嗎？
您的開發人員團隊每天都可以生成許多構建，而您能全部跟蹤和掌握所有的構建嗎？
如果沒有全面的解決方案，那您可能會知道哪個版本是最新的，但卻無法確認哪個版本纔是最好的。您也無法可靠地追溯構建的歷史，並掌握組成該交付版本的各個部分都是來自何處。
當構建失敗時，您能夠識別並回退有問題的部分嗎？您如何才能查明哪些構建存在問題，以及問題出現在構建過程中哪個位置，以便您或開發人員可以快速提供修復。
解決方案：通用記錄系統
爲您所有的構建建造一個製品中心，作爲所有在DevOps流水線中運轉的製品的唯一真實來源。在中心的倉庫中管理和版本化所有構建的產出，意味着您可以輕鬆找到功能最佳、最新的構建。
製品倉庫能夠跟蹤製品使用的位置，及其先前的所有版本，從而提供了豐富的數據，來幫助您追溯所有構建的來源及其祖先。您可以快速查看一個版本與另一個版本之間的差異，瞭解每個版本的製作方式，並找到可幫助您修復錯誤版本的參考。
三、障礙二，您的過程中有人工操作嗎？
在DevOps過程中，每個需要人工介入的地方都會帶來風險。例如，人工的檢驗會增加延遲，生產環境的重複構建會帶來不確定性，必須手動更改、維護和執行的用於工具管理或構建部署的腳本會浪費時間，而且容易出錯。這些成本昂貴的過程，任何一個都會減慢正確的軟件版本發佈到最終用戶的速度。
解決方案：自動化和流程管理
如上一部分所講，保管您所有構建和製品的中央製品倉庫爲構建管理提供了便利。但如果同時它也可以收集有關製品的信息，這將賦予您更多的能力。您對製品的瞭解越多，就越能實現更好的自動化，並使您的構建工具能夠做出明智的決策，從而統一併加速整個部署過程中的軟件交付。
您的製品倉庫應該能夠爲您的構建工具提供豐富的、靈活的查詢和命令接口，以便它們可以不在您的干預下自動完成工作。如果它使用標準的、平臺無關的訪問機制，如REST API，則您可以任意選擇最適合您的CI服務器。
一旦您能夠實現DevOps流程的自動化，就可以更好地確保發佈到生產中的每個版本都遵循相同的流程，並且符合通用標準。
四、障礙三，您規範管理了所有的構建依賴嗎？
現在的軟件應用開發的特點，一是多語言並存，二是架構在公共框架、公共庫的基礎之上。從而開發人員在構建過程中爲這多鍾開發語言和技術都拉取了大量的外部依賴，而每種語言和技術對於依賴的管理都有其自己的要求和接口。您將如何管理它們？
這些外部資源可以隨時更改，並且對其質量的控制和管理程度參差不齊，有的根本就沒有保證。您如何確定每個版本中的用到了哪些依賴？如何可靠地複用其中的某個依賴？如何檢測悄然發生的有害更新？
而且，您的構建過程不可能跑得比訪問這些遠程資源的鏈接快，繁重的網絡負載會減慢構建速度，而訪問的中斷會導致您原來可靠的構建失敗。
解決方案：依賴管理
使用本地製品倉庫來代理存儲外部依賴的遠程資源，進而將所有外部依賴納入統一管理。藉助製品倉庫對這些外部依賴的本地緩存，可以保證始終以所需的版本、最快的速度來完成構建。
更好的是，一旦您的製品倉庫掌握了這些外部依賴，它就可以像其他製品一樣，爲這些外部依賴保存和維護相同的信息。通過跟蹤依賴的歷史記錄和使用過程，就能始終確認每個構建中都採用了哪個版本的依賴項。
五、障礙四，您是如何在DevOps流程中傳遞交付版本的？
許多DevOps流程中，在測試、驗證和發佈的每個階段，都需要基於全部或部分源代碼進行重新構建。這就導致每個新版本都需要花費更多的時間，並且可能需要每個干係人進行手動評估和觸發。更糟的是，隨着開發人員持續地更改共享代碼，每次重新構建都會帶來不確定性，不得不在每個階段重複相同的質量檢查。
一旦某個構建通過了當前檢查，您如何將其實際推進到下一階段？手動將該構建推送到下一階段的過程很容易出錯。而且，您還需要一種在整個DevOps過程中向整個團隊傳達該構建狀態的方法。
解決方案：元數據和升級管理
如障礙二的解決方案中所述，本地製品倉庫不僅管理了所有構建及其製品，還管理了製品相關的信息，也可稱爲製品的元數據。這些元數據可以幫助您對該製品的質量進行檢驗，來源進行跟蹤。
在DevOps流程中，各個階段之間交付版本的推進，推薦的最佳實踐是避免重複構建，而是採用製品升級的方式。也就是說，在前一個階段完成質量檢查後，製品帶着其元數據，一起升級到下一個階段。下一個階段首先根據元數據對該製品進行質量檢查和評測，確認達到質量標準再開始本階段的工作。
升級的方式，使得每個階段都直接基於製品開展工作，避免重複構建，在提升效率的同時，也降低了不確定性的風險。同時，針對元數據的檢測，既保證了製品在各個階段的一致性，避免篡改，又有助於提升質量檢測的自動化程度，減少人工的介入，提高效率的同時，也降低了出錯風險。
六、障礙五，您是如何滿足客戶不斷增長的需求的？
爲了滿足客戶日益增長的需求，您需要今天多做，明天做得更多。這會加重許多業務團隊的負擔，進而可能會減慢整個開發流程。
而基礎架構中的任何單點故障都可能是災難性的。地理位置分散的團隊需要始終能夠以相同的速度獲得相同的資源，任何業務更新或容量升級造成的服務中斷都會浪費大量的生產時間。
解決方案：企業級支持
企業級支持的解決方案可提供適應您的規模及成長的能力和靈活性。
可以在雲平臺中工作的製品倉庫可以幫助您無限地擴展存儲和計算的成本。您的製品倉庫可以使用的雲供應商越多，您獲得的控制權就越大。SaaS訂閱選項可確保您的資源始終可用並且是最新的。
高可用、多活的集羣配置可以確保高負載下製品倉庫的響應能力。其冗餘還爲災難恢復提供了容錯支持，並實現了零宕機的升級和維護。
支持多站點複製同步的製品倉庫可以爲跨地域的分佈式團隊提供全球範圍內DevOps過程中資源、信息的快速分享。
七、障礙六，您適應變更的成本有多高？
響應所有的客戶意味着在多個運行系統中使用多種語言進行開發。某個部門可能用Go爲雲平臺編寫代碼，而另一個部門則可能用Java爲移動設備編寫代碼。但是每種語言和技術都有其自己的要求和支持的工具。
您將爲DevOps使用哪種基礎架構？現在，在您自己的數據中心中安全運行可能是最有意義的。而未來，您可能需要雲平臺的靈活性，或者將它們結合起來以獲得各自的優勢。您將可以自由選擇最適合您需求的供應商，並在需求變化時靈活地進行更改。
解決方案：混合雲的解決方案
支持混合雲架構的製品倉庫可以幫助您的交付過程自動化，無論您使用的是哪種語言或運行於何種平臺。通過REST API進行訪問，可以方便、靈活地與您已經在使用的工具進行對接。
作爲DevOps系統的核心，您的製品倉庫在雲平臺中的功能必須與在本地自己的服務器上的性能相同。在任何環境間都能夠輕鬆地升級構建、推進交付的解決方案可以有效地幫助您在功能強大的混合雲中實現DevOps。對所有主要提供商（例如AWS、Google Cloud、Azure、阿里雲等）的集成支持，可以幫助您實現避免供應商綁定的多雲策略。
您也應該能夠自主地選擇付款方式。您需要的解決方案應該是，無論您選擇固定的許可費用還是靈活的SaaS訂閱，都能夠幫助您自由地構建現在和將來使用的系統。
五、總結
功能齊全的製品倉庫將幫助您實現自動化的軟件交付流程，並支持您採用新的工作方式。它可以爲您提供對流程的控制和洞察力，從而可以解決出現的問題並不斷改進您的方法。經過穩健的設計後，您的製品倉庫可以靈活地適應企業的特殊需求。
同樣重要的是，您需要一個可以在您的DevOps建設過程中成爲良好合作伙伴的解決方案提供商。他們應該瞭解不同的方法和行業趨勢。
JFrog的Artifactory製品倉庫是端到端DevOps平臺的核心，用於自動化管理、保護、分發和監視所有類型的製品。Artifactory得到了近6000家客戶的信任，其中包括了世界500強中93％的客戶。亞馬遜、Facebook、華爲、VMware等世界頂級品牌都依靠JFrog來管理其製品，推進其DevOps進程。
希望Artifactory同樣能夠幫助您解決上述的六大障礙，成功建設DevOps體系，實現高質量、快速、持續的軟件發佈流程。