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