《DotNET Core与 DevOps敏捷实现概述》由会员分享，可在线阅读，更多相关《DotNET Core与 DevOps敏捷实现概述（13页珍藏版）》请在金锄头文库上搜索。
1、.NET Core 与 DevOps敏捷实现概述目 录1.关键要点32.NET Core 框架和 SDK52.1.我的 IDE 呢82.2.使用IIS82.3.这与 DevOps 有什么关系93.NET Core 构建自动化93.1.始终有一个可部署的构建。104.使用.NETCore 进行应用程序监控115.结论131. 关键要点 无论你目前使用什么样的技术栈，DevOps 都是值得一试的。 闭源、专有软件和构建过程与 DevOps 实践不兼容。 .NET Core 是开源的，是基于 DevOps 构思和构建的。 .NET Core CLI 和 Roslyn API 让整个交付流程变得更加开
2、放，且具有更强的适应性强。 自动化是 DevOps 的重要组成部分，.NET Core 从一开始就支持自动化构建和部署。随着.NETCore 2.0 的发布（最初发布于 2016 年），微软拥有了一个通用、模块化、跨平台和开源的平台最新主要版本。.NETCore 在当前版本的.NETFramework 中提供了很多 API。它最初是作为下一代 ASP.NET 解决方案而创建的，但现在成为很多其他场景的基础，包括物联网、云计算和下一代移动解决方案。在这篇文章中，我们将探讨.NETCore 的更多优势，以及它如何在为传统的.NET 开发人员带来好处的同时，还能让所有需要为市场带来强大、高性能和经济
3、的解决方案的技术人员受益。从.NET1.0 推出测试版开始，我就在开发软件。我还记得当时使用.NET 感觉就像在作弊一样。我当时想，“这不是应该很难吗？我的 malloc 在哪里？我不需要转换指针了吗？这个框架类库用来做什么的？”快进到 2018 年，我们仍然很乐意在.NETFramework 上编写代码，不必为内存分配问题而烦恼。System.Thread 为我们处理线程问题，然后是 BackgroundWorker，现在是 Task。原先不是线程安全的 FCL 类现在被标记为线程安全的。想开发一个 Web 应用程序？它就是一个完整的框架，包含了所有必需的组件。.NET 为我们提供了很多原本
4、需要手动完成的东西。作为开发人员，我们把更多的时间花在编写业务逻辑代码上。汇编 /C/C+ 拥护者可能会唏嘘现在的一般开发人员都不需要硬核系统编程知识，但我不会这么抱怨！从第一个 Beta 版开始，.NET 经历了多次迭代，其中包括了四个主要版本。最近的迭代.NETCore 是最重要的。.NET Core 带来了真正的跨平台、现代 CLI、构建系统和开源库，等等。这些东西都很重要，但.NETCore 的承诺不止于此，它还涉及了软件的开发和交付方式。我开发软件已经有二十多年了，所以我还记得源码控制是为“大型”团队而保留的。“自动化”并没有真正出现在我们的词典中除了我们为客户自动化业务流程。说得具
5、体一点，就是构建 / 编译软件是由人类完成的。“构建经历”会在她自己的计算机上生成二进制文件（所以生成的文件在她自己的计算机上总能正常运行）！将软件部署到它要运行的环境中是一个脆弱的拜占庭式过程，因为需要共享驱动器、FTP 和进行手动文件复制粘贴。整合开发团队的工作是一场悲惨的死亡游行，一次又一次的回退就像玩打地鼠游戏一样。是否可以投入生产？谁知道呢？软件正在迅速建立起对世界的兴趣，但开发、部署和运营基于软件的系统的过程却停留在图灵和Hopper时代。2008 年左右发生了一场革命，这场革命被称为 DevOps。从那时起到现在，这些年我们已经看到一场运动的兴起。DevOps 非常重要，它包含并
6、可能取代之前出现的敏捷运动。我在 2014 年开始接触 DevOps，当时我在一次大会上拿到了凤凰项目这本书。当我开始如饥似渴地阅读那本书时，我的会议计划被我抛到脑后。这本书讲的东西太多了。如果你正处在 IT 行业，即使是很短的时间，你也一定扮演过那些角色。你可以试着自己代入角色。从那以后，DevOps 成了我职业生涯的焦点。DevOps 通常被认为有三个主要的“支柱”：文化、流程和技术。本文是关于 DevOps 的技术部分。具体地说，是关于.NETCore 为现代 DevOps 实践带来的技术。.NET Core 是在 DevOps 兴起期间构思出来的。微软显然有明确的目标，就是让.NETC
7、ore 成为 DevOps 时代的平台。本文将介绍.NETCore 和 DevOps 的三个主要主题： .NET Core 框架和 SDK； 构建自动化； 应用程序监控。2. .NET Core 框架和 SDKDevOps 并不是孤立存在的。用于生成和交付基于软件的系统的技术可能可以支持或者阻碍 DevOps 实践。无论你的技术栈是怎样的，DevOps 都是值得一试的。话虽如此，你选择的技术栈将对你的 DevOps 实践产生重大影响。闭源、专有构建系统对 DevOps 来说并不友好。.NET Core 是完全开源的，用于表示项目和解决方案的文件格式也有完整的文档化。现代语言和框架（如 Node
8、/JavaScript、Ruby 和 Python）已经具有一些常见特性： 紧凑的开源框架； 命令行界面（CLI）； 记录良好的开放式构建系统； 支持所有主要操作系统。这些特性和其他更多功能在 DevOps 时代变得越来越流行，因为它们具有很强的适用性和自动化能力。.NETCore 的 CLI 命令 dotnet 是.NETCore 应用程序构建过程的单一入口点。无论是什么平台，开发人员都可以在工作站上使用 dotnet，用于构建代理。也就是说：我将在后续展示的所有本地开发工作都可以在 MacBook Pro 上进行。试着想象一下，这在三年前是不可能的事情！使用.NETCore 的第一步是下载
9、它。你可以在这里下载 SDK。在我的 MBP 上有 171MB。安装完毕后，打开你最喜欢的终端窗口（在 Windows 上我偏爱 Powershell，但在 Mac 上我使用 iTerm2）。如果你已经很熟悉.NET 开发，那么可能已经习惯了安装大型框架。你习惯使用 Visual Studio 来完成开发工作。如果你是.NETCore 新手，可能会觉得有点奇怪。在使用 IDE 之前，我们可以使用这 171 兆字节的东西完成很多事情。执行：dotnet这是一个新的 CLI 命令，用于与.NETCore SDK 发生交互。让我们来看一下。执行：dotnet help这将列出 CLI 支持的所有命令
10、，这个清单并不长，也没必要很长。你可能在查找哪些是与.NETCore 框架构建过程进行交互所需的，从一个新项目到已部署的应用程序。第一步是创建一个新的应用程序。让我们来看看我们的选项。执行：dotnet new输出的信息将列出可用的模板。在 Visual Studio 中你可以单击 File-New Project 来创建项目，但在这里我们使用命令行。我们有很多模板可选择。我偏爱 Angular，所以让我们从那里开始吧。执行：dotnet new angular -o dotnet-angular这将在新目录 dotnet-angular 中创建一个新的 Angular 项目。如果你愿意，可以
11、手动创建目录，只是在执行 dotnet new 之前不要忘记更改目录，否则将在当前目录中创建项目。如果你已经做过 Angular 开发，那么可能已经安装了 Node。如果没有，请花点时间下载并安装它。如果确实需要安装 Node，请在安装后关闭并重新打开终端。执行：dotnet run这个命令将编译并运行应用程序（也可以通过执行 dotnet build 直接完成编译，而无需运行应用程序来）。这可能需要一两分钟时间，然后你将得到一些包含 URL 的输出：Content root path: /Users/dswersky/dotnet-angular Now listening on: http
12、s:/localhost:5001将 URL 复制到 Web 浏览器中，然后等一会儿。你现在应该能看到一个在后台运行 ASP.NETCore、在前端运行 Angular 的简单应用程序。那么，这种体验与昔日的.NET 开发体验有何不同？你在几分钟内就创建并运行了一个.NETCore 应用程序（即使包括安装.NETCore 和 Node），你可能会想到这几个问题：2.1. 我的 IDE 呢到目前为止，我们还不需要 IDE，对吗？很显然，如果你想编辑这段代码，你需要使用某些工具。你可能希望使用与.NET 和 Angular 相关的工具。“没问题”，你可能会想，“我启动 Visual Studio
13、Professional 就可以了”。你可以这样做或者你也可以下载 Visual Studio Code，它提供了很多功能，而且是免费的。你可以使用 Visual Studio Community，它也是免费的。关键在于，不再需要花费数百美元就可以开始基于.NETCore 的开发。2.2. 使用IIS这是“遗留”.NETWeb 应用程序开发和 ASP.NETCore 之间的主要区别。你可以在 IIS 中运行 ASP.NETCore 应用程序，但也可不必这么做。.NET Core 是跨平台的，所以将 ASP.NETCore 与 IIS 分离也是显而易见的。我在这里列出的命令，包括 dotnet
14、run，在 Windows、Mac 和 Linux 上同样运行良好，且效果完全相同（甚至还有一个可以在 Raspberry Pi 上运行的 ARM 构建命令）。这个 Angular 应用程序是“编写一次，到处运行”的一个很好的示例。不使用 IIS 来托管.NET 应用程序已经有一段时间了。.NET Open Web Interface（OWIN）多年来一直支持“自托管”ASP.NET 应用程序。这是通过代码和基础设施（通常称为“Project Katana”）来实现的。.NET Core 使用了一个叫作Kestrel的 HTTPS 服务器。Kestrel 是一款用于.NET 应用程序的快速、高
15、性能、开源的 HTTPS 服务器。Kestrel 为 ASP.NETCore 网站和 RESTful 服务提供 HTTPS，让它们可以运行在任何地方，包括 Windows、Linux 和容器协调器。Kestrel 使 ASP.NETCore 应用程序变得完全独立，在基于 Windows 的 HTTPS 服务器上没有外部依赖性。2.3. 这与 DevOps 有什么关系自动化是 DevOps 的核心原则和实践。.NET Core 提供的可移植性、CLI 和开源构建系统对于 DevOps 实践来说至关重要。最重要的是，它们可以轻松实现构建和部署过程的自动化。可以通过编写 CLI 脚本来实现自动化，也可以通过编程方式直接自动化构建系统。.NET Core 的这些功能使其不仅可以实现自动化，而且可以相对轻松地自动执行复杂的构建过程。我们因此能够建立自动化和持续集成。3. .NET Core 构建自动化回到 Visual SourceSafe 时代，团队提交到存储库的代码就在那里，随时准备好进行编译。我的脑海里浮现出一个想法“为什么我要在我的系统上构建部署，因为构建原本可以在存储库中进行？”我不是唯一一个有这种想法的人，但却没有对此采取什么行动。真正采取行动的是那些开始着手开发持续集成（CI）系统的勇士们。CI 的目标说起
