這篇文章是我們「縮短週期時間」戰術指南（共分為五個部分）的第五篇也是最後一篇文章。在此處
。 如果開發人員的變更集在合併時並非始終準備就緒，則您的團隊將不練習持續交付。
完全優化產品上市時間（或週期時間）的最後一步是灌輸無縫部署，讓每個工程師負責將主要生產部門保持在可發布狀態。
真正的持續交付的障礙可分為三類：
這篇文章將引導您減輕各種障礙，以便您可以在工程團隊中實現部署就緒的文化。
過渡到cd流程要求開發團隊中的每個人都盡可能在策略上花費時間。 這種無情的時間管理方法要求在部署過程中自動執行所有操作，尤其是完全阻止部署的任何手動階段。
在許多團隊中，最艱鉅的過渡正在遠離人工關門運送的流程，例如人工質量檢查和安全檢查。 這些認可標誌的存在使您的團隊充滿信心，他們不會運送不符合要求的物品。 為了消除這些障礙，您需要解決整個軟體開發過程中的質量問題，而不僅僅是在最後。
刪除質量檢查人員作為部署的阻止者
測試的目的是手動還是自動，目的是確保軟體質量符合標準。 cd中的許多實踐，例如小批量工作和進行《準則》審查，都固有地用作質量控制措施。 您的團隊在開發過程中沒有發現的任何重大缺陷都應該通過自動化測試來發現。
將這些元件安裝到位後，您將需要確保擁有乙個有效的監視系統，在該系統中，工具會盡快出現問題。 與平均恢復時間（mttr ）一起測量平均發現時間（mttd）將幫助您持續跟蹤並提高監視和部署前測試套件的效率。
左移安全性和合規性檢查
安全是部署之前最重要的檢查之一，這就是為什麼您不應該將其暴露於人為錯誤的原因。 使您的安全專家可以策略性地考慮應該進行哪種測試，同時將大部分戰術安全工作留給計算機。
要在整個軟體交付過程中整合安全性，請考慮：
自然，您的安全團隊總會有人工工作，例如滲透測試。 但是，如果將安全性納入開發流程中，則它不會在流程的最後階段成為瓶頸，從而阻止功能向客戶推廣。
devops group進行的一項調查
發現，組織文化是cd實施的最大障礙。
養成持續交付文化所需的行為改變是適應真正的cd實踐的最困難但討論最少的方面。 您的團隊需要有信心，他們的測試基礎架構和響應變更的能力應足以支援持續部署。
為了灌輸這種確定性，您需要圍繞cd的好處進行調整，並在整個軟體交付過程中鼓勵最佳實踐。
建立持續交付的組織一致性
如果進行了正確的溝通，那麼持續交付管道對工程師來說就不算是乙個硬道理。 cd可以阻止開發人員做他們最喜歡的事情-構建有用的軟體並將其推向世界。
預期的三個結果將幫助您使管理人員和工程師都投入到持續交付中：
對單個開發人員的影響更大。 當開發人員有權合併到生產中時，他們會感到對工作擁有更多的所有權。 由於對速度的絕對期望，持續交付管道使自上而下的計畫最小化，並使開發人員能夠做出更多與實施相關的選擇。
少怪。因為對某個功能的所有權不會孤立在乙個人中，所以軟體開發過程變得更加協作。 當開發人員決定將其變更交付生產時，對功能的分布式所有權消除了一些焦慮（和潛在的責備）。
為您的團隊提供最佳實踐的變革
到目前為止，我們的《縮短週期的戰術指南》共分五部分 ，其中包括數十種可以與團隊共享的最佳實踐。 除了這些特定於階段的優化之外，您還需要指導這些通用原則：
如果這個過渡過程要花六個月的時間，請不要感到驚訝。 您的團隊對這種新工作方式的習慣將需要很長時間才能建立他們的信心。 如果您想迅速採取行動，請與一群已經有興趣並積極做出積極改變的早期採用者採用cd。 您可以從小環境中的採用摩擦中學習，以更好地緩解大型組織的過渡。
您的團隊無法克服行為或流程障礙，除非他們對自己的ci / cd工具套件充滿信心。 執行自動測試和部署的內部版本應該快速可靠，同時您的監視設定可以使您清晰，即時地了解事物的執行方式。
銳化工具
您不能一天多次向客戶發布功能，如果有以下兩種情況之一：
您的版本是flakey，或者您的構建速度很慢。
即使您的測試通過了，您的團隊也沒有信心建立自動部署，如果：
您的監控不徹底，或者您的監控沒有很好地調整。
再次，測試水域的安全方法是使用黑暗發射或特徵標記。 您的團隊將能夠測試問題的捕獲速度和恢復速度，而這些都不會損害客戶體驗。
在努力改善測試版本和監控的過程中，建議您將手動部署計畫緩慢過渡到更頻繁的節奏。 首先是每週部署，然後是每天，然後是一天多次部署。 最後，一旦按下部署按鈕就感覺很浪費時間，就可以自動化部署過程。
我們系列中的每篇文章都指導您優化軟體交付過程的每個階段。 如果您成功做到了，那麼您的開發人員將進行少量的增量更改，頻繁進行推送，並在連續交付管道中進行工作，而幾乎不會產生摩擦。
但是，除非您實際將這些更改交付生產，否則您就不會練習連續交付。 cd（以及之前的敏捷）的重點是縮短客戶與工程師之間的反饋迴圈。 逐步工作，但仍在發布大量發行版並不能實現此目標。
持續交付以降低風險，快速響應並盡快將最佳版本的軟體交付客戶。
-第一部分： 軟體交付的良性迴圈
-第二部分： 縮短週期時間的最大槓桿
-第三部分： 如何停止瓶頸審查的**審查
-第四部分： 避免浪費每個人的時間來審查**
-第五部分： 實現真正連續交付的最後一英里
from:
21英里法則 解決連續交付的最後一英里問題
21英里法則 這篇文章是我們 縮短週期時間 戰術指南 共分為五個部分 的第五篇也是最後一篇文章。在此處 如果開發人員的變更集在合併時不一定總是可以部署，那麼您的團隊就沒有在實踐持續交付。完全優化產品上市時間 或週期時間 的最後一步是灌輸無縫部署，讓每個工程師負責將主要生產部門保持在可發布狀態。真正的...
持續交付的最後一英里
如果開發人員的變更集在整合時並沒有實現長期部署就緒的狀態，那麼你的團隊其實就沒有真正的實踐持續交付。想要完全優化產品開發周期，你需要在團隊中強調無縫部署的重要性，使每位工程師都對主要生產線負責，使主要生產線保持在可發布狀態。真正的持續交付中很多團隊大概率都會遇到的以下三類阻礙 這篇文章將會告訴你如何...
8 29 最後一英里
給一顆根為 1 的有根樹，樹上每個點的權值為 w i 大小為 a i 有 q 個詢問，給出兩個引數 x,s 詢問在以 x 為根的子樹中，選出若干個點，這些點的大小之和不超過 s 並最大化權值之和 乙個明顯的 o ns 2 的樹形揹包暴力 設 f x k 為以 x 為根的子樹中大小和小於 k 的結點的...