如果開發人員的變更集在整合時並沒有實現長期部署就緒的狀態，那麼你的團隊其實就沒有真正的實踐持續交付。
想要完全優化產品開發周期，你需要在團隊中強調無縫部署的重要性，使每位工程師都對主要生產線負責，使主要生產線保持在可發布狀態。
真正的持續交付中很多團隊大概率都會遇到的以下三類阻礙：
這篇文章將會告訴你如何降低每一類障礙，從而在你的工程師團隊中實現部署就緒文化。
在團隊從傳統交付狀態過渡到持續交付的過程中，需要開發團隊中的每個人都盡可能有策略地管理時間。實現這種嚴苛的時間管理方法的前提就是要在部署過程中盡可能地自動執行所有操作，尤其是那些非常阻礙部署的手動操作。在許多團隊中，最困難的實施障礙不只單單存在於人力管理和發布流程管理（例如人工質量檢查和安全檢查）。持續交付工程中代表「批准許可」標誌的存在會讓團隊有信心相信他們交付的產品是符合要求的。因此，解決軟體開發工程中的品控問題不能是只放在最後一步實施的，在每個環節都進行嚴格把控是消除流程實施中的障礙最關鍵的一步。
| 移除部署過程中的障礙——qa（質量測試） |
無論是手動還是自動，測試的目的是確保軟體質量符合標準。持續交付中的許多操作，例如小批量工作和**審查，都自帶質量管控監測的特性。任何在開發過程中沒有被團隊所發現的重大缺陷都應該通過自動檢測來發現。
為了降低因qa帶來的風險，你的團隊應該：
滿足以上三種要求之後，還將需要確保系統中存在有效的檢測系統，這樣做有乙個很大的好處就是讓你的系統能夠及早顯現出目前所存在的問題。故障診斷所需平均時間（mttd）和故障恢復所需平均時間時間（mttr）將幫助你持續跟蹤並提高管控和部署前測試套件的效率。
| 安全合規檢查 |
安全檢查是部署前最重要的檢查之一，這就是為什麼安全檢查不能容忍人為錯誤。你團隊的安全專家應該策略性地考慮應該進行哪種測試，同時將大部分戰略性的安全工作留給計算機去完成。
如果你的團隊想把安全性全程融入到軟體交付的過程中，你應考慮如下操作：
安全團隊的工作不能完全由機器代替，例如滲透測試。但是，如果你將安全性納入整個開發流程中，人為工作便不會在開發流程的最後階段成為瓶頸，導致功能無法推向客戶。
在devops group進行的一項調查中發現，組織文化是cd實施的最大障礙。構建持續交付文化所需的工作模式/行為改變是適應真正的cd實踐最困難、但討論最少的方面。你的團隊需要有信心，他們的測試基礎架構和響應變更的能力都應該足夠強大，能夠支援持續部署。為了像團隊輸出這種確定性想法，你需要圍繞cd的優勢進行調整，並在整個軟體交付過程中鼓勵最佳實踐。
| 建立持續交付的組織一致性|
如果溝通得當，那麼持續交付對工程師而言不應該是乙個難以接受的事情。cd可以使開發人員做他們最喜歡的事情-構建有用的軟體並將其推向世界。以下三個預期結果將幫助管理人員和工程師都投入到持續交付中:
| 為你的團隊提供最佳實踐的變革 |
到目前為止，我們的_「縮短專案週期的戰術指南」（ tactical guide to a shorter cycle time five-part series ）_共分五部分，其中包括數十種可以與團隊共享的最佳實踐。除了這些特定階段的優化之外，你還需要以下這些通用原則的指導：
如果這個過渡過程需要超過6個月的時間，請不要感到驚訝。你的團隊需要很長時間才能建立起對這種新的工作方式習慣的信心。如果你想要快速地採取行動，請與一群已經有興趣並且樂於做出積極改變的早期探索者來一起研究、使用ci/cd。相比於大環境，你反而可以在小而精的組織環境中更好地學習、打磨新的模式。
即便你的團隊對於自己的ci/cd工具套件充滿了信心，仍然需要面對工作習慣、流程及溝通上的困難。
| 優化你的工具 |
如果有出現以下情況中的任意乙個，那麼你就不能每天多次向客戶發布功能:
1、你的軟體版本很不穩定
2、你的軟體版本速度非常緩慢即使你的測試通過了，但團隊也沒有信心設定自動部署，如果:
1、你的監測不徹底
2、你的檢測結果沒有得到很好的調整這裡提供一種我們覺得比較安全的測試方法：使用灰度測試。團隊在這種情況下既能夠測試問題的捕捉速度和恢復速度，同時又不會損害客戶體驗。當你努力改進測試版本和監控過程時，我們建議你慢慢地將手動部署過渡到更頻繁的節奏。首先可以從每週部署開始，然後是每天，再然後是一天多次部署。最後，當你一旦按下部署按鈕就感覺很浪費時間時，那就可以進入自動化部署過程了。
通過以上內容的介紹，如果你的團隊成功實現了持續交付，那麼開發人員將在幾乎不會產生衝突的情況下通過持續交付的pipeline實現軟體的細微增量更改、版本迭代及持續推送。但是，除非你實際將這些更改/更新交付到客戶手中，否則你就不算是真正實踐了持續交付。cd（以及之前的敏捷）的重點是縮短客戶與工程師之間的反饋迴圈。以增量的方式工作，但如果仍在發布大量版本，就沒有辦法實現這個目標。持續交付需要以減少風險、快速響應，並盡可能快地將軟體的最佳版本交付給客戶。
歡迎點選「京東智聯雲
21英里法則 解決連續交付的最後一英里問題
21英里法則 這篇文章是我們 縮短週期時間 戰術指南 共分為五個部分 的第五篇也是最後一篇文章。在此處 如果開發人員的變更集在合併時不一定總是可以部署，那麼您的團隊就沒有在實踐持續交付。完全優化產品上市時間 或週期時間 的最後一步是灌輸無縫部署，讓每個工程師負責將主要生產部門保持在可發布狀態。真正的...
解決連續交付的最後一英里問題
這篇文章是我們 縮短週期時間 戰術指南 共分為五個部分 的第五篇也是最後一篇文章。在此處 如果開發人員的變更集在合併時並非始終準備就緒，則您的團隊將不練習持續交付。完全優化產品上市時間 或週期時間 的最後一步是灌輸無縫部署，讓每個工程師負責將主要生產部門保持在可發布狀態。真正的持續交付的障礙可分為三...
8 29 最後一英里
給一顆根為 1 的有根樹，樹上每個點的權值為 w i 大小為 a i 有 q 個詢問，給出兩個引數 x,s 詢問在以 x 為根的子樹中，選出若干個點，這些點的大小之和不超過 s 並最大化權值之和 乙個明顯的 o ns 2 的樹形揹包暴力 設 f x k 為以 x 為根的子樹中大小和小於 k 的結點的...