Azure DevOps 持续集成（一）：初步

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。这些更深入的我将会在接下来的几篇文章里都一一讲解。

---

个人公众号，欢迎关注。天天更新是不可能的，这辈子都不可能天天更新。只有心情好的时候更新一下这样子才维持的了生活。