什麼是以特性為核心的持續交付｜阿里巴巴DevOps實踐指南
編者按：本文源自阿里云云效團隊出品的《阿里巴巴DevOps實踐指南》，掃描上方二維碼或前往：//developer.aliyun.com/topic/devops，下載完整版電子書，了解阿里十年DevOps實踐經驗。
隨著微服務架構和雲原生技術的成熟，持續交付的理念也深入人心。持續交付要求開發團隊持續、高頻地向生產系統交付軟體。然而，不斷增多的服務數量，給企業交付流程管理帶來了巨大挑戰。同時，在 DevOps落地的過程中，逐步開放生產環境的發布許可權給到開發人員，這種松管控與企業安全生產存在衝突，多應用版本之間的協同問題也逐漸凸顯。如何解決企業在新技術轉型和 DevOps 落地中的痛點，拿到技術變革帶來的效能紅利，是每個企業包括阿里巴巴都必須面對和解決的難題。
軟體交付挑戰
阿里巴巴 2008 年對淘寶巨型服務進行拆分以後，逐步形成了一套適用於服務化、分散式架構的中間件體系，解決了複雜系統性能和穩定性在業務高速擴張中的瓶頸問題。隨之而來的是應用變多、架構依賴複雜、人員數量高速膨脹、技能參差不齊等等問題。總結下來有以下幾個方面：
應用數量多
微服務架構被廣泛應用以後，首先面臨的就是應用數量的快速膨脹。原有研發流程也必須從批量發布模式向持續交付模式轉型，否則會導致發布軟體的風險和回滾的複雜度不可控。另一方面，測試和運維的工作量因為應用的膨脹而倍增，變成整個研發團隊的效率瓶頸。打破這種瓶頸的方法就是 DevOps 的全面落地，把整個軟體交付過程交給開發來主導，從而解除瓶頸提升效率。
架構依賴複雜
微服務架構讓應用內依賴變為了應用間依賴，變更過程無法做到原子化，因此需要很好的模組拆分和介面設計。一方面減少單特性覆蓋的應用數量，變更順序可控、回滾風險可控；另一方面單元測試能覆蓋的場景需要集成測試來覆蓋，導致開發過程對測試環境的使用頻度和依賴度變高，需要穩定、可靠的環境來保障所有開發人員都可以並行工作。
測試資源成本大
測試環境受到資源成本和運維成本雙重製約。在業務發展初期，可以採用全鏈路完整部署加上多套環境的方式來滿足研發團隊的要求。但是隨著業務的快速發展和研發團隊的快速擴張，不斷地增加環境在成本上已經無法負擔。因此需要一套運維高度自動化，高度彈性隨用隨取，並且可以實現局部隔離的測試環境方案來滿足多版本部署需求。
研發協同難
研發環節的協同分為開發間協同和測試，開發、運維多角色間協同兩種。前者主要解決並行開發、按需上線的問題。後者解決的是在一個交付流程中各司其職、互相約束，確保軟體能高品質、安全交付的問題。在DevOps 場景下軟體交付過程由開發人員主導，而測試和運維角色則需要承擔流程守護、門禁卡點、提供自動化工具的責任。為了提升協同的效率，需要一個能夠滿足以上要求的工具平台來將團隊的約定固化下來，確保團隊各個角色可以高效率的完成工作。
線上風險大
線上的風險來自於兩方面，一方面越來越高頻的線上迭代意味著出錯的概率也在變大，另一方面隨著系統規模變大，傳統人防人治的手段已不可能滿足風控要求。因此必須從出錯可能性和出錯影響面兩個方面系統性地去解決問題，前者關注能否在出錯之前對風險進行攔截，而後者關注系統變更影響的用戶數量和頻度。這兩種主動和被動防禦措施的相結合，可以有效的解決風險控制的投入產出比問題，從而達到一個比較優的狀態。
解決思路
為了解決以上在企業規模增長和新技術應用中的種種交付痛點，阿里巴巴不斷探索和嘗試，逐步摸索出一種適合這種業務發展快、軟體迭代快、架構依賴複雜場景的交付方法和實踐，我們稱之為「以特性為核心的持續交付」。它有三個特點：
以特性為核心
特性是一個用戶能體驗到的產品能力的最小單元，其程式碼可能涉及到多個應用，因此特性也是協同多個開發團隊完成一個能力的最小單元。以特性為核心的交付過程管理可以有效地將開發、測試等角色連接起來並統一推進，比如組織隔離測試環境、運行自動化測試、編寫測試用例、做好測試驗收等等。
以應用為載體
應用可以直接對應一個服務，是提供一種業務能力的最小單元，也是軟體交付和運維的最小單元。可以通過應用串聯程式碼、流水線、環境、測試和資源，以及外圍工具鏈比如監控、資料庫、運維、中間件等。開發人員可以在工具平台上定義他的應用，及應用的交付運維過程，比如配置流水線、規劃環境、創建資源、設置部署策略等。以獨立應用為載體的交付流程可以實現軟體交付的原子化，並強迫開發降低應用間的耦合性，同時避免系統級集中式交付模式的慣性。
松管控與強卡點
在軟體高速迭代下需要兼顧品質和效率，DevOps 模式需要給開發人員足夠的自由度來完成軟體的線上變更，阿里巴巴結合自身業務特點，在實踐上採用了松管控和強卡點結合的方式。「松管控」表現在有多種流水線可以供開發選擇，應用負責人可以完整定義這個應用的各種規則，比如如何部署、如何測試、資源環境如何配置。在技術可控的前提下，還可以開放線上測試，比如全鏈路壓測和全鏈路灰度。輕發布，重恢復，在每一個應用維度，開發可以隨時使用流水線來交付程式碼，不主張過多的人為限制，重點需要思考的是如果出問題，如何控制影響面，如何快速恢復。「強卡點」是一種軟體品質底線思維的體現，比如程式碼審核和品質紅線，規約檢查，發布窗口，安全檢查，線上灰度卡點等。這些卡點是為了保障集團所有開發工程師步調統一，交付合格的產品。
持續交付的核心是快速高品質地交付價值，給與開發人員最大自由度，負責開發和運維全部過程。在監控、故障防控工具、功能開關的配合下，可以在保障用戶體驗和快速交付價值之間找到平衡點。
總結
今天，基於雲的開發已成為主流，這是效能提升的巨大機會，同時又對工程實踐提出了前所未有的要求。比如，雲原生基礎設施、雲原生中間件和新一代的雲軟體編程方法等等，都要求有與之適配的實踐和工具。在適配新的技術發展趨勢過程中，阿里形成了以特性為核心的持續交付工程實踐，並且將其內建到 DevOps 工具體系中，以保障實踐準確、有效地落地。
接下來的我們將按照軟體開發和交付過程逐一介紹，具體包括：開發、調試、測試、集成、交付。
【關於雲效】
雲效，雲原生時代一站式BizDevOps平台，支援公共雲、專有雲和混合雲多種部署形態，通過雲原生新技術和研發新模式，助力創新創業和數字化轉型企業快速實現研發敏捷和組織敏捷，打造「雙敏」組織，實現 10 倍效能提升。
