【壹个小技巧】一看就会的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)。

比如说，用空格表示代码块，然后用 - 表示数组，用 : 来表示键值对操作等等。

相应的代码操作：注意这里有一个错误，我故意这么写就是为了暴漏这个错误：

name: .NET Core
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

就比如我的是这样的：

[![Build status](https://github.com/anjoy8/blog.core/workflows/.NET%20Core/badge.svg)]()

最终的展示效果：

是不是又简单又很方便的！而且我们点击这个徽章，还可以看到之前的提交记录和详细日志：

只有这么多了么？

当然不是，Github Actions 还有很多很多的内容，值得我们去学习和研究，比如这些：

本文也仅仅是一个小技巧，详细在微软的带领下，Github也会越来越好！

更多精彩小技巧，欢迎联系我哟。

???? 这里是 Github Actions 官网地址