Following up on my post last week on moving from App Service on Windows to App Service on Linux, I wanted to make sure I had a clean CI/CD (Continuous Integration/Continuous Deployment) pipeline for all my sites. I'm using Azure DevOps because it's basically free. You get 1800 build minutes a month FREE and I'm not even close to using it with three occasionally-updated sites building on it.
在上周发布有关从Windows上的App Service转移到Linux上的App Service的帖子之后，我想确保我所有站点的CI / CD(连续集成/连续部署)管道都干净。 我正在使用Azure DevOps，因为它基本上是免费的。 您每月可以免费获得1800个构建分钟，并且我甚至无法将其与三个偶尔更新的站点一起使用。
Last Post: I updated one of my websites from ASP.NET Core 2.2 to the latest LTS (Long Term Support) version of ASP.NET Core 3.1 this week. I want to do the same with my podcast site AND move it to Linux at the same time. Azure App Service for Linux has some very good pricing and allowed me to move over to a Premium v2 plan from Standard which gives me double the memory at 35% off.
上一篇文章：本周我将自己的网站从ASP.NET Core 2.2更新到了ASP.NET Core 3.1的最新LTS(长期支持)版本。 我想对我的播客站点做同样的事情，并将其同时移至Linux。 适用于Linux的Azure应用服务的价格非常优惠，使我可以从Standard转到Premium v2计划，这使我的内存减少了35％，增加了一倍。
Setting up on Azure DevOps is easy and just like signing up for Azure you'll use your Microsoft ID. Mine is my gmail/gsuite, in fact. You can also login with GitHub creds. It's also nice if your project makes NuGet packages as there's an integrated NuGet Server that others can consume libraries from downstream before (if) you publish them publicly.
在Azure DevOps上进行设置非常容易，就像注册Azure一样，您将使用Microsoft ID。 实际上，我是我的gmail / gsuite。 您也可以使用GitHub凭据登录。 如果您的项目制作NuGet软件包也很好，因为有一个集成的NuGet服务器，其他人可以在下游(如果您)公开发布之前从下游使用库。
I set up one of my sites with Azure DevOps a while back in about an hour using their visual drag and drop Pipeline system which looked like this:
大约一个小时后，我使用Azure DevOps使用其可视化的拖放管道系统建立了一个站点，如下所示：
There's some controversy as some folks REALLY like the "classic" pipeline while others like the YAML (Yet Another Markup Language, IMHO) style. YAML doesn't have all the features of the original pipeline yet, but it's close. It's primary advantage is that the pipeline definition exists as a single .YAML file and can be checked-in with your source code. That way someone (you, whomever) could import your GitHub or DevOps Git repository and it includes everything it needs to build and optionally deploy the app.
有些人确实喜欢“经典”管道，而有些人喜欢YAML(即另一种标记语言，恕我直言)风格，这引起了争议。 YAML还没有原始管道的所有功能，但是已经接近了。 它的主要优点是管道定义作为单个.YAML文件存在，并且可以使用源代码进行检入。 这样，某人(无论您是谁)都可以导入GitHub或DevOps Git存储库，其中包括构建和可选部署应用程序所需的一切。
The Azure DevOps team is one of the most organized and transparent teams with a published roadmap that's super detailed and they announce their sprint numbers in the app itself as it's updated which is pretty cool.
Azure DevOps团队是组织最完善，最透明的团队之一，其发布的路线图非常详细，并且在应用程序本身进行更新时宣布其冲刺编号，这非常酷。
When YAML includes a nice visual interface on top of it, it'll be time for everyone to jump but regardless I wanted to make my sites more self-contained. I may try using GitHub Actions at some point and comparing them as well.
当YAML在其顶部包括漂亮的可视界面时，每个人都该跳起来，但是不管我想使我的网站更加独立。 我可能会尝试使用GitHub Actions并进行比较。
从经典管道迁移到YAML管道 (Migrating from Classic Pipelines to YAML Pipelines)
If you have one, you can go to an existing pipeline in DevOps and click View YAML and get some YAML that will get you most of the way there but often includes some missing context or variables. The resulting YAML in my opinion isn't going to be as clean as what you can do from scratch, but it's worth looking at.
如果有的话，可以转到DevOps中的现有管道，然后单击“查看YAML”，然后获取一些YAML，它将在大多数情况下为您提供帮助，但通常会包含一些缺少的上下文或变量。 我认为生成的YAML不会像您从头开始可以做的那样干净，但是值得一看。
In decided to disable/pause my original pipeline and make a new one in parallel. Then I opened them side by side and recreated it. This let me learn more and the result ended up cleaner than I'd expected.
在决定禁用/暂停我原来的管道并并行创建一个新管道。 然后我并排打开它们并重新创建它。 这让我学到更多，结果最终比我预期的还要干净。
The YAML editor has a half-assed (sorry) visual designer on the right that basically has Tasks that will write a little chunk of YAML for you, but:
YAML编辑器的右侧有一个半成品(很抱歉)的视觉设计器，该设计器基本上具有一些可以为您编写少量YAML的任务，但是：
Once it's placed you're on your own
一旦放置，您就可以自己
- You can't edit it or modify it visually. It's text now. 您无法对其进行视觉编辑或修改。 现在是文字。
If your cursor has the insert point in the wrong place it'll mess up your YAML
如果光标将插入点放在错误的位置，则会弄乱您的YAML
- It's not smart 这不聪明
But it does provide a catalog of options and it does jumpstart things. Here's my YAML to build and publish a zip file (artifact) of my podcast site. Note that my podcast site is three projects, the site, a utility library, and some tests. I found these docs useful for building ASP.NET Core apps.
但是它确实提供了选项的目录，并且确实起步了。 这是我的YAML，用于构建和发布我的播客网站的zip文件(工件)。 请注意，我的播客站点是三个项目，该站点，一个实用程序库和一些测试。 我发现这些文档对于构建ASP.NET Core应用非常有用。
- You'll see it triggers builds on the main branch. "Main" is the name of my primary GitHub branch. Yours likely differs. 您会看到它触发了主分支上的构建。 “ Main”是我的主要GitHub分支的名称。 您的可能会有所不同。
- It uses Ubuntu to do the build and it builds in Release mode. II 它使用Ubuntu进行构建，并以发布模式构建。 II
- I install the .NET 3.1.x SDK for building my app, and I build it, then run the tests based on a globbing *tests pattern. 我安装了.NET 3.1.x SDK来构建我的应用程序，然后构建它，然后基于一个* tests模式运行测试。
- I do a self-contained publish using -r linux-x64 because I know my target App Service is Linux (it's cheaper) and it goes to the ArtifactStagingDirectory and I name it "hanselminutes." At this point it's a zip file in a folder in the sky. 我使用-r linux-x64进行了独立的发布，因为我知道我的目标应用程序服务是Linux(价格便宜)，并且转到ArtifactStagingDirectory，我将其命名为“ hanselminutes”。 这是天空文件夹中的一个zip文件。
Here it is:
这里是：
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- task: UseDotNet@2
displayName: ".NET Core 3.1.x"
inputs:
version: '3.1.x'
packageType: sdk
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI@2
displayName: "Test"
inputs:
command: test
projects: '**/*tests/*.csproj'
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI@2
displayName: "Publish"
inputs:
command: 'publish'
publishWebProjects: true
arguments: '-r linux-x64 --configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: true
- task: PublishBuildArtifacts@1
displayName: "Upload Artifacts"
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'hanselminutes'
Next I move to the release pipeline. Now, you can also do the actual Azure Publish to a Web App/App Service from a YAML Build Pipeline. I suppose that's fine if your site/project is simple. I wanted to have dev/test/staging so I have a separate Release Pipeline.
接下来，我转到发布管道。 现在，您还可以从YAML生成管道将实际的Azure发布到Web App / App服务。 我想如果您的站点/项目很简单就可以了。 我想要开发/测试/登台，所以我有一个单独的发布管道。
The Release Pipelines system in Azure DevOps can pull an "Artifact" from anywhere - GitHub, DevOps itself natch, Jenkins, Docker Hub, whatever. I set mine up with a Continuous Deployment Trigger that makes a new release every time a build is available. I could also do Releases manually, with specific tags, scheduled, or gated if I'd liked.
Azure DevOps中的Release Pipelines系统可以从任何地方提取“工件”-GitHub，DevOps本身，nen，Jenkins，Docker Hub等。 我使用一个持续部署触发器进行设置，该触发器在每次可用构建时都会发布一个新版本。 如果愿意，我也可以手动，使用特定的标签，预定的或封闭的方式进行发布。
Mine is super easy since it's just a website. It's got a single task in the Release Pipeline that does an Azure App Service Deploy. I can also deploy to a slot like Staging, then check it out, and then swap to Production later.
我的网站很简单，因为它很简单。 发布管道中只有一个任务可以执行Azure App Service部署。 我还可以将其部署到“分段”之类的插槽中，然后将其检出，然后稍后交换到“生产”中。
There's nice integration between Azure DevOps and the Azure Portal so I can see within Azure in the Deployment Center of my App Service that my deployments are working:
Azure DevOps与Azure门户之间有很好的集成，因此我可以在Azure的App Service部署中心内看到我的部署正在正常工作：
I've found this all to be a good use of my staycation and even though I'm just a one-person company I've been able to get a very nice automated build system set up at very low cost (GitHub free account for a private repo, 1800 free Azure DevOps minutes, and an App Service for Linux plan) A basic starts at $13 with 1.75Gb of RAM but I'm planning on moving all my sites over to a single big P1v2 with 3.5G of RAM and an SSD for around $80 a month. That should get all of my ~20 sites under one roof for a price/perf I can handle.
我发现所有这一切都可以很好地利用我的假期，即使我只是一个人的公司，我仍然能够以非常低的成本建立一个非常好的自动化构建系统(GitHub免费帐户为私人存储库，1800分钟的免费Azure DevOps分钟和适用于Linux的应用程序服务)基本版本起价为$ 13，带有1.75Gb RAM，但我计划将我的所有站点移至具有3.5G RAM和每月约80美元的SSD。 这样一来，我所有的约20个场所都将以一个我可以应付的价格/性能获得一个屋顶。
Sponsor: Like C#? We do too! That’s why we've developed a fast, smart, cross-platform .NET IDE which gives you even more coding power. Clever code analysis, rich code completion, instant search and navigation, an advanced debugger... With JetBrains Rider, everything you need is at your fingertips. Code C# at the speed of thought on Linux, Mac, or Windows. Try JetBrains Rider today!
发起人：喜欢C＃吗？ 我们也这样做！ 这就是为什么我们开发了一个快速，智能，跨平台的.NET IDE的原因，它为您提供了更多的编码能力。 巧妙的代码分析，丰富的代码完成，即时搜索和导航，高级调试器...使用JetBrains Rider，您所需的一切都唾手可得。 在Linux，Mac或Windows上以思考的速度编写C＃代码。 立即尝试JetBrains Rider ！
扫一扫
448
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
