1. 首頁 > 生活百科 > >

cd的元素及意思解釋 cd是什么( 四 )

小知識cd是什么


這里的一個重點是 ， 僅僅因為可以進行持續部署并不意味著始終部署來自管道的每組可交付成果 。 它實際上指 ， 通過管道每套可交付成果都被證明是“可部署的” 。 這在很大程度上是由持續測試的連續級別完成的（參見本文中的持續測試部分） 。
管道構建的發布成果是否被部署可以通過人工決策 ， 或利用在完全部署之前“試用”發布的各種方法來進行控制 。
在完全部署到所有用戶之前 ， 有哪些方法可以測試部署？由于必須回滾/撤消對所有用戶的部署可能是一種代價高昂的情況（無論是技術上還是用戶的感知） ， 已經有許多技術允許“嘗試”部署新功能并在發現問題時輕松“撤消”它們 。 這些包括：
藍/綠測試/部署在這種部署軟件的方法中 ， 維護了兩個相同的主機環境 —— 一個“藍色” 和一個“綠色” 。 （顏色并不重要 ， 僅作為標識 。 ）對應來說 ， 其中一個是“生產環境” ， 另一個是“預發布環境” 。
在這些實例的前面是調度系統 ， 它們充當產品或應用程序的客戶“網關” 。 通過將調度系統指向藍色或綠色實例 ， 可以將客戶流量引流到期望的部署環境 。 通過這種方式 ， 切換指向哪個部署實例（藍色或綠色）對用戶來說是快速 ， 簡單和透明的 。
當新版本準備好進行測試時 ， 可以將其部署到非生產環境中 。 在經過測試和批準后 ， 可以更改調度系統設置以將傳入的線上流量指向它（因此它將成為新的生產站點） 。 現在 ， 曾作為生產環境實例可供下一次候選發布使用 。
同理 ， 如果在最新部署中發現問題并且之前的生產實例仍然可用 ， 則簡單的更改可以將客戶流量引流回到之前的生產實例 —— 有效地將問題實例“下線”并且回滾到以前的版本 。 然后有問題的新實例可以在其它區域中修復 。
金絲雀測試/部署在某些情況下 ， 通過藍/綠發布切換整個部署可能不可行或不是期望的那樣 。 另一種方法是為 金絲雀(canary)測試/部署 。 在這種模型中 ， 一部分客戶流量被重新引流到新的版本部署中 。 例如 ， 新版本的搜索服務可以與當前服務的生產版本一起部署 。 然后 ， 可以將 10％ 的搜索查詢引流到新版本 ， 以在生產環境中對其進行測試 。
如果服務那些流量的新版本沒問題 ， 那么可能會有更多的流量會被逐漸引流過去 。 如果仍然沒有問題出現 ， 那么隨著時間的推移 ， 可以對新版本增量部署 ， 直到 100％ 的流量都調度到新版本 。 這有效地“更替”了以前版本的服務 ， 并讓新版本對所有客戶生效 。
功能開關對于可能需要輕松關掉的新功能（如果發現問題） ， 開發人員可以添加 功能開關(feature toggles) 。 這是代碼中的 if-then 軟件功能開關 ， 僅在設置數據值時才激活新代碼 。 此數據值可以是全局可訪問的位置 ， 部署的應用程序將檢查該位置是否應執行新代碼 。 如果設置了數據值 ， 則執行代碼；如果沒有 ， 則不執行 。
這為開發人員提供了一個遠程“終止開關” ， 以便在部署到生產環境后發現問題時關閉新功能 。
暗箱發布在 暗箱發布(dark launch)中 ， 代碼被逐步測試/部署到生產環境中 ， 但是用戶不會看到更改（因此名稱中有 暗箱(dark)一詞） 。 例如 ， 在生產版本中 ， 網頁查詢的某些部分可能會重定向到查詢新數據源的服務 。 開發人員可收集此信息進行分析 ， 而不會將有關接口 ， 事務或結果的任何信息暴露給用戶 。
這個想法是想獲取候選版本在生產環境負載下如何執行的真實信息 ， 而不會影響用戶或改變他們的經驗 。 隨著時間的推移 ， 可以調度更多負載 ， 直到遇到問題或認為新功能已準備好供所有人使用 。 實際上功能開關標志可用于這種暗箱發布機制 。
什么是“運維開發”？運維開發 (DevOps) 是關于如何使開發和運維團隊更容易合作開發和發布軟件的一系列想法和推薦的實踐 。 從歷史上看 ， 開發團隊研發了產品 ， 但沒有像客戶那樣以常規、可重復的方式安裝/部署它們 。 在整個周期中 ， 這組安裝/部署任務（以及其它支持任務）留給運維團隊負責 。 這經常導致很多混亂和問題 ， 因為運維團隊在后期才開始介入 ， 并且必須在短時間內完成他們的工作 。 同樣 ， 開發團隊經常處于不利地位 —— 因為他們沒有充分測試產品的安裝/部署功能 ， 他們可能會對該過程中出現的問題感到驚訝 。
這往往導致開發和運維團隊之間嚴重脫節和缺乏合作 。 DevOps 理念主張是貫穿整個開發周期的開發和運維綜合協作的工作方式 ， 就像持續交付那樣 。

推薦閱讀