如何允许多种类型的部署？

Question

在搜索meaning of life 时，我偶然发现了一篇博文，其中提到你的部署策略不是你的架构，它只是一个实现细节，因此，我们需要设计允许不同的部署模式模式，无论您是将系统部署到 1 个节点还是多节点，还是其他类型的结构。

最新版本的 Visual Studio 是否提供了某种灵活性（除了天蓝色）以能够以各种策略部署服务？

例如，假设我有一个解决方案

    Acme Solution
    --Acme Startup Proj
    --Acme Service A.csproj
    --Acme Service B.csproj
    --Acme Service C.csproj

我希望能够将整个解决方案部署为 1 个解决方案，或者我希望能够部署 3 个单独的二进制文件，每个微服务一个。

AcmeServiceA.exe
AcmeServiceb.exe
AcmeServicec.exe

Visual Studio 在部署配置的灵活性方面为您提供了什么？

Answer 1

部署技术会因您的应用所构建的技术而异。举个例子，我假设我们正在处理 Web 服务或网站。

您指定了两种部署方案：部署单个项目（例如微服务）和部署所有项目（全面推出）。让我们从小事做起...

部署单个项目

要计划的主要事情是每个可部署的原子（这可能是一个项目或一个服务 + 数据库后端......就像您不希望将其拆分为更小的部署一样小）。

对于Web项目（无论是Web API项目还是其他类型），Visual Studio的内置选项一般可以概括为：WebDeploy、Azure、现在使用 .NET Core、Docker 映像。我不打算深入每个细节，因为这些是单独的问题。但是，如果它们听起来很有趣，我可能会参考一些细节供您研究（我在概念上对 WebDeploy 更熟悉，所以我会参考很多；但我并不赞成或反对它）。

例如，如果您使用 WebDeploy，您可以让每个项目生成一个 WebDeploy 包。 （再次，查看此以了解有关 如何 的更多详细信息）。这个包可以被设计成包含一个文件有效负载（站点/服务文件）以及一个数据库有效负载，或者使用 WebDeploy 提供程序模型的其他子原子。 Visual Studio 对这种情况有相当不错的支持，并且有相关文档。

或者你可以生成一个 Docker 镜像。根据我的理解（目前还缺乏使用 Docker 的经验），如果你想部署 Web 服务和数据库，它们应该在单独的容器中。您很快就会发现自己在 VS 之外构建这些。这不是一件坏事，一旦你掌握了 Docker 的窍门，它听起来就非常灵活；但是您要为此离开 IDE。

无论哪种方式，现在您都可以部署 atomic 包了。这是最简单的部分。

部署解决方案

所以，您有很多这些原子部署包。您如何将它们全部推出？

嗯，在这一点上，VS 并没有为你提供很多东西。并且很难证明 VS 应该在这里做什么 。几乎每个组织都会提出略有不同的规则。您是否从 CI 部署？您是否创建包并将它们部署到发布管道中的不同环境？还是在云和热插拔环境（如 Azure 部署槽）中执行此操作？

VS 原生解决方案必须是高度可配置的（因此非常复杂），或者过于简单而无法满足大多数客户的需求。 （顺便说一句，在 VS2010 中对 WebDeploy 的初始支持在第一个问题上出现了错误。它非常可配置，客户甚至产品团队很难理解所有可能的场景。来源：我是该功能的 QA 曾几何时。）

此时您确实需要确定部署部署的方式和时间。您需要一些东西来编排这些部署中的每一个。

VS 通常使用 MSBuild 来编排事务。同样，我并不是在提倡将其作为您的编排平台（我实际上不喜欢它...这对您的项目配置没问题，但 IMO 不适合任务管理），但是如果这样是你想用的，它可以工作。如果您将它用于 Web 项目场景，它实际上非常简单。您可以构建您的解决方案并使用参数/p:PublishOnBuild=true。如果您使用 WebDeploy 直接发布，您就完成了！如果您正在创建 WebDeploy 包，那么您仍然需要推送它们，但至少您已经一次性创建了它们。

如果您使用 WebDeploy 包，它们将各自生成一个用于发布的脚本。还有一些方法可以传入不同的 WebDeploy 参数，因此您可以重用相同的包（构建输出）来发布到不同的环境。但是，您必须编写自己的脚本才能将所有这些组合到一个巨石部署中。

同样适用于 Docker。你可能会得到一组图像，但你仍然需要一些东西来协调发布所有这些图像。 Kubernetes 之类的工具可以帮助您进行部署，或者在出现问题时进行回滚。

还有更通用的编排平台，例如 Octopus Deploy。

多么令人不满意！

是的，没有针对大规模部署的开箱即用解决方案有点糟糕。但如果有，它对 95% 的团队都不起作用。 VS 提供的大部分功能足以让个人或非常小的开发团队将他们的代码发送到他们的服务器。任何更大的团队，您都可以通过构建一个针对您的团队运作方式量身定制的系统获得更好的成果。那里有很多工具，但没有一个工具在所有情况下都能完美运行。找到一个适合你的，你会没事的。最后，这一切都归结为推送文件和运行脚本。如果您不喜欢某个系统或工具，可以尝试另一个。

Answer 2

如果您希望在 Visual Studio 中获得改进的部署体验，请查看 Flexera 的 InstallShield Limited Edition 内置解决方案（ISLE，http://blogs.msdn.com/b/visualstudio/archive/2013/8/15/what-s-new-in-visual-studio-2013-and-installshield-limited-edition.aspx）。对于那些寻求 Visual Studio 安装程序项目中没有的附加功能（例如 TFS 和 MSBuild 集成、对创建新网站的支持和 ISO 19770-2 标记支持等）的客户来说，ISLE 是一个很好的解决方案。

VS2015：https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2015InstallerProjects

VS2017：https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2017InstallerProjects

使用设置和部署项目模板，您可以选择将解决方案中的所有程序集打包或将每个程序集单独打包为使用设置、Web、CAB 或合并模块项目的微服务：

然后选择包含哪些程序集：

Answer 3

这实际上取决于具体的用例如何实现所要求的某种灵活性，以及您对这种灵活性的可接受水平的定义。

以这三个不同的可执行文件作为单独的微服务（服务 A、B、C）和 Web.Api 上下文中的完整服务（启动）为例，您可以执行以下操作：

1. 每个项目（服务 A、B、C）都可以设计为单独的 OWIN 自托管可执行文件（如Use OWIN to Self-Host ASP.NET Web API 2 中所述）并提供一个或多个要公开的端点。

   李>

2. 主项目（启动）也可以是 OWIN 自托管或常规 IIS Web.Api 应用程序，它引用三个项目（服务 A、B、C）并在其自己的 @987654322 中加载各自的端点@routine（以及可选的自身的附加端点）。

然后，您可以在 Visual Studio 中使用单独的配置项目（或完全不同环境中的外部项目），并使用 Puppet、Chef 等部署技术，或根据您的场景进行部署。

您的代码将不受您实际希望执行的部署的影响，并且相应的配置将单独管理。

如果这不能回答您的问题或者我误解了您的问题，请您澄清一下并提供更多详细信息？

Answer 4

当我们谈论生命的意义时，这是部署（安装）专家关于它的两分钱 :-)- 答案很长（似乎 :-)，但它会包含在哪里寻找的具体信息每一点..

首先，让我们声明部署并不是一件轻而易举的事，尽管许多开发人员希望看到这样的情况（作为一名部署专家，我经常观察到软件开发过程中的利益相关者实际上是这样思考的——简单地说，直到发货前一天，部署才被遗忘:-)

将其与可乐进行比较，这是一个大胆而简单的例子。 “开发人员”生产液体，但在这里很容易意识到，这项工作还没有完成。 :-)

Visual Studio 本身并没有真正支持部署策略。基于以下列表中提到的几个部署领域，当然有很多技术，其中一些来自 Microsoft，可以帮助实现这一点。 我要做的是为不同的客户或安装服务子集的场景构建设置包，如客户端/服务器场景或其他（参见下面列表中的第 3 号。）

---

其次，正如您可能从其他答案中看到的那样，部署不是部署。 部分地，这取决于人们是否将部署视为仅通过 MSBuild 生成二进制文件或部署到测试系统或部署到客户，例如通过更新生产网站或制作 DVD 或将可执行文件上传到更新网站...

有几个不同的领域肯定有关系，但每个编号的领域都足够大和复杂，足以拥有自己的专家：

1. 被视为架构一部分的部署必须处理源和二进制结构和实体，例如项目和二进制结构（有多少.exe、.dll文件，它们的依赖关系如何，变化计划。 => 正如您所提到的，您在（Visual Studio 等）解决方案、项目以及命名空间领域，特别是在 WCF 领域，您有合同等，您有（POC#）接口等。您有 Nuget 或其他工具来解决和管理依赖项。 .NET 必须提供程序集的概念来处理这个问题，例如架构。如果在自己的程序集中部署接口和契约，如何处理客户端/服务器场景，程序集如何相互依赖，取决于您和架构..

   • 关于服务，有一个有趣的子任务如何托管服务，它们可以托管在 Web 服务器上，可以在 .exe 中自托管，可以使用 IIS 或 OWIN 托管等。更多信息的链接：

   • WCF 中的自托管： https://msdn.microsoft.com/en-us/library/ee939340.aspx

   • Windows 服务中的自托管，此处使用 SignalR： https://code.msdn.microsoft.com/windowsapps/SignalR-self-hosted-in-6ff7e6c3

   • 使用 OWIN 托管： https://en.wikipedia.org/wiki/Open_Web_Interface_for_.NET

2. 作为本地 Windows 或其他操作系统集成的一部分进行部署：您必须考虑通常必须在哪些系统目录中放置某些文件或数据。您必须考虑共享 dll、共享数据、项目数据、临时数据、用户特定数据、注册表、文件系统、Windows 徽标要求、最佳实践、服务配置等。

3. 部署作为创建设置的过程，拥有安装，除其他事项外，它还完成了 2- 中提到的所需操作以及图形等附加任务安装前端（设置 GUI）、许可证确认、新增功能部分、可选组件的选择（想想 Visual Studio 设置）、卸载/修复/修改可能性等等。

4. 部署为 devops 进程，例如continuous integration , continuous delivery and/or continuous deployment 的一部分。这里有两个要点：从技术上讲，有一个定义的过程，它会自动执行 2. 和 3. 中提到的事情（或者 Web 部署步骤）作为构建过程的一部分（“构建后步骤”）。
   这可以包括创建设置或设置的层次结构 - 或根本不使用设置）。第二个是让测试人员、开发人员和管理人员（甚至客户）至少每天早上甚至更频繁地查看最后一个夜间或每日构建的已安装示例，可能有多个部署变体（客户端/服务器？、基本/教授？）或在不同的系统上。 你一半在开发者世界，一半在管理世界。 这里的重点通常不是像 3 那样创建复杂的设置，而是主要定义自己的“打包”和复制（和签名......等）过程，并将它们作为开发（以及测试和交付）的一部分自动化过程。 Puppet 和 Chef 已被提及。

5. 部署为 web 或云部署（也可以是 devops 流程的端点）- 其他人对此已经说过，我将在这里省略细节，但一个重要的区别是，如果您正在谈论部署到客户或部署到中间测试或登台系统。 也许有一点值得对 devops 提及这一点，那就是部署到在线服务器、服务器场或云都有自己的挑战。

6. 部署主要被视为将可交付、购买和/或拥有的编程软件分发到公司及其子公司的所有数千台 PC 的管理过程。当然也有专门的工具，包括更新策略、监控、许可证管理等等。您现在是在管理世界，而不是在开发人员世界。 微服务对于主要用于安装和分发“大型”软件包（如 MS Office 或 Oracle 等）的管理员来说将是一个新的高挑战。

   • 这个话题对于开发人员来说并不像看起来那么无聊。主要是因为开发人员和管理员的两个“世界”正在合并。而开发人员必须关心“在现实世界中运行软件”的客户观点。 Devops 只是一个开始。每个人都知道虚拟机，但现在我们有软件定义的网络、虚拟应用程序、虚拟服务器场、云等。您可以通过依赖项定义部署架构，而无需任何编程，只需通过配置即可。因此，部署应该是您的应用程序架构的一部分，但大多数情况下它还不够（足够）。事实上，到目前为止，管理视图几乎没有与软件生产者/开发者的视图集成。关于微软，Windows 团队在这里做了很多工作，尤其是。在服务器产品线中，这从未与开发团队 AFAIK 进行过真正的战略协调（到目前为止，这可能对每个软件商店都有效:-)

目前，很多发布与 devops 或持续流行语相关的内容的人对设置的经验并不丰富。在其他必要步骤中，建筑设置可以被视为一项特殊技术。

鉴于您有兴趣了解有关 3.（设置）的更多信息： 如果您不想只复制可执行文件，而是想要拥有完整设置的功能，这比复制做更多的工作，设置策略的一部分可以是使用自己的选择进行捆绑设置（有时称为套件设置或引导程序设置）特征。他们可以调用底层的小型设置，例如用于您的微服务。

Visual Studio 本身不再支持像 MSI 这样更复杂的设置类型，尤其是从来没有将设置分组到包，部署一堆（或服务的变体）——VS 对“ClickOnce”部署提供了一些支持，但这更多地是针对数据库（“智能”）客户端而不是服务甚至微服务。 点击一次：https://msdn.microsoft.com/de-de/library/31kztyey.aspx

WiX 工具集可以替代 Visual Studio 中缺乏“真正的”设置创建，它是由 Microsoft 员工组成的开源项目。或 InstallShield Express（它是免费的，但商业版本的有限变体）。 使用这两者，您可以创建完整的 MSI 设置，这可能是 windows setup zoo 中最复杂的设置类型。

a) 当然，除了 MSI（也称为 Windows Installer）之外，还有其他设置类型，它们来自第三方供应商，它们或多或少是专有的，但更简单：例如Nullsoft - NSIS 和 InnoSetup.
我不会提供用于创建单个 MSI 设置的链接，因为可以通过下一行中的创建 MSI 设置包的给定链接轻松找到它们：

b) 在 Wix“世界”中创建选择和安装其他（定义的底层子集）的设置的工具称为“Burn”：

使用 Burn 创建设置包： http://wixtoolset.org/documentation/manual/v3/bundle/

为此，您可以从 WiX 的创始人那里获得特别（付费）支持，他为此专门创建了一家公司： https://www.firegiant.com/wix/tutorial/net-and-net/bootstrapping/ 可以在 SA 上找到创始人 Rob Mensching 并回答专门的问题。

c) InstallShield Suite 设置： 另一个是已经提到的工具 InstallShield，但为此您将需要他们的 InstallShield Premium 变体，该变体要花很多钱：
http://helpnet.installshield.com/installshield21helplib/helplibrary/SteCreatingSuites.htm

d) 设置工厂： https://www.indigorose.com/setup-factory/

e) 我敢肯定，很多人会建议看看 Docker。 虚拟应用程序不仅是设置，而且它们在“已安装”状态下将自己与沙盒等其他应用程序隔离开来。 参见例如https://docs.docker.com/docker-for-windows/

f) 如果我不提到 APP-V 作为与 docker 共享一些但不是全部功能的虚拟应用程序安装技术，那么该列表将不完整。但这些技术并不是真正为协调多个交付而设计的，而是仅用于交付一个应用程序。 微软还定义了一种名为 AppX 的新设置类型。 特别是你必须有所不同，如果你想为 Windows 创建“传统”（完整）桌面应用程序，其中 MSI 设置是 Windows 8 以来新类型的已知技术或存储应用程序（又名通用 Windows 应用程序，又名 Windows 商店应用程序，又名现代应用又名 Metro 应用）。

AppX： https://msdn.microsoft.com/en-us/library/windows/desktop/hh446767(v=vs.85).aspx AppX 的目标设置类型比 MSI 更简单。

通用 Windows 应用 (UWP)： https://docs.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp

对于任何更详细的信息，我们必须了解更多您的要求。