什么是 CI/CD?我这里先不说概念,先说一个平时开发的场景问题:
当然,我们这里不说平时公司的正规方案,肯定是一大推的集成方案。咱们就说一下平时自己是如何做的: 基本都是本地调试调试看看,或者是F6运行一下,然后提交,提交的时候,还不敢保证和本地的一样,可能拷贝的时候拷贝错了,或者少拷贝了一两个,然后就很尴尬。 那这个时候,如果有一个 Job 能够自动的将我们每次提交的代码做自动化编译,然后它自己进行测试,最后甚至可以自己去部署,嗯,就很美啦! 还真有!那这个时候就来说说常见的方案 —— 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:
就比如我的是这样的: [![Build status](https://github.com/anjoy8/blog.core/workflows/.NET%20Core/badge.svg)]() 最终的展示效果: 是不是又简单又很方便的!而且我们点击这个徽章,还可以看到之前的提交记录和详细日志: 只有这么多了么?当然不是,Github Actions 还有很多很多的内容,值得我们去学习和研究,比如这些: 本文也仅仅是一个小技巧,详细在微软的带领下,Github也会越来越好! |
|