本文是對本人對devops持續交付流水線的一些個人理解（只針對現所在公司的情況），不一定準確，僅供參考，後期會不定期修改
一、任何公司項目都存在流水線
一些初創公司有可能就寥寥數人，老闆可能就兼任產品經理，開發可能兼任開發、測試、運維、、
即便這樣的情況，我也說項目從提出到面向用戶也是存在流水線的
都會經歷：需求提出-->開發-->測試-->上線
這可以說是最簡單的一個流水線了，每個節點都是人工手動完成，還可能是同一個人完成，可能沒有人給出什麼時間點幹什麼事，但具體的流程架子是抹不掉的
到這裏我們來拋出個問題：在這樣的公司去試行devops現實嗎？有必要嗎？
二、CI、CD
CI：持續集成，傳統的項目會將項目拆分爲幾個大的模塊，然後各自開發，開發完後（這個時間相對較長）各個模塊開始集成（拼湊），然後發現很多地方格格不入，難度很大
而持續集成則是，開發人員修改很小一部分代碼就立馬提交到代碼倉庫進行集成，這樣整個項目到結束一直在不斷做集成，風險相對較小
CD：持續交付，以前我們在開發測試完畢後會手動搭建服務器環境，然後手動部署對外開放，後面我們修改代碼後又會重複去打包代碼，上傳服務器、重啓，這一切的操作都是手動完成，這中間很明顯有很多的不足：環境的不一致、手工的失誤、異常回滾等等，，需要耗大量的人力；
而持續交付是：代碼提交後自動觸發後續的打包、部署、異常回滾等，大大減少耗時和錯誤率，讓整個流程更自動化（也就是釋放雙手）一個按鈕就可以實現上線
三、理想中的持續交付流水線
持續交付的過程中大多數情況下開發並不是瓶頸，出現瓶頸的地方往往是測試、環境、上線、異常回滾；
而理想中的情況就是減少人工測試，測試完畢一鍵上線，系統隨流量自動擴縮容、、、
自適應，，解放勞動力
四、何時引入devops
引入devops的目的就是爲了解決整個交付過程中惹人煩的地方，接入之前首先要對項目的整體架構，整體流程有全局概念，然後找出實際痛點，有針對性的解決，devops並不是重置流程，而是針對痛點貫穿流程
如果是新項目：可將開箱可用的開源項目引入進來如jira、Jenkins、gitlab等能大大提高效率
如果是老項目：我們要儘可能的從全局出發，找到痛點，有針對性的引入開源工具解決問題
這是一個持續的過程，一切爲了效率，當然我們還可以自研更適合公司模式的工具，讓人性化和效率結合，
經過一系列的優化後肯定會到達一個適應期，就是表面看似沒問題；那麼我們就要主動發現問題，要制定一系列的指標，通過指標來判斷哪些地方是瓶頸，有問題才能更好的解決問題
公衆號主要記錄各種源碼、面試題、微服務技術棧，幫忙關注一波，非常感謝
