从零开始针对 .NET 应用的 DevOps 运营实践 - 运行环境搭建

一、Overview#

最近的一段时间，在公司里我都在进行基于 Jenkins 和 SonarQube 配合已有的 Gitlab 搭建部门的持续集成环境的工作，虽然之前有使用过 GitHub Actions 和 Azure DevOps，但是从头开始搭建这样的一套 DevOps 环境还是学习到了一些新的知识点，因此，借着这个中秋国庆假期的机会，分享下整个工具链的搭建过程，如果你也有相似的需求的话，希望可以对你有所帮助

二、Contents#

从零开始针对 .NET 应用的 DevOps 运营实践 - 运行环境搭建

三、Step by Step#

3.1、一些概念#

DevOps, Development 和 Operations，从名称上就可以看出，这一名词包含了软件的开发与运营。当然，这里提到的 DevOps 是一种方法论，更多的是为了打破开发与运营人员之间的壁垒，用来促进开发人员、运营人员以及 QA 人员之间的沟通与协作。通过引入 DevOps 中使用的各种工具，我们可以通过自动化的方式，完成软件系统的构建、测试、发布，从而降低因人工操作所造成的不确定性，提升软件的交付速度、系统质量

在践行 DevOps 方法论时，经常会提到三个概念，持续集成、持续交付、持续部署，这里借由 Redhat 上介绍相关概念的一张图片来说明三者之间的联系

持续集成（Continuous Integration）：在传统的软件开发过程中，将个人开发的代码与整个项目代码的合并一般都会置于比较靠后的阶段，而持续集成强调的是开发人员提交了新代码之后，立刻进行构建、单元测试。根据测试的结果，确定新代码和原有代码能否正确地集成在一起
持续交付（Continuous Delivery）：持续交付是一种自动化的软件交付手段，在持续集成的基础上，代码库中的代码已经做好了部署到正式环境的准备，在目前的通用做法中，将构建之后的代码通过持续交付变更部署到测试环境、预发布环境中，实现对持续集成的扩展，出于业务方面的考虑，我们可以手动选择是否部署到正式环境
持续部署（Continuous Deployment）：作为对持续交付的延伸，持续部署能够自动的将最终的代码部署到生产环境中，完成整个的 CI/CD 流程

虽然目前的需求仅仅是为了实现持续集成，完成对于系统的自动化代码检查、自动化单元测试，但是因为后续的功能对于我们完整的实施 DevOps 方法论也是必须的，所以在这几篇的博客内容中，我也会完成对于后续功能的实践分享

3.2、前期调研#

与持续集成的场景存在一些的差异，我们在实际的开发中，并不会在新的功能分支上按照每个开发人员再建立单独的分支，因此，这里的持续集成更多的想要实现的是当开发人员提交代码到 Gitlab 时，自动触发代码检查以及单元测试，产出代码检查报告、单元测试报告、以及整个项目的测试覆盖率

因此，基于目前的需求，整个系统主要依赖于三个主要的软件系统，Gitlab、Jenkins、以及 SonarQube，当然，这里缺少了一个 bug 管理工具，因为我们部门人数不是很多，目前是和别的部门共用的 Redmine 进行的项目管理，所以本次并没有纳入到我们的需求范围内，当然， bug 管理也是推行 DevOps 中不可缺少的一部分

在挑选组件时，本着不给自己和别人挖坑的原则，优先考虑使用人数多的软件系统。因此，作为事实上的开源 CI/CD 工具的标准，毫无疑问选择 Jenkins，而对于代码的自动化检查，结合我们需要实现私有化部署，满足对多种开发语言的支持、能够与 CI/CD 工具进行有效结合的需求，这里最终选择的是 SonarQube

由于历史原因，部门系统的框架版本横跨了 VB.NET、.NET Framework 2.x，4.x 与 .NET Core，.NET 框架的程序涵盖了 Web Form、MVC、Web API，排除掉已经不维护的系统，最终需求的范围限定在支持 .NET Framework 4.x+ 以及 .NET Core 程序上。因此，这里只能选择将 Jenkins 和 SonarQube 部署到 Windows 服务器上，如果你不需要兼容 .NET Framework 的程序，推荐你部署到 Linux 服务器上

在选定好使用的软件后，就需要完成环境的配置，Jenkins 与 SonarQube 都是基于 Java 的软件，因此在安装软件之前，需要我们在服务器上完成 Java 环境的配置，同时，基于我们的系统现状，需要在服务器上安装好 .NET Framework、.NET Core、Git 以及 Node

对于 Git、Node、.NET SDK 的安装，下载安装包后，一直 next 即可，加上这里主要针对的是 .NET 程序员，以及我们的服务器是断网的，所以这里主要列举的是两个相对来说稍微复杂的环境配置，一个是对于 MSBuild 工具的离线下载，另一个则是 Java 环境的配置

3.3、MSBuild 安装#

因为在整个过程中会涉及到对应用程序的编译生成，对于 .NET Core 应用，完全可以采用 .NET Core CLI 中的各种命令来实现，而对于 .NET Framework 程序来说，则需要一个执行应用程序生产的平台，MSBuild 就是这样的一个工具，我们在开发过程中使用 Visual Studio 进行程序编译时，其实也是会借用 MSBuild 来进行的

因此，最简单的办法，就是在服务器上安装 VS 即可，当然，这个过于简单粗暴了，以及在服务器上安装我们开发使用的 IDE 也过于浪费，所以这里还是会选择独立的安装 MSBuild

与 VS 相似，MSBuild 也有不同的版本，为了避免一些莫名其妙的问题，在 MSBuild 的版本选择上，最好选择与你们开发时用的 VS 匹配的版本，因为我们在开发中会使用到了 VS 2017 和 VS 2019 这两个版本，所以这里我会安装两个 MSBuild 到服务器上

对于 MSBuild，之前很多文章中说可以直接把你本地电脑中的 VS 所包含的 MSBuild，丢到服务器上就可以了，经过我的多次尝试，在踩坑的路上越走越远，这里还是建议你通过 Visual Studio Build Tools 进行安装

在 VS 的下载页面，这里是以 VS 2019 的下载页面进行示例，在 Visual Studio 2019 工具这个内容块中，找到生成工具这个下载项，下载即可

这里你可以直接通过我给出的这两个地址，直接下载对应的生成工具，打开软件，找到 MSBuild 这个组件进行安装即可

Visual Studio 2017 Build Tools：https://visualstudio.microsoft.com/zh-hans/thank-you-downloading-visual-studio/?sku=BuildTools&rel=15
Visual Studio 2019 Build Tools：https://visualstudio.microsoft.com/zh-hans/thank-you-downloading-visual-studio/?sku=BuildTools&rel=16

当然，这个下载完成的也只是一个在线安装包，还是需要连接网络进行下载的，如果你们的服务器也是没有连接外网权限的话，这里需要换个方式

对于离线安装，找到下载后的安装器所在的路径，打开 CMD，输入下面的命令，即可按需下载需要的组件到指定的位置，例如这里我是将下载好的文件放在我桌面上的 msbuild 文件夹下的 offline 文件夹中

Copy
vs_buildtools.exe --layout C:\Users\danvi\Desktop\msbuild\offline --add Microsoft.VisualStudio.Workload.MSBuildTools --add Microsoft.VisualStudio.Workload.WebBuildTools --lang zh-CN

整个命令包含了三个部分的内容