『高階篇』docker之瞭解CICD和DevOps（41）
之前已經說了mesos，swarm，k8s都部署了，k8s因為機器的問題，我沒做部署，有了微服務和服務編排的基礎，我們可以一起了解下CICD和DevOps，之前在中級篇的文章講過，老鐵一起回顧學習下。
它的產生
* 編譯失敗
從痛苦中產生，小公司人手少。開發人員每天需要處理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做個環境跑跑實踐一下。
>>原創文章，歡迎轉載。轉載請註明：轉載自，謝謝！>>原文連結地址：上一篇:已是最新文章