 |
VOOZH | about |
|
VOOZH | about |
DevOps 的出現並非只是為了順應開發人員和運維人員應該協同合作的理念，更大程度上，它是企業在走向現代化應用交付的過程中需要經歷的文化轉型。DevOps 的最終目標是能夠更頻繁地發布高質量的軟體，並通過促進溝通和協作來實現這一目標。
Octopus Deploy 創始人兼執行長 Paul Stovell 說：「現如今，團隊應該做出更快的改變。如果沒有開發人員和運維人員成功合作，實現快速改變的機會幾乎為零「。
CI/CD 管道是 DevOps 背後的推動力，這種推動力依賴 DevOps 的內聚性，並將其帶入到現代軟體的開發和交付當中。
來自 CA Technologies 的持續交付總經理 Jeff Scheaffer 說：「正在進行數位化轉型的公司在面臨組織變革時，DevOps 通常被認為是一劑良藥，但 CI/CD 管道才是推動 DevOps 走向成功的引擎，幫助企業更快地交付更好的應用。這是企業從手動轉向自動化、從單體應用交付轉向現代應用交付的核心業務流程「。
OpsGenie 聯合創始人兼工程副總裁 Sezgin Küçükkaraaslan 說，在討論 DevOps 時經常會提到 CI/CD 管道，因為它在團隊之間建立起了橋樑，並幫助他們看到了更大的藍圖，這個藍圖就是能夠成功構建出軟體系統，並交付給用戶。
他說：「CI/CD 管道是將代碼移交到生產環境最快的一種方式。開發人員能夠通過自動化且不易出錯的方式輕鬆地構建、打包、集成、測試和發布代碼「。
Küçükkaraaslan 補充道，DevOps 專注於文化，而 CI/CD 管道則專注於能夠幫助團隊適應不斷變化的文化的過程和工具。
Stovell 說，CI/CD 管道是 DevOps 的關鍵推動者，因為它消除了 DevOps 流程中的摩擦因素，從而可以更快地發生變化和投入生產。他還解釋說，消除的摩擦越多，發生變更的周期就越短。「這意味著你正在推動業務向前發展，並創造出了一個反饋閉環以及持續改善的環境」。
Mobile Labs 總裁兼執行長 Dan McFall 說，管道「實際上是發布流程自身的一個循環。它是一個持續的過程，包括編寫代碼、測試代碼、部署代碼、在生產環境中重新測試，然後再次完成對整個過程的反饋。這是實現高質量發布並持續運作一切的能力「。
如果能夠從更寬泛的角度來思考管道，它將會讓你看到更完整的生命周期，不僅包括了將軟體交付到生產環境，還會看到它時如何交付的以及交付之後會發生什麼。Stovell 說，如果事情失敗了，你可以看到出了什麼問題，並很容易進行恢復。
API Fortress 創始人 Patrick Poulin 說，CI/CD 管道中最重要的方面是 C，它代表持續性。為了在 CI 和 CD 方面獲得成功，你必須「具備在不影響其他事情的情況下持續前進的能力」。
管道包含了一個發布階段，首先你要知道自己要交付什麼，然後進入測試階段、預生產階段、部署階段，最後進入生產環境。來自 XebiaLabs 的首席產品官 Robert Stroud 說，這當然是一種經過簡化的管道，它的基本思想是以自動的方式經過這些階段或批准點。「目前業界存在幾個切入點，我們將這些切入點交給開發團隊、測試團隊、階段發布團隊和部署團隊，而只有自動化所有這些步驟和階段才能真正加速整個過程。」
來自 CA 的 Scheaffer 說，之所以被形象化地稱為管道，是因為在理想情況下，變更是從頭到尾一個接一個地發生。
來自 OpsGenie 的 Küçükkaraaslan 說，從更高的層面來看，管道「包括在代碼庫合併之前進行的編譯、打包和基本測試。將代碼合併到主分支之後，將運行其他測試，以確保應用程式能夠使用真實的配置和其他服務。性能和安全測試也在這個時候運行。隨後就可以將代碼部署到 staging 環境，然後再到生產環境「。
Scheaffer 說，保持管道的簡單性、可見性和可衡量性是讓管道奏效的最好方式。這裡的關鍵因素包括管道的自動化和編排、改進、與利益相關者保持一致，以及對「好」的評估能力。
McFall 說，「DevOps 讓你以漸進和可管理的節奏取得進展，讓你能夠在軟體準備就緒時擁有更強的信心，並且確實交付了正確的東西。」
Scheaffer 說，管道應該是流動式的，不同的階段可以同時發生。「例如，測試可以不需要等開發完成編碼才開始進行。相反，測試可以與開發同時進行——與開發一起並行測試更小的代碼塊「。
Scheaffer 解釋說，管道就像一根含有多級玻璃纖維的光纜。「每根玻璃纖維都可以代表單個應用程式的工作流，你可能會有許多不同的應用程式在管道中移動，而你需要做好協調工作」。
不過，同時運行多條線索很容易帶來複雜性，所以不要讓你的管道成為瓶頸。OpsGenie 的 Küçükkaraaslan 建議 DevOps 團隊要不斷監控所有組件，確保能夠發現問題並儘快解決。
另外，他還解釋說，團隊應該密切關注測試性能。「大家都喜歡將新代碼快速發布到生產環境，但如果沒有經過正確的測試，這樣做是非常危險的。系統相互依賴的複雜性意味著一切都有可能出錯。監控測試環境中新代碼的執行情況對於發布穩定的版本來說至關重要。所以，嘗試在快速測試和模擬生產環境測試之間找到最佳平衡。「Stroud 說，擁有良好的測試套件和良好的測試覆蓋率可以更好地了解部署了什麼、部署在哪裡和部署時間。
Küçükkaraaslan 解釋說，CI/CD 管道不是一成不變的，它會隨著時間推移而發生演化，團隊和業務需要能夠隨著管道一起演化。
他說：「我們不斷努力改善我們的 CI/CD 性能，並擁抱最佳實踐。也就是說，我們一直在收集每個參與交付新功能的人的反饋意見，以便找到可以改進的地方。隨著業務的發展，我們的 CI/CD 流程也必須跟著演化「。
McFall 說，如果你沒有為 CI/CD 管道創建反饋循環，那麼實際上你並沒有在實施 DevOps。「建立反饋循環的好處是，它可以讓你有更強的信心和更快的速度去做事情。」即使現在團隊可以把所有東西都推到生產環境中，但這並不意味著他們應該一直這麼做。這就是反饋循環發揮作用的地方，因為它確保你可以聽到客戶的意見，而不只是一直在推出新的東西。「請注意你的同事在做什麼，他們的成功之處在哪裡，以及是否有機會不要犯同樣的錯誤「。
Scheaffer 建議我們遠離快速修複方法。他說：「在生活中，快速取得勝利是很誘人的，但也是要付出代價的。在 CI/CD 管道中，它表現為技術債務，發展腳步停滯不前，其他團隊無法參與進來，以及在組織內部對什麼是』好』的東西理解不一致。其結果是要花費很多精力重建管道「。McFall 相信組織會不斷試圖找到一種適用於所有工具的方法，而實際上，他們真正需要做的是找出對他們的業務和風險狀況有意義的事情。
Stroud 表示，要儘可能地利用自動化，但不要陷入自動化孤島的局面。Stroud 解釋說，目前管道中存在的一個常見問題是，企業的自動化並沒有覆蓋所有部門，因此存在自動化孤島。「DevOps 的關鍵規則之一是我們需要在整個工具鏈中進行一致的協作，否則它就變成年輕玩家最大的陷阱之一」。組織可以通過標準化和合理化他們在每個孤島中使用的工具來解決這個問題。
最後，不要陷入責備文化。Stroud 說，當事情失敗時，關鍵的不是問責，而是想想如何能夠做得更好，如何提高速度，以及如何交付更好的結果。「你希望人們試錯，並從錯誤中學習。這必須成為 DevOps 的基本原則，而不是在發現部署的變更不符合要求之後對誰嚴加指責。借鑑這些經驗或反饋，並在未來改變你的流程，這樣你就可以持續創造價值。」
Stroud 說，儘管 CD 通常被稱為持續交付，但一些組織正在將其視為持續部署。
現如今，軟體變更在規模、性質和增量差異方面正逐漸縮小。這種變化使得團隊能夠達到可以自動部署的程度。Stroud 說：「現實情況是，我們最終按照迷你的速率進行部署。變更在瞬間就發生，可能是每周一次，某些組織會收集變更，並把它們組合在一起，然後按月部署。具體情況取決於業務和業務轉型的意願「。
為了跟上變化的速度，團隊需要採用良好的部署方法，例如金絲雀發布。如果使用金絲雀發布，變更先被發布到一小組樣本實例上，以便驗證變更是否沒有問題。如果使用藍綠部署，就可以以一種可控的方式讓不同的用戶收到變更。開發者可以收到反饋，確保交付的東西符合要求。
Stovell 說，在部署軟體時一個常見的錯誤是，團隊編譯代碼並將其部署到測試環境中，而在進入生產環境時再次編譯代碼。「這不是一個好的做法，因為在你第二次編譯代碼時，會引入很多潛在的問題。你無法保證你測試過的東西就是最後進入生產環境的那個「。正確的做法是只構建一次，保留構建過程中生成的文件副本，然後將其部署到測試環境和生產環境中。
成功實現持續部署的另一種方式是為每個環境提供一致的流程。Stovell 說：「保證生產環境部署成功的最好方法就是確保生產環境的流程儘可能與其他環境保持一致。」
Küçükkaraaslan 說，部署管道的高級別視圖被稱為 DevOps 組裝線。他說：「我們所要面臨的挑戰是，DevOps 工具鏈並不像 CI/CD 那樣完善，並涉及到對人的依賴，因此可能會效率低下。DevOps 組裝線嘗試將活動連接到基於事件驅動的工作流程中，然後可以將這些工作流程與特定的應用程式或服務相關聯。」
API Fortress 創始人 Patrick Poulin 說，如果你將 CI/CD 管道視為一直在運行的軟管，那麼 API 測試就是拖慢流速的扭結。
API 測試已經成為 DevOps 開發過程中的一個痛點，因為它一直被忽視。他說：「這是人們一直在拖延的事情之一，因為可能不存在一種工具可以讓這個問題變得容易解決，或者因為它需要大量的開發工作」。
如果團隊沒有測試這些 API，那麼在錯誤發生時他們可能就捕獲不到，或者需要數周時間才能發現錯誤，因為除非 API 完全不可用，否則他們將看不到任何問題。Poulin 說：「如果一直延續下去，可能會變成一個非常嚴重的錯誤，只因團隊沒有對其進行全面的測試」。
與自動化網站和應用程式測試相比，DevOps 團隊需要在 API 測試中也投入同樣的工作量。Poulin 說：「相比前端，API 也同樣重要，API 涉及到公司系統的每個部分，因此對測試、可靠性和正常運行時間有足夠的了解」。
團隊應該要測試所有的 API，而不僅僅是測試單個端點。還要創建集成測試，也就是用於重現常見用戶流程的多步驟任務。Poulin 解釋說，你不僅需要對單個功能很了解，而且還需要知道它們在與其他功能或過程結合在一起時是如何工作的。「當你以真實的用戶體驗方式來測試你的東西，就會發現它們之間存在的差別」。
關鍵在於要找到一種工具或平台，讓每個人都可以知道 API 的狀態，比如我的 API 在運行中嗎？昨天有沒有出現 API 問題？Poulin 說：「如果你有適當的工具，任何人都可以通過幾次點擊就可以得到答案，並充分了解他們的 API 的健康狀況」。
根據云管理解決方案提供商 TriNimbus 的首席技術官 Goran Kimovski 的說法，DevOps 和 CI/CD 管道有兩個價值原則。第一個原則是不斷整合代碼變更，並按照一組定義好的測試標準進行測試。Kimovski 說，這是一個非常有吸引力的主張，因為你可以持續確保代碼可以正常運行。第二個原則往往難以實現，那就是加速採用。Kimovski 解釋說，開發人員編寫的應用程式代碼需要部署到某種基礎設施上，但這一過程通常與手動變更管理流程相關聯。
他說：「軟體行業已經花了多年時間在單元測試以及像自動化集成測試、最終用戶測試、性能測試這樣的概念上，但測試基礎設施的整體概念仍處於早期階段，測試代碼本身都很困難。」
Kimovski 說，這是因為開發人員需要調配和部署基礎設施。而傳統方案則包括實際的硬體或虛擬環境，要求傳統的網絡工程師、IT 運維和系統管理員了解相關技術，將硬體組合在一起，建立網絡，創建虛擬機並將它們交給開發人員或 QA 去配置，然後再讓其他人在上面部署應用程式。「這一過程需要由多人來處理，並依賴大量的體力勞動，不穩定或不可重複「。Kimovski 補充說，這不僅耗費時間，還會引入外部成本。
Kimovski 建議基於雲來實現 CI/CD 管道。他說：「在雲中配置一台伺服器，運行 15 分鐘後關閉，你只需要為此支付 15 分鐘的費用。而在某個數據中心里配置伺服器意味著你必須擁有物理硬體，這對你的業務而言是額外的成本。」另外，使用物理硬體來測試基礎設施代碼會有所限制，因為不是每個人都可以訪問到它。他解釋說，雲將其大眾化，並將其轉化為運營成本。
活動推薦
目前運維的方法有很多痛點，無論是異常檢測，故障發現，瓶頸分析，自愈等工作都需要有大量的人工參與。隨著公司越做越大，運維的場景也將會變得越來越複雜。那麼僅僅依靠人工經驗的運維工作將會變得捉襟見肘，所以就必然會走向基於機器學習算法的智能運維（AIOps）。來 ArchSummit 全球架構師峰會上，和我們一起關注 AIOps 的現狀和未來發展。
