### 一、Overview 最近的一段時間，在公司裡我都在進行基於 Jenkins 和 SonarQube 配合已有的 Gitlab 搭建部門的持續整合環境的工作，雖然之前有使用過 GitHub Actions 和 Azure DevOps，但是從頭開始搭建這樣的一套 DevOps 環境還是學習到了一些新的知識點，因此，藉著這個中秋國慶假期的機會，分享下整個工具鏈的搭建過程，如果你也有相似的需求的話，希望可以對你有所幫助 ### 二、Contents 1. [從零開始針對 .NET 應用的 DevOps 運營實踐 - 執行環境搭建](/danvic712/p/build-a-devops-environment-for-the-dotnet-application.html) ### 三、Step by Step #### 3.1、一些概念 DevOps, **Dev**elopment 和 **Op**erations，從名稱上就可以看出，這一名詞包含了軟體的開發與運營。當然，這裡提到的 DevOps 是一種方法論，更多的是為了打破開發與運營人員之間的壁壘，用來促進開發人員、運營人員以及 QA 人員之間的溝通與協作。通過引入 DevOps 中使用的各種工具，我們可以通過自動化的方式，完成軟體系統的構建、測試、釋出，從而降低因人工操作所造成的不確定性，提升軟體的交付速度、系統質量 在踐行 DevOps 方法論時，經常會提到三個概念，持續整合、持續交付、持續部署，這裡藉由 [Redhat](https://www.redhat.com/zh/topics/devops/what-is-ci-cd) 上介紹相關概念的一張圖片來說明三者之間的聯絡  - 持續整合（Continuous Integration）：在傳統的軟體開發過程中，將個人開發的程式碼與整個專案程式碼的合併一般都會置於比較靠後的階段，而持續整合強調的是開發人員提交了新程式碼之後，立刻進行構建、單元測試。根據測試的結果，確定新程式碼和原有程式碼能否正確地整合在一起 - 持續交付（Continuous Delivery）：持續交付是一種自動化的軟體交付手段，在持續整合的基礎上，程式碼庫中的程式碼已經做好了部署到正式環境的準備，在目前的通用做法中，將構建之後的程式碼通過持續交付變更部署到測試環境、預釋出環境中，實現對持續整合的擴充套件，出於業務方面的考慮，我們可以手動選擇是否部署到正式環境 - 持續部署（Continuous Deployment）：作為對持續交付的延伸，持續部署能夠自動的將最終的程式碼部署到生產環境中，完成整個的 CI/CD 流程 雖然目前的需求僅僅是為了實現持續整合，完成對於系統的自動化程式碼檢查、自動化單元測試，但是因為後續的功能對於我們完整的實施 DevOps 方法論也是必須的，所以在這幾篇的部落格內容中，我也會完成對於後續功能的實踐分享 #### 3.2、前期調研 與持續整合的場景存在一些的差異，我們在實際的開發中，並不會在新的功能分支上按照每個開發人員再建立單獨的分支，因此，這裡的持續整合更多的想要實現的是當開發人員提交程式碼到 Gitlab 時，自動觸發程式碼檢查以及單元測試，產出程式碼檢查報告、單元測試報告、以及整個專案的測試覆蓋率 因此，基於目前的需求，整個系統主要依賴於三個主要的軟體系統，Gitlab、Jenkins、以及 SonarQube，當然，這裡缺少了一個 bug 管理工具，因為我們部門人數不是很多，目前是和別的部門共用的 Redmine 進行的專案管理，所以本次並沒有納入到我們的需求範圍內，當然， bug 管理也是推行 DevOps 中不可缺少的一部分 在挑選元件時，本著不給自己和別人挖坑的原則，優先考慮使用人數多的軟體系統。因此，作為事實上的開源 CI/CD 工具的標準，毫無疑問選擇 Jenkins，而對於程式碼的自動化檢查，結合我們需要實現私有化部署，滿足對多種開發語言的支援、能夠與 CI/CD 工具進行有效結合的需求，這裡最終選擇的是 SonarQube 由於歷史原因，部門系統的框架版本橫跨了 VB.NET、.NET Framework 2.x，4.x 與 .NET Core，.NET 框架的程式涵蓋了 Web Form、MVC、Web API，排除掉已經不維護的系統，最終需求的範圍限定在支援 .NET Framework 4.x+ 以及 .NET Core 程式上。因此，這裡只能選擇將 Jenkins 和 SonarQube 部署到 Windows 伺服器上，如果你不需要相容 .NET Framework 的程式，推薦你部署到 Linux 伺服器上 在選定好使用的軟體後，就需要完成環境的配置，Jenkins 與 SonarQube 都是基於 Java 的軟體，因此在安裝軟體之前，需要我們在伺服器上完成 Java 環境的配置，同時，基於我們的系統現狀，需要在伺服器上安裝好 .NET Framework、.NET Core、Git 以及 Node 對於 Git、Node、.NET SDK 的安裝，下載安裝包後，一直 next 即可，加上這裡主要針對的是 .NET 程式設計師，以及我們的伺服器是斷網的，所以這裡主要列舉的是兩個相對來說稍微複雜的環境配置，一個是對於 MSBuild 工具的離線下載，另一個則是 Java 環境的配置 #### 3.3、MSBuild 安裝 因為在整個過程中會涉及到對應用程式的編譯生成，對於 .NET Core 應用，完全可以採用 .NET Core CLI 中的各種命令來實現，而對於 .NET Framework 程式來說，則需要一個執行應用程式生產的平臺，MSBuild 就是這樣的一個工具，我們在開發過程中使用 Visual Studio 進行程式編譯時，其實也是會借用 MSBuild 來進行的 因此，最簡單的辦法，就是在伺服器上安裝 VS 即可，當然，這個過於簡單粗暴了，以及在伺服器上安裝我們開發使用的 IDE 也過於浪費，所以這裡還是會選擇獨立的安裝 MSBuild 與 VS 相似，MSBuild 也有不同的版本，為了避免一些莫名其妙的問題，在 MSBuild 的版本選擇上，最好選擇與你們開發時用的 VS 匹配的版本，因為我們在開發中會使用到了 VS 2017 和 VS 2019 這兩個版本，所以這裡我會安裝兩個 MSBuild 到伺服器上 對於 MSBuild，之前很多文章中說可以直接把你本地電腦中的 VS 所包含的 MSBuild，丟到伺服器上就可以了，經過我的多次嘗試，在踩坑的路上越走越遠，這裡還是建議你通過 Visual Studio Build Tools 進行安裝 在 VS 的下載頁面，這裡是以 VS 2019 的下載頁面進行示例，在 Visual Studio 2019 工具這個內容塊中，找到生成工具這個下載項，下載即可  這裡你可以直接通過我給出的這兩個地址，直接下載對應的生成工具，開啟軟體，找到 MSBuild 這個元件進行安裝即可 - Visual Studio 2017 Build Tools：https://visualstudio.microsoft.com/zh-hans/thank-you-downloading-visual-studio/?sku=BuildTools&rel=15 - Visual Studio 2019 Build Tools：https://visualstudio.microsoft.com/zh-hans/thank-you-downloading-visual-studio/?sku=BuildTools&rel=16 當然，這個下載完成的也只是一個線上安裝包，還是需要連線網路進行下載的，如果你們的伺服器也是沒有連線外網許可權的話，這裡需要換個方式 對於離線安裝，找到下載後的安裝器所在的路徑，開啟 CMD，輸入下面的命令，即可按需下載需要的元件到指定的位置，例如這裡我是將下載好的檔案放在我桌面上的 msbuild 資料夾下的 offline 資料夾中 ```shell vs_buildtools.exe --layout C:\Users\danvi\Desktop\msbuild\offline --add Microsoft.VisualStudio.Workload.MSBuildTools --add Microsoft.VisualStudio.Workload.WebBuildTools --lang zh-CN ``` 整個命令包含了三個部分的內容 - `--layout`：指定離線安裝檔案所在的路徑 - `--add`：指定需要下載的元件，因為我們的系統是 Web 專案，為了防止在 MSBuild 中生成出錯，所以這裡除了 MSBuild 還需要下載了一個 WebBuildTools - `--lang`：指定安裝包的語言  同新版本的 VS 的安裝一樣，當我們輸入命令之後，會開啟如下的頁面，等待安裝器的下載完成即可  當下載器安裝完成後，會自動彈出一個新的控制檯頁面，坐和放寬，此時已經開始自動下載我們需要的元件，當全部元件下載完成時，按照提示的內容關閉彈出的頁面即可  找到你所指定的下載路徑，將整個資料夾拷貝到伺服器上，然後點選 vs_buildtools.exe 進行安裝，具體安裝的元件則可以通過右側的安裝詳細資訊進行檢視，如果你在使用中發現缺少你需要的，按照上面的方法新增新的引數即可  #### 3.4、Java 環境配置 因為 Jenkins 與 SonarQube 均是 Java 程式，並且 SonarQube 對 Java SDK 的版本有具體的要求，這裡我選擇的是 OpenJDK 11，你可以從此處（[https://jdk.java.net/archive/](https://jdk.java.net/archive/)） 獲取到 OpenJDK 的各個發行版本  與 .NET SDK 不同，在習慣了一路 next 就可以安裝各種的操作後，在安裝 OpenJDK 時，需要手動的將 SDK 的路徑以及相關的環境變數新增到作業系統中 解壓下載完成的壓縮包到指定的路徑，例如這裡我的路徑是 `E:\sdk\jdk-11.0.2`，此時我們需要對環境變數進行配置，從而確保 Java 環境的正確安裝 右擊我的電腦，選擇屬性，開啟系統資訊頁面，點選右側的高階系統設定，開啟系統屬性彈窗，當然，你也可以通過 Windows 10 的搜尋直接搜尋環境變數關鍵字找到這個頁面  點選環境變數按鈕，在系統變數的類別下，我們執行如下的三步操作 - 新建系統環境變數 JAVA_HOME，變數值為解壓後的 OpenJDK 所在的路徑，例如我這裡配置的 `E:\sdk\jdk-11.0.2`  - 新建系統環境變數值 CLASS_PATH，具體對應的值為 `%Java_Home%\lib;`  - 修改已經存在的 PATH 變數，將 `%JAVA_HOME%\bin` 新增到環境變數中  至此，針對 Java 的環境配置已經完成，此時為了避免一些奇怪的錯誤，建議你重啟下電腦。在重啟之後，可以通過 `java --version` 命令來檢視是否已經配置成功，如果如下圖一樣可以顯示出 Java 的版本資訊，則代表 Java 環境已經配置成功  #### 3.5、總結 自此，目前使用到的軟體所需的環境就已經安裝配置完成了，在下一篇中就可以安裝我們主要使用到的兩個軟體 Jenkins 和 SonarQube，從而配合我們已經存在的 Gitlab，構建自己的 CI/CD 服務 ### 四、References - [在攜程，我們如何實踐 DevOps](https://www.infoq.cn/article/wNOeM38OZVc1ITeB9bwU) - [The Product Managers’ Guide to Continuous Delivery and DevOps](https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/) - [CI/CD是什麼？如何理解持續整合、持續交付和持續部署](https://www.redhat.com/zh/topics/devops/what-i