前两天有朋友问我，微软的Azure好用吗，适不适合国人的使用习惯，我就跟他讲了下，Azue很好用，这也是为什么微软云营收一直涨涨涨的原因，基本可以再1个小时内实现自动化构建、打包以及部署到Azure服务器上。利用周末的时间，写了这篇文章，分享给大家，希望能帮助一些人快速入手如何使用Azure DevOps自动化构建、测试以及部署自己的服务。
今天，我给大家一步一步详细介绍，如何在1个小时内，创建一个Web API项目，实现服务的自动化构建、打包，并自动化部署到Azure上。
1. 创建一个Azure托管存储库 （Organization）
第一步，需要在Azure DevOps (https://dev.azure.com/)上创建一个组织团体（Organization)。
Organization可以理解为是一个公司（或者一个事业群）或某个机构的所有数据的统一存储库，微软称之为托管存储库。
Host 项目的地区选择一个最近的区域最好，减少网络延迟。
2. 创建一个新的Azure DevOps项目（Project）
Azure DevOps Project 一般是一个大组或者一个大的周期内共同使用的一个数据及代码集合。你在创建项目时，可以设置项目名称以及项目具体的介绍；也可以选择项目的可见性，可以设置为公开的或者私有的。版本控制可以选择默认的Git。
其他选项（例如，工作项处理的模板等），有兴趣的可以自己研究，这里不做重点介绍。
3. 创建一个新的代码仓库(Repository）
Repository 顾名思义就是存放代码的地方， 一个Repo 可以有很多个分支，一般默认为master分支。
在这里，我们创建一个名叫AzureWebApps的Repository，并且假设我们以VisualStudio为IDE，选择VisualStudio .ignore 文件模板。.ignore 文件里配置了那些我们纳入Git管理的文件。
4. 创建我们的Web API项目，并进行修改。
4.1 克隆代码到本地
我们先把上面创建的AzureWebApps Repo 克隆到本地，方便在本地对代码进行增删改。Azure DevOps 本身也提供了在线编辑Git Repo，一般一些微小的改动可以直接在线修改。
打开Visual Studio，连接到我们的托管存储库，并定位到我们所创建的代码仓库（AzureWebApps)，点击“克隆”即可。
（你本机如未安装Git，请自行到Git官网安装Git，后面会用到。）
4.2 创建HelloAzure API网站。
接下来，我们在VS里来创建一个Web API project。
新建项目模板时，我们选择“Asp.Net Core Web 应用程序”模板，如下：
然后下一步，我们选择API的ASP.NET Core Web API:
当我们创建完项目后，默认的API Project是一个随机返回天气预报信息的API。 我们可以任意修好一些配置，如端口，打包输出位置，对象类型及属性等。我在这里简单加了一个Source 属性给WeatherForecase.cs.
5. 创建一个构建管道（Build Pipeline）
此构建管道（Build Pipeline）的作用就是：每当我们有代码更新（Push）到远程master分支时，它会自动用来自动构建，（自动测试，这里略过），自动打包生成Artifacts 供后面自动部署管道使用。
5.1 创建构建管道 （BuildAndPublishHelloAzure)
我们在Pipelines 页面，新建一个Pipeline， 并选择连接到“Azure Repos Git” 作为代码仓库位置，如下图：
接着，选择我们上面存放代码的代码仓库(Repository) - AzureWebApps:
接下来，我们来进行初始化配置我们的构建管道（Build Pipeline）。我们给他配置上一个默认的任务（Task）- ASP.Net Core (.NET Framework) ， 此Task 会利用VS Build来自动编译.sln 及 .csproj的项目。
这里我简单介绍下，Azure的一个Pipeline 一般是包含多个任务（Task）， 每个任务（Task）是一个最小的运行单元。Azure 市场（Market place）上有很多现成的task 模板可以供咱们直接使用，只需简单的配置一些参数即可。
因为我们需要把编译构建HelloAzure的结果包发布到Azure上的某个地方，因此我们需要给我们的Build Pipeline 加一个任务 Publish build artifacts （直接在搜索框里搜‘publish build’）：
Publish build artifacts 任务有三个参数，我们保持默认就可以。 请注意，其中Artifact name （drop） 在后面配置部署管道时会用到。
点击添加完后，咱们就会在左边的YAML Settings 里看到我们新加的这个任务的设置了，如果需要的话，可以进行修改。最后我们保存我们配置好的构建管道。
保存后，我们可以把我们的管道重命名成一个更有意义的名字，如 BuildAndPublishHelloAzure :
5.2 配置自动化（持续性）构建
构建管道创建好了，接下来我们需要给我们的Repository配置如何自动化构建。
我们的需求是，如果master 分支有代码更新（包括新建Pull Request， Complete Code/Push），那么就自动运行我们BuildAndPublishHelloAzure Pipeline。
首先我们在分支页面，找到Master 分支的分支策略管理页面，添加一个构建策略：
新建的构建策略的配置页面，触发一项我们选”Automatic“，这样每当有新的PullRequest 创建时，就会自动绑定此BuildAndPublishHelloAzure Pipeline 进行编译，构建，跑单元测试等。
最后，我们需要在配置，当有代码check in （PullRequest Complete）后，也自动运行这个build Pipeline。
在BuildAndPublishHelloAzure 编辑页面，跳到Triggers（触发器）这个配置tab页面，我们勾上并选中“Enable continuous integration” 即可，一般我们只需要对特定的一些分支设置持续性集成构建测试，所以我这里也只设置了master 分支。
到此，自动化的持续性集成构建 （测试）及打包已经完成了。
6. 在Azure上创建一个Web APP （Web API） 网站
6.1 创建Azure订阅（Subscription）
在创建Web 网站之前，我们需要创建一个Azure 订阅（Subscription，Azure用来收费的账户，如果你已经有了，可跳过）。登录www.azure.com， 用微软账户登录，在门户页面创建一个subscription，如下：
6.2 创建HelloAzure Web API Application
在Azure Portal （门户）的搜索框里搜”Api app“， 就回出来 API App 的一个创建模板，点击它开始创建：
配置好你的网站名字 - JasonHelloAzure，并选择上一步创建的订阅（Azure subsciption - Jason Test) ，其他默认即可。
接下来我们将介绍如果将自动化构建生成好的包部署到我们创建的这个API 网站（JasonHelloAzure)上。
7. 创建一个发布管道（Release Pipeline）
此发布管道（Release Pipeline）的作用就是：每当我们有代码更新（Push）后并已经打包好后，此管道会自动将构建管道生成的Artifacts 自动部署到Azure Web App (JasonHelloAzure)。
7.1 创建发布管道HelloAzureReleasePipeline
我们在Releases 频道，新建一个Release Pipeline， 并选择连接到“Azure Repos Git” 作为代码仓库位置，如下
新建是，会弹出来让你选择一个模板（如下图），我们这可以选择”Azure App Service deployment“， 这个模板适用于所有Azure Web app及其他一些app （如containers 部署，Azure Function apps等）：
现在我们来给这个部署管道设置部署的来源，点击Artifacs这个模块，在右边会弹出来配置的页面：
Project 就是我们第二不创建的项目，也是存放我们创建的构建管道的地方。
Source （build pipeline），选择我们创建的BuildAndPublishHelloAzure 管道。
默认版本（Default Vesion），选择Latest即可，意思是每当上面的BuildAndPublishHelloAzure管道的最新发布的包。
Source alias， 就是包名的意思，在配置BuildAndPublishHelloAzure构建管道时，有一步配置Artifacts name 配置的就是 "drop”， 这里只需前后配置一致即可，任意字符串都可以。
7.2 配置自动化持续性部署
现在我们来给部署管道配置持续性部署触发（Continuous deployment trigger)， 这个意味着，每当有新的artifacts 包生成时，就自动触发这个部署管道进行部署。
点击Artifacts 模块里的那个小闪电button， 右边就会出来持续性部署触发器的配置页面。
选择一个master 分支，启用Continue deployment trigger， 如下图：
最后一步，我们来配置部署管道要部署的目的地，也就是配置到我们上面创建好的Azure API App （JasonHelloAzure)。
一个部署管道也跟构建管道类似，区别是他包含多个阶段（Stage），一个阶段又包含任务（Task）。
点击任务选项组（Tasks），在右边的配置页里，填好阶段名称，选择订阅名称（Azure subscription - Jason Test)。
App type, 由于我们创建的是API App，自然选择API App， 选了API App 后，最后的App service name下拉框就会出现所有该订阅下面的API App， 我们选择JasonHelloAzure及可。
Deploy Azure App Service 任务的配置，我们保持默认即可。
8. 测试结果与总结
8.1 效果展示
我们直接先手动运行下创建好的“HelloAzureReleasePipeline”部署管道，然后访问JasonHelloAzure API 网站，如下：
最后，我们来试试自动化部署，看看效果（成果）哈 ：）
我们创建一个Pull Request， 那么自动跑我们配置好的CodeBuild Policy （其实就是跑BuildAndPublishHelloAzure Pipeline)
当Pull Request Complete 后， 会自动跑持续性构建管道，以及部署管道：
约3分钟后，部署完成，再次访问JasonHelloAzure API: https://jasonhelloazure.azurewebsites.net/weatherforecast , 结果已经更新：
希望对想用Azure DevOps 对自己的服务做自动化CI/CD的人有帮助。
本文没有重点介绍测试部分，可以直接给HelloAzure创建一个UnitTest Project，BuildAndPublishPipelline 可以增加一个跑单元测试的任务即可以实现自动化构建+测试了。
8.2 总结
Azure DevOps 整体还是很人性好的，在易用性和可扩展性方面确实做的不错。对于一些中小企业，还是一个不错的选择，可以让研发人员专注于业务逻辑，省去了一些CI/CD的繁杂琐事。微软Azure部门可以说是最具有互联网基因的事业群了，Azure的产品同时也有了互联网的敏捷性和易用性，这也是微软股价持续新高，被华尔街看好的原因。