它的產生

• 編譯失敗

從痛苦中產生，小公司人手少。開發人員每天需要處理bug和開發任務，當到達一個階段的時候，開發人員我說bug修復可以進行測試了，告訴QA，QA進入內網執行部署的腳本，發布到測試環境，告訴我發布失敗了，告訴編譯有個錯誤，報錯的代碼是其他人寫的，需要喊過來其他人，看看誰的問題，很快其中一個人說是他寫的忘了提交一個類了， 提交代碼後告訴我，我告訴QA好了可以重新發布了，起初一兩次大家都忍了，後來發現粗心的老鐵經常會發生這個或者那樣的錯誤，都有人少提交類或者少提交一個配置導致內網的發布失敗，於是就想了一個辦法，找了個專用的伺服器，每次提交代碼的時候，都會觸發一個webhook，將代碼重新一遍，如果發現編譯錯誤，都會編譯對應的代碼提交者，這就是最初的持續集成了。（老司機可能都遇見過，其實這個就是最早的持續集成）

• 運行時異常

雖然之前的編譯的異常解決了，但是運行時異常又凸顯出來了，所以就在這個基礎上增加了代碼的風格檢查，單元測試，覆蓋率，加入阿里巴巴編碼規範插件啊，這裡要吐槽下，據說代碼規範都是給外部人看的，內部人都不遵守，其實規範很好，遵守風格統一利於維護，不要挖坑啊老鐵。

• 手動發布

新項目，要申請資源，申請埠，配置nginx。老項目也不簡單，在二線城市也沒運維，stop下線服務。

• 手動部署

上傳代碼，重啟，驗證，上線。其實都是重複性的工作，但是這個工作要非常的消息，萬一遇見個傻叉rm -rf ，大家都喝西北風了。

• 上邊的痛點優化

從細節慢慢的去優化，優化每個環節，為了讓流程更順暢更優雅，這也就是CICD它的由來。

了解CICD和DevOps

CI 是持續集成。CD 是持續部署。

• CI

在傳統軟體中，集成基本是項目的收尾階段，我們花費幾周或者數月的時間。持續集成就是把集成提前了，搞到了開發階段，一邊開發一邊集成。讓構建和測試經常反覆的一個過程。持續集成一般是多個開發者，為同一個產品同時編寫代碼。把代碼放到一個源資料庫的地方，然後開發人員通過一個CI-server的工具進行構建和集成。持續集成首先要求開發者需要自測代碼，分別測試各自的代碼，保證他們能夠正常的工作，測試也成為單元測試，當所有的代碼都順利的測試通過，就認為他們就順利的集成到一起了。代碼的表現也是之前所預計的。好處是使集成不在是一個讓人頭疼的事情，軟體一直在編寫集成。在有持續集成之前，軟體的開發都是到收尾統一進行的。並不知道它要耗時多久，CI就是讓我們的集成融入我們日常的工作中。

• CD

持續部署是建立在持續集成之上的，持續部署就是開發人員在開發和測試代碼的時候，同時也在其他環境進行測試這段代碼。通常將不同的環境下的部署，叫做部署流水線。我們公司的部署流水線：開發環境，測試環境，准生產環境，生產環境。根據不同的公司，不同的產品，不同的團隊而變化，所有的代碼會經過前一個測試，才會進入下一個流水線中。通過這種方式，開發人員提交代碼後，都是自動的完成的。這個過程叫持續部署。

• DevOps

更好的去優化開發，運維，測試的流程。使開發和運維通過高度自動化的工具，來使得的軟體發布和構建更加的快捷頻繁可靠。Devops其實是CICD思想的延伸，如果沒有CICD其實DevOps就是空中樓閣，沒有一點意義，CICD為基礎優化開發和運維測試的所有環節。DevOps包含的東西很多，落地方案也是五花八門。

PS：CICD和DevOps有了進一步的認識，下次開始針對CICD做個環境跑跑實踐一下。

推薦閱讀：