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

Question

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

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

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

    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 API项目或其他类型），Visual Studio的内置选项通常可以概括为： WebDeploy ， Azure ，现在使用.NET Core， Docker镜像。我不打算详细介绍每个细节，因为这些都是单独的问题。但是我可以参考一些细节供你研究它们听起来有意思（我在WebDeploy概念上比较熟悉，所以我会提到很多;但我并不是在鼓吹或反对它）。

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

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

无论哪种方式，现在您可以部署原子包。这很容易。

部署解决方案

所以，你已经拥有了很多这些原子部署包。你如何全力以赴？

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

VS本机解决方案必须是极其可配置的（因此非常复杂），或者它太简单，无法容纳大多数客户。需要。 （顺便说一句，在VS2010中对WebDeploy的初始支持在第一个方面存在错误。它非常易于配置，对于客户甚至产品团队来说都非常难以绕过所有可能的场景。来源：我是曾几次对该功能进行质量保证。）

此时您需要确定部署方式和时间。您需要协调每个部署的内容。

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

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

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

还有更通用的业务流程平台，如Octopus Deploy。

多么不满意！

是的，对于大规模部署而言，没有开箱即用的解决方案，这很糟糕。但如果有的话，95％的团队都无法工作。 VS提供的大部分内容足以让个人或非常小的开发团队将他们的代码提供给他们的服务器。任何规模较大的团队，您都可以在构建专为团队运营方式量身定制的系统中获得更好的成绩。有很多工具，在所有情况下都没有完美的工作。找一个适合你的，你会没事的。最后，这一切都归结为推送文件和运行脚本。如果您不喜欢一个系统或工具，可以尝试另一个系统或工具。

Answer 2

这实际上取决于确切的用例如何实现所请求的某种灵活性以及您对可接受级别这种灵活性的定义。

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

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

2. 主项目（Startup）也可以是OWIN自主主机或常规IIS Web.Api应用程序，它引用三个项目（服务A，B，C）并在其自己的{{{}中加载各自的端点1}}例程（以及可选的iteself的其他端点）。

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

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

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

Answer 3

如果您正在寻找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 Installer项目中没有的附加功能的客户来说，ISLE是一个很好的解决方案，例如TFS和MSBuild集成，支持创建新网站和ISO 19770-2标记支持等。

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

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

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

然后选择包含哪些组件：

Answer 4

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

首先，让我们说部署不是一个nobrainer，虽然许多开发人员希望看到它（并且作为部署专家，我经常观察到软件开发过程中的利益相关者实际上是这样想的这个 - 简单的说，部署有点被遗忘，直到发货前一天： - ）

将它与焦炭进行比较，获得一个大胆而简单的例子。 ＆＃34;开发人员＆＃34;生产液体，但在这里很容易实现，这项工作尚未完成。 ： - ）

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

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

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

1. 作为架构的一部分，部署必须处理源和二进制结构和实体，例如项目和二进制结构（多少.exe，.dll文件，它们的依赖关系，变体规划。 =＆GT;正如你所提到的，你在（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 的一部分。这里有两个要点：从技术上讲，要有一个已定义的流程，即在构建流程的一部分（＆＃34;构建后步骤＆＃34; ）。
   这可以包括创建设置的设置或层次结构 - 或者根本不使用设置。第二个是让测试人员，开发人员和管理人员（甚至客户）至少每天早上或甚至更经常地看到已经安装的最后一夜或每日构建的示例，可能有几种部署变体（客户端/服务器？，基本/教授？）或在不同的系统上。 你在开发者世界的一半，在管理世界的一半。 这里的主要观点通常不是像3中那样创建复杂的设置，而主要是为了定义自己的＆＃34; pack＆＃34;并复制（和签署......等）流程，并将其作为开发（和测试和交付）流程的一部分进行自动化。已经提到 Puppet 和 Chef 。

5. 部署为Web或云部署（也可以是devops进程的端点） - 其他人已经说了些什么，我将在这里省略细节，但是一个重要的区别是，如果你在谈论部署到客户或部署到中间测试或临时系统。 也许有一点让这一点值得在devops上提及，是对在线服务器，服务器群或云的部署有很多挑战。

6. 部署主要是指将可交付，购买和/或自己编程的软件分发给公司及其子公司的数千台PC的管理流程。当然还有专门的工具，包括更新策略，监控，许可证管理等。你来到管理世界，而不是开发者世界。 微服务对管理员来说将是一个新的高挑战，主要用于安装和分发大型的＃34;像MS Office或Oracle一样的软件包。

   • 这个主题对于开发人员来说并不是那么无聊。小学因为这两个世界＆＃34;开发人员和管理员正在合并。开发人员必须关心客户对在现实世界中运行软件的看法＆＃34;。 Devops只是一个开始。每个人都了解虚拟机，但现在我们拥有软件定义网络，虚拟应用程序，虚拟服务器场，云等。您可以通过dependendies定义部署体系结构，而无需通过配置进行任何编程。因此，部署应该是应用程序体系结构的一部分，但主要是它不够（足够）。事实上，直到现在，管理视图几乎与软件生产者/开发者的观点无法整合。关于微软，Windows团队在这方面做了很多工作，尤其是。在服务器产品线中，从未真正与开发团队AFAIK进行战略协调（这可能对于每个软件商店都有效： - ）

目前，许多与devops或连续流行语有关的人都对设置不太熟悉。建筑设置可以被视为其他必要步骤中的一项特殊技术。

鉴于您有兴趣了解有关3.（设置）的更多信息： 如果您不想复制可执行文件，但要具有完整设置的功能，这些功能比复制更多，那么部分安装策略可以是捆绑设置（有时称为套件设置或引导程序设置）自己的选择功能。他们可以调用底层的小设置，例如为你的微服务。

Visual Studio本身不再支持更复杂的安装类型（如MSI），特别是从未将设置分组到捆绑，可能是部署一堆的可能解决方案（或服务的变种 - VS有一些支持＆＃34; ClickOnce＆＃34;部署，但这对于数据库（＆＃34; smart＆＃34;）客户端而言比服务甚至微服务更多。 ClickOnce：https://msdn.microsoft.com/de-de/library/31kztyey.aspx

取代缺乏＆＃34;真实＆＃34; Visual Studio中的安装程序创建可以是 WiX 工具集，它是由Microsoft员工组成的开源项目。或InstallShield Express（这是一个免费的，但商业的有限变体）。 两者都可以创建完整的MSI设置，这可能是Windows安装动物园中最复杂的设置类型。

a）当然除了MSI（又名Windows Installer）之外还有其他设置类型，它们来自第三方供应商，这些供应商或多或少都是专有的，但更简单： Nullsoft - NSIS和InnoSetup。
我不会给出创建单个MSI设置的链接，因为可以通过在下一行创建MSI设置包的给定链接轻松找到它们：

b）中 用于创建设置的工具，用于在Wix＆＃34; world＆＃34;中选择和安装其他（底层的已定义子集）。被称为＆＃34;烧伤＆＃34;：

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

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

c）InstallShield Suite设置： 另一个是已经提到过的工具InstallShield，但是为此你需要他们的 InstallShield Premium 变种，这需要花钱： http://helpnet.installshield.com/installshield21helplib/helplibrary/SteCreatingSuites.htm

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

e）我确信，很多人会建议你去看看 Docker 。 虚拟应用程序不仅是设置，而且它们在安装的＆＃34;中被隔离。来自沙盒等其他应用的状态。 请参阅示例https://docs.docker.com/docker-for-windows/

F） 如果我不提及APP-V作为虚拟应用程序安装技术与docker共享一些但不是所有功能，那么该列表将不完整。但这些技术并非真正用于编排多个交付，而是仅提供一个应用程序。 微软已经定义了一种名为AppX的新安装类型。 特别是你必须有所不同，如果你想创造＆＃34;遗产＆＃34; （完整）适用于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

对于更详细的内容，我们必须了解您的更多要求。