扯閑淡
在進入正式話題之前，先扯個淡，這算是第一篇我正式在博客上發布的隨筆吧，之前也一直有想寫點什么，將自己多年的作業經驗分享出來，供大家參考點評，但是奈何一直對自己的文字功底不自信（其實也確實比較爛，上學期間，語文永遠是拖后腿的），當然，最主要還是因為自己的懶惰，導致一直沒有付出行動，
細算下來，到目前為止，我從事.Net開發已經差不多八年了，也算是一只見證了.Net從興起到衰落（不知道這么說會不會被打）再到逐漸有復蘇跡象的老鳥了，在這個程序中，帶過團隊，也擔任過架構師（當時為了證明自己并非野路子，2018年還專門拿下了軟考《系統架構設計師》認證），在企業內部Wiki上也寫過不少文章，做過不少技術分享，但畢竟是小群體，文章寫得再爛(甚至只有提綱，或者只字片語，或者只有一張圖)，也可以通過溝通解釋清楚，就算真的寫錯了，也會有很多補救措施，不會產生什么不良影響，而對外發布，對內容的完整性，嚴謹性以及文字組織能力的要求就要高得多，而這正是我不得不花精力填補的短板，
2020年注定是不平凡的一年，對于我們這些.Neter來說更是如此，我不確定能否通過文字完整的出自己的思想，但是我會盡力，希望我的文字不會帶偏你的思路，當然，如果你能贊同我的觀點，并能從中得到一點點啟發，那將是我莫大的榮幸，
好了，閑淡扯完了，進入今天的正題吧！
總體架構
在這里，我準備結合自己的作業經歷和個人理解，針對當前比較火熱的DevOps話題出一個文章系列，但是，在這之前，有必要從整體上梳理一下思路，圈定一下范圍，以保證整體思想的一致，并方便后續文章的展開，
這個系列并沒有涵蓋DevOps的全部內容，例如，沒有包含服務的鏈路追蹤、日志監控、健康檢查等微服務相關的部分，也沒有包括集群和容器的監控、管理、健康檢查、報警等更偏向運維的部分，而是更多的聚焦在CI/CD上，微服務相關的部分后面可能單會獨寫一個系列詳細探討，而運維相關部分則不會過多涉及，即使是K8S容器編排也只會點到為止，因為這部分我自己接觸的也比較少，不敢瞎寫，
概覽
注意，這里的Jenkins并非部署了多套，而是在同一套Jenkins中根據部署環境的不同劃分了多個分組，每個分組有各自不同的權限和功能，
流程說明
- 開發人員每次寫完代碼之后，Push到源代碼倉庫（企業中一定會有自己SVN或者Git等私有倉庫，這是即使沒有DevOps或CI/CD概念也會存在的最基本的基礎設施，我后續會直接使用GitHub，因此不會單獨介紹這部分內容），自動（或者定時輪詢）觸發Jenkins構建，完成Nuget包還原，靜態代碼審查，單元測驗，上傳報告到SonarQube服務器，如果構建失敗，或者代碼審查和單元測驗報告不達標（實際作業中，由于各種原因，這個目標比較難以達到），則反饋開發修復，如果達標則構建鏡像并發布到開發環境的Docker容器中；
- 開發人員功能開發完成，并通過開發環境容器測驗通過后，將Dev分支合并到Master分支，并發送提測通知到測驗人員；
- 測驗人員（可以在分支合并的時候自動觸發，或者定時輪詢）構建Master分支，大體流程跟開發分支相同，不同點就是會發布到盡量貼近生產環境的Docker集群，同時將鏡像Push到Harbor鏡像倉庫；
- 測驗人員測驗通過后，通知運維人員安排上線；
- 運維人員通過手動觸發Jenkins的方式，先從Harbor上Pull對應版本的鏡像，并逐步分階段完成到生產環境Docker集群的部署，
- 剩下的就是生產環境α測驗和β測驗及一系列的監控了，
總結
DevOps更多體現的是一種思路和流程，可能每個團隊做法都不一樣，例如，有的團隊可能在Dev分支上測驗，而在Master分支上構建生產環境鏡像；有的團隊可能因為環境隔離的原因，不得不部署多套Jenkins環境等，但歸根結底目的是一樣的，就是達到全程自動化，減少人力勞動（不知道算不算自己砸自己飯碗）以及各種人力，環境等因素導致出錯的概率，
后續的文章我會按照這個思路展開，如果存在考慮不周，或者可以改進的地方，希望各位大佬們能夠及時指出，大家一起探討，共同進步！
最后，希望.Net生態越來越好！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/6643.html
標籤：其他