DevOps系列(1)-整體架構

扯閒淡

在進入正式話題以前，先扯個淡，這算是第一篇我正式在博客上發佈的隨筆吧，以前也一直有想寫點什麼，將本身多年的工做經驗分享出來，供你們參考點評，可是奈何一直對本身的文字功底不自信（其實也確實比較爛，上學期間，語文永遠是拖後腿的），固然，最主要仍是由於本身的懶惰，致使一直沒有付出行動。

細算下來，到目前爲止，我從事.Net開發已經差很少八年了，也算是一隻見證了.Net從興起到衰落（不知道這麼說會不會被打）再到逐漸有復甦跡象的老鳥了。在這個過程當中，帶過團隊，也擔任過架構師（當時爲了證實本身並不是野路子，2018年還專門拿下了軟考《系統架構設計師》認證）。在企業內部Wiki上也寫過很多文章，作過很多技術分享，但畢竟是小羣體，文章寫得再爛(甚至只有提綱，或者隻字片語，或者只有一張圖)，也能夠經過溝通解釋清楚，就算真的寫錯了，也會有不少補救措施，不會產生什麼不良影響。而對外發布，對內容的完整性，嚴謹性以及文字組織能力的要求就要高得多，而這正是我不得不花精力填補的短板。

2020年註定是不平凡的一年，對於咱們這些.Neter來講更是如此，我不肯定可否經過文字完整的出本身的思想，可是我會盡力，但願個人文字不會帶偏你的思路，固然，若是你能贊同個人觀點，並能從中獲得一點點啓發，那將是我莫大的榮幸。

好了，閒淡扯完了，進入今天的正題吧！

整體架構

在這裏，我準備結合本身的工做經歷和我的理解，針對當前比較火熱的DevOps話題出一個文章系列。可是，在這以前，有必要從總體上梳理一下思路，圈定一下範圍，以保證總體思想的一致，並方便後續文章的展開。

這個系列並無涵蓋DevOps的所有內容，例如，沒有包含服務的鏈路追蹤、日誌監控、健康檢查等微服務相關的部分，也沒有包括集羣和容器的監控、管理、健康檢查、報警等更偏向運維的部分，而是更多的聚焦在CI/CD上。微服務相關的部分後面可能單會獨寫一個系列詳細探討，而運維相關部分則不會過多涉及，即便是K8S容器編排也只會點到爲止，由於這部分我本身接觸的也比較少，不敢瞎寫。

概覽

注意，這裏的Jenkins並不是部署了多套，而是在同一套Jenkins中根據部署環境的不一樣劃分了多個分組，每一個分組有各自不一樣的權限和功能。

流程說明

1. 開發人員每次寫完代碼以後，Push到源代碼倉庫（企業中必定會有本身SVN或者Git等私有倉庫，這是即便沒有DevOps或CI/CD概念也會存在的最基本的基礎設施，我後續會直接使用GitHub，所以不會單獨介紹這部份內容），自動（或者定時輪詢）觸發Jenkins構建，完成Nuget包還原，靜態代碼審查，單元測試，上傳報告到SonarQube服務器，若是構建失敗，或者代碼審查和單元測試報告不達標（實際工做中，因爲各類緣由，這個目標比較難以達到），則反饋開發修復，若是達標則構建鏡像併發布到開發環境的Docker容器中；
2. 開發人員功能開發完成，並經過開發環境容器測試經過後，將Dev分支合併到Master分支，併發送提測通知到測試人員；
3. 測試人員（能夠在分支合併的時候自動觸發，或者定時輪詢）構建Master分支，大致流程跟開發分支相同，不一樣點就是會發布到儘可能貼近生產環境的Docker集羣，同時將鏡像Push到Harbor鏡像倉庫；
4. 測試人員測試經過後，通知運維人員安排上線；
5. 運維人員經過手動觸發Jenkins的方式，先從Harbor上Pull對應版本的鏡像，並逐步分階段完成到生產環境Docker集羣的部署。
6. 剩下的就是生產環境α測試和β測試及一系列的監控了。

總結

DevOps更多體現的是一種思路和流程，可能每一個團隊作法都不同，例如，有的團隊可能在Dev分支上測試，而在Master分支上構建生產環境鏡像；有的團隊可能由於環境隔離的緣由，不得不部署多套Jenkins環境等，但歸根結底目的是同樣的，就是達到全程自動化，減小人力勞動（不知道算不算本身砸本身飯碗）以及各類人力，環境等因素致使出錯的機率。

後續的文章我會按照這個思路展開，若是存在考慮不周，或者能夠改進的地方，但願各位大佬們可以及時指出，你們一塊兒探討，共同進步！

最後，但願.Net生態愈來愈好！