本文是對本人對devops持續交付流水線的一些個人理解（只針對現所在公司的情況），不一定準確，僅供參考，后期會不定期修改

一、任何公司項目都存在流水線

一些初創公司有可能就寥寥數人，老板可能就兼任產品經理，開發可能兼任開發、測試、運維、、

即便這樣的情況，我也說項目從提出到面向用戶也是存在流水線的

都會經歷：需求提出-->開發-->測試-->上線

這可以說是最簡單的一個流水線了，每個節點都是人工手動完成，還可能是同一個人完成，可能沒有人給出什么時間點干什么事，但具體的流程架子是抹不掉的

到這里我們來拋出個問題：在這樣的公司去試行devops現實嗎？有必要嗎？

二、CI、CD

CI：持續集成，傳統的項目會將項目拆分為幾個大的模塊，然后各自開發，開發完后（這個時間相對較長）各個模塊開始集成（拼湊），然后發現很多地方格格不入，難度很大

而持續集成則是，開發人員修改很小一部分代碼就立馬提交到代碼倉庫進行集成，這樣整個項目到結束一直在不斷做集成，風險相對較小

CD：持續交付，以前我們在開發測試完畢后會手動搭建服務器環境，然后手動部署對外開放，后面我們修改代碼后又會重復去打包代碼，上傳服務器、重啟，這一切的操作都是手動完成，這中間很明顯有很多的不足：環境的不一致、手工的失誤、異常回滾等等，，需要耗大量的人力；

而持續交付是：代碼提交后自動觸發后續的打包、部署、異常回滾等，大大減少耗時和錯誤率，讓整個流程更自動化（也就是釋放雙手）一個按鈕就可以實現上線

三、理想中的持續交付流水線

持續交付的過程中大多數情況下開發并不是瓶頸，出現瓶頸的地方往往是測試、環境、上線、異常回滾；

而理想中的情況就是減少人工測試，測試完畢一鍵上線，系統隨流量自動擴縮容、、、

自適應，，解放勞動力

四、何時引入devops

引入devops的目的就是為了解決整個交付過程中惹人煩的地方，接入之前首先要對項目的整體架構，整體流程有全局概念，然后找出實際痛點，有針對性的解決，devops并不是重置流程，而是針對痛點貫穿流程

如果是新項目：可將開箱可用的開源項目引入進來如jira、Jenkins、gitlab等能大大提高效率

如果是老項目：我們要盡可能的從全局出發，找到痛點，有針對性的引入開源工具解決問題

這是一個持續的過程，一切為了效率，當然我們還可以自研更適合公司模式的工具，讓人性化和效率結合，

經過一系列的優化后肯定會到達一個適應期，就是表面看似沒問題；那么我們就要主動發現問題，要制定一系列的指標，通過指標來判斷哪些地方是瓶頸，有問題才能更好的解決問題

?

公眾號主要記錄各種源碼、面試題、微服務技術棧，幫忙關注一波，非常感謝

總結

以上是生活随笔為你收集整理的持续交付流水线的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。