Azure DevOps CI/CD（一）：初步
CI/CD
看到這篇文章的你應該已經對CI/CD已經有一個比較大概的印象，所以在這裏我也就大概的說一下概念性的東西就OK了。隨着現在軟件工程，互聯網的發展，軟件的規模，架構，面對的業務場景等都越來越複雜，用戶對軟件服務的要求也越來越高。因此軟件也必須得用更快的速度去編碼，構建，測試。
CI（持續集成Continuous Integration）簡單理解就是程序員提交代碼後立即進行構建，測試。可以通過構建測試的結果看到代碼是否可以跟原代碼集成合並。
CD（持續部署Continuous Delivery）也叫持續交付，持續部署在持續集成的基礎上把構建，測試通過的代碼打包部署到內部測試環境或者正式的環境中。
有了CI/CD我們就可以更專注於業務代碼的編寫，實現提交代碼自動構建，測試，部署，然後就能在線上環境看到自己的更改了。
Azure DevOps
Azure DevOps對開源項目免費開放，可謂是個人開發者的福音
一些基礎的介紹就到這了，這篇文章主要是給大家介紹微軟的Azure DevOps工具，雖然在國內的互聯網大環境黑微軟就是政治正確，但是這並不能否認Azure DevOps本身是一款出色的CI/CD工具。
當時我主要是想要找一款CI/CD的工具，用過Appveyor和TravisCi但是都因爲各自的編譯環境問題需要配合一起來使用，Jenkins又需要安裝配置較麻煩。最後找到了Azure DevOps直接在網頁就能完成操作，當時聽說開源項目免費就馬上在自己的項目用起來。然後就離不開了，當然微軟自家的東西跟dotnet core框架和Azure雲服務的集成度肯定會更高，也更好。看VS IDE就知道微軟全家桶有多香。
Azure DevOps也不單止對自己的框架和服務適用，對java，node.js，python，webpack，docker，k8s，Azure雲服務等都有很好的支持。在Azure DevOps中每一個步驟執行的動作都是由插件來執行，也就是說我們也可以開發自己的插件來執行自己希望的CI/CD過程，並且發佈出來給更多人使用。
開始使用Azure DevOps
本文章暫時只講解持續集成，持續部署的在第二篇文章進行講解
下面我們就來開始使用Azure DevOps來幫我們完成CI的工作。
首先登陸Azure DevOps官網可以使用github賬號登陸。
然後就來到了主頁，我這裏因爲之前已經有些項目是已經集成了Azure DevOps所以界面上面就有很多的項目，如果是剛開始使用的這個界面就是一片空白，只有左邊的組織，剛註冊都是默認有一個組織。
廢話不多說，如何把我們github或者在其他源碼管理器的代碼跟Azure DevOps集成來完成CI/CD呢？
新建項目
點擊主頁的右上角藍色圖標New project。
點開後可以看到屏幕右邊有一個Create new project的彈窗，輸入一個項目名稱，隨意就好不一定要跟github上面的項目名稱一樣的。
在Visibility中選擇Public開源項目，然後點擊Create，完成後就會看到下面的界面：
左邊欄是Azure DevOps的重要組成部分，有Boards，Repos，Pipelines，Test Plans，Artifacts。其中的Pipelines(管道)將是我們接下來用得最多，最最重要的部分。
添加管道
在這過程中可能有很多不理解的地方，沒關係跟着做就好了。在後面我會解釋這些概念性的問題。
鼠標移動到左邊欄的Pipelines中，在二級菜單中選擇Pipelines，如下圖：
然後在新的頁面中點擊Create Pipeline：
接着就會來到下面這個界面：
這裏對應選擇就行了，我是用的github項目，所以我在這裏就選擇github。
這裏就會列出你github上面所有的項目，這裏選擇隨便選擇一個然後繼續下一步。
上面需要在github中授權一下，然後就會返回到Azure DevOps中繼續下一步配置了。Azure DevOps會自動分析項目結構，然後找到最適合的項目構建，測試配置。由於我這裏的項目是一個asp.net core用例項目和C#類庫項目，所以分析結果就像下圖：
由於我項目主要還是類庫項目，asp.net core只是用來測試一些庫。所以我這裏是選擇的.NET Desktop配置。
選擇後就會跳到預覽界面，預覽剛剛選擇的配置的配置文件，如下圖：
代碼項目和Azure DevOps集成後會在根目錄生成一個azure-pipelines.yml文件，這個文件就是現在要預覽的代碼。
可以看到右邊那個列表，那個列表就是插件，Azure DevOps中有非常多的插件，大到對代碼的構建，測試，部署用插件，小到複製，移動文件，解壓文件用插件。SSH連接也是用插件。
讓我們一起來看看上圖的代碼做了些什麼工作。
-
trigger：在master分支上設置觸發器，當master分支提交時出發這個腳本 -
pool：設置一個windows的鏡像 -
variables：設置方便下面操作的變量 -
steps：步驟 -
task：task是在steps裏面，一個steps可以有多個task，每個task按順序執行。
上圖的task首先安裝一個nuget工具爲還原做準備，然後使用nuget還原*.sln解決方案（項目），然後用vs build構建項目，最後使用vs test來搜索測試項目並運行測試。
上面的task其實可以理解爲最小單元了，在上面自動生成的yml文件中每個的task其實我們也是可以在右邊的插件欄去搜索關鍵字VS來找到，並完成配置，並添加到yml配置文件中，所有這些操作都是可以在可視化的界面下去進行的，所以非常的友好。yml預覽只是給我們更精確的控制腳本而已，更多時候都是通過圖形化的搜索插件，配置並自動添加插件到yml文件來完成。
檢查沒問題過後就可以按右上角的Save and run按鈕，彈出下面的窗口：
Azure DevOps有兩種方式添加azure-pipelines.yml文件到我們的項目中，一種是直接提交到master分支，另一種是創建一個新的分支以手動PR或者自動PR的方式來添加。這裏看個人喜好，如果不想污染master就創建新分支，在新分支測試沒問題後再PR到master。
我個人是選擇了創建新分支，然後Save and run。
然後在左邊欄Pipelines裏可以看到剛新建的管道了，並且管道已經在自動運行，點擊進去就能看到實時的運行日誌
當全部任務都綠色打勾就是執行成功了，構建成功後你會收到一封構建成功的郵件，裏面有詳細的構建信息。如果中間任何一個任務出現錯誤整個構建將會中止並且會通過註冊的郵件通知你。
總結
到這裏CI的過程就結束了，這篇文章只能夠說作爲一個Hello World式的講解，我們也還沒對自動生成的CI腳本進行任何的修改，也沒有對構建後進行打包，更沒有進行CD。這些更深入的我將會在接下來的幾篇文章裏都一一講解。
個人公衆號，歡迎關注。天天更新是不可能的，這輩子都不可能天天更新。只有心情好的時候更新一下這樣子才維持的了生活。
