【壹个小技巧】一看就会的CI/CD ：Github Actions
什么是 CI/CD?
我這里先不說概念，先說一個平時開發(fā)的場景問題：
我們平時開發(fā)一個項目，經(jīng)常會遇到這些“小”問題：
就是如何保證自己的項目是正確的，至少拿給別人的時候，可以編譯運行的？
或者說多人開發(fā)的時候，如何保證提交沒有編譯沖突？
或者如何做到快速自動化測試？
最后又是如何在服務(wù)器自動化部署的呢？
當(dāng)然，我們這里不說平時公司的正規(guī)方案，肯定是一大推的集成方案。咱們就說一下平時自己是如何做的：
基本都是本地調(diào)試調(diào)試看看，或者是F6運行一下，然后提交，提交的時候，還不敢保證和本地的一樣，可能拷貝的時候拷貝錯了，或者少拷貝了一兩個，然后就很尷尬。
那這個時候，如果有一個 Job 能夠自動的將我們每次提交的代碼做自動化編譯，然后它自己進行測試，最后甚至可以自己去部署，嗯，就很美啦！
還真有！那這個時候就來說說常見的方案?—— CI/CD
CI/CD 是一種通過在應(yīng)用開發(fā)階段引入自動化來頻繁向客戶交付應(yīng)用的方法。CI/CD 的核心概念是持續(xù)集成、持續(xù)交付和持續(xù)部署。作為一個面向開發(fā)和運營團隊的解決方案，CI/CD 主要針對在集成新代碼時所引發(fā)的問題。
具體而言，CI/CD 在整個應(yīng)用生命周期內(nèi)（從集成和測試階段，到交付和部署）引入了持續(xù)自動化和持續(xù)監(jiān)控。這些關(guān)聯(lián)的事務(wù)通常被統(tǒng)稱為“CI/CD 管道”，由開發(fā)和運維團隊以敏捷方式協(xié)同支持。
?? ? ? ? ? ? —— 資料來源于網(wǎng)上
它有以下幾點好處：
持續(xù)集成、持續(xù)交付、持續(xù)部署、持續(xù)測試。
這個時候，你可能你會說，『媽耶，你今天不會講這個吧，這么復(fù)雜，就算是明白了，我自己平時開發(fā)肯定用不到呀，甚至說自己開發(fā)很難去搞這么多東西，我平時只有 Github 一個代碼管理，這么復(fù)雜，肯定搞不定』，沒關(guān)系！我們在 Github 上也可以簡單的實現(xiàn) CI/CD 操作。
Github 上如何進行 CI/CD 的操作？
我的 Blog.Core 項目在 Github 上也開源了一年多了，目前效果基本還行，每天少不了的就是被各種問：
群主，你的項目沒有調(diào)試么？我本地下載下來都編譯不通過？！
群主，你的項目能直接在服務(wù)器上部署么，我拷貝了發(fā)現(xiàn)運行不起來？！
等等，諸如此類。
后來我沒辦法了，就在Github上增加了一個第三方的插件—— Appveyor?，來簡單的實現(xiàn)了?CI/CD?操作，通過注冊賬號，然后各種配置以后，可以實現(xiàn)，每次向 Github 提交，會自動編譯，然后生成報告，而且他們第三方還提供了一個徽章，可以放到 README 里，很貼心，一直用著，（如果你也想用這個，可以留言，或者群里問我，我寫個小步驟，或者自己網(wǎng)上隨便百度百度吧，很簡單，因為我以后不用這個了，具體看下文?????）
但是，就在今天，我再提交代碼的時候，發(fā)現(xiàn)爆紅了，心情瞬間不爽：
這個肯定不是代碼的問題，因為我都沒有修改代碼，怎么辦呢，查看日志吧，這個不重要就不說了，反正就是說 Appveyor 地址什么的無法訪問了，行吧，那我就不用你啦！
正在考慮是否要放棄的時候，想起來之前 Github 官方發(fā)的一個郵件：
大概意思是說，Github 官方將在十一月13號以后新增兩個功能，其中一個就是 Github Actions，可以支持CI/CD了，哇塞！自家的東西，肯定想用，而且也是微軟搞的，那要試一試！
使用 Github?Actions 實現(xiàn)CI/CD
這個過程其實就很簡單了，畢竟 Github 的操作都很人性化的，我們來快速的操作一遍，可以看我下邊的步驟，當(dāng)然可以看官網(wǎng)地址
https://help.github.com/cn/actions/automating-your-workflow-with-github-actions/about-continuous-integration），很人性化的提供了中文翻譯：
1、打開我們的 Github 項目，在頂部有一個 Actions 的banner。
2、點擊進去，會自動根據(jù)項目的內(nèi)容，進行判斷，找到合適的 Workflow 模板。因為我的項目的 NetCore 的，所以這里自動會給我們匹配 .NET Core 的workflow，如果你是其他項目，比如Java、python等，會有不同，當(dāng)然我們自己也可以自定義模板。
3、點擊 Set?up this workflow ，可以看到已經(jīng)有一些 yml 代碼了，這個是 YAML 語法，感興趣的自己研究下，學(xué)會基本的就行了，官方的學(xué)習(xí)地址：
(https://help.github.com/cn/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)。
比如說，用空格表示代碼塊，然后用 - 表示數(shù)組，用 :?來表示鍵值對操作等等。
相應(yīng)的代碼操作：注意這里有一個錯誤，我故意這么寫就是為了暴漏這個錯誤：
on: [push]
jobs: build:
runs-on: ubuntu-latest
steps: - uses: actions/checkout@v1 - name: Setup .NET Core uses: actions/setup-dotnet@v1 with: dotnet-version: 2.2.108 - name: Build with dotnet run: dotnet build --configuration Release
4、直接將這個文件 submit，可以看到會在 .github 下的 workflows 文件夾下，生成一個dotnetcore.yml 文件。
與此同時，我們的項目已經(jīng)正式的在后臺進行自動編譯了，目前是過程中，黃色的圓點：
5、剛剛我說過了，上邊官方給我們默認(rèn)的 workflow 模板有一個錯誤，也不是錯誤，就是不太合適的地方，會報錯，但是，會有很詳細的日志報告，我們來看看：
相信每一個只要開發(fā)過 netcore 的都知道這個錯誤，沒錯！就是 SDK 的版本不一致導(dǎo)致的，我們只需要改一下那個 .yml 文件中的 dotnet 版本就行了，不懂的請回看。
版本改成 3.0.100 即可。
6、如果Build失敗，會通過郵件提醒。
我認(rèn)為這個特別合理，因為之前用第三方的時候，比如Appveroy，是沒有提醒功能的，我們push到Github的時候，只能慢慢的等待，看日志了。但是 Github Actions 提供了發(fā)送錯誤日志的功能：
7、最后可以看到綠色的成功的標(biāo)志，也會有編譯列表！
是不是很方便！而且里邊有很詳細的日志文檔，可以提供一個月，我們可以下載和查看，我們項目中的警告等，也會列出來，很方便：
可以來一個小徽章
上邊咱們說完了，但是總感覺少點兒什么，沒錯，就是沒辦法實時在 README 頁面里，查看編譯狀態(tài)，GitHub 也想到啦，他們提供了一個徽章api：
https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_NAME>/badge.svg就比如我的是這樣的：
最終的展示效果：
是不是又簡單又很方便的！而且我們點擊這個徽章，還可以看到之前的提交記錄和詳細日志：
只有這么多了么？
當(dāng)然不是，Github Actions 還有很多很多的內(nèi)容，值得我們?nèi)W(xué)習(xí)和研究，比如這些：
本文也僅僅是一個小技巧，詳細在微軟的帶領(lǐng)下，Github也會越來越好！
更多精彩小技巧，歡迎聯(lián)系我喲。
???? 這里是 Github Actions 官網(wǎng)地址
總結(jié)
以上是生活随笔為你收集整理的【壹个小技巧】一看就会的CI/CD ：Github Actions的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： GitHub Actions，卧槽！牛批
- 下一篇： Hyper-V虚拟机自动添加检查点和导出