Question

用这个相当长的问题来解释：

为什么在与服务配置结合使用时，您的项目需要多于2个构建配置？

我有一个云服务，其中包含多个网站，需要部署到多个不同的Azure平台上，一个用于测试，一个用于UAT，一个用于实时。

每个环境都需要为其部署的网站定义不同的主机头，例如test.myportal.com，test.myservice.com，uat.myportal.com，uat.myservice.com，live.myportal.com和live.myservice.com。

这意味着我需要为每个环境定义一个ServiceDefinition，到目前为止很好。

在之前的相关问题中我看过（Azure: Is there any way to deploy different instance sizes for test/production，Azure connection string best practices（第4步，并在.ccproj文件中使用$(Configuration)而不是$(TargetProfile)）提到你需要X配置（意思是构建配置）。这对我来说没有意义，因为我只需要两个构建配置（Debug和Release）来构建代码的方式，而不是服务的配置方式。而是我需要的是三种服务配置。

我的问题是，我是否正确认为构建配置应仅用于构建代码的方式以及为服务配置创建多个不同构建配置的人员是错误的？（我承认，这不是最好用的词）

为了进一步解释我是如何围绕这个实现解决方案的，我将继续下面：

我正在为MSBuild配置我的CI构建服务器，以便在TargetProfile旁边添加一个额外参数Configuration。

我的环境的MSBuild命令如下所示：

对于测试：

msbuild mySolution.sln /p:TargetProfile=Test /p:Configuration=Debug

对于UAT

msbuild mySolution.sln /p:TargetProfile=UAT /p:Configuration=Debug

直播

msbuild mySolution.sln /p:TargetProfile=Live /p:Configuration=Release

对于我的云服务，我使用三个ServiceDefinition.csdef文件，每个环境对应一个文件：ServiceDefinition.Test.csdef ServiceDefinition.UAT.csdef ServiceDefinition.Live.csdef。这些保存在'/ config /'文件夹中。

在我的云服务器ccproj文件中，我只有两个配置，调试和发布，BeforeBuild中有一个任务：

<Target Name="BeforeBuild">
  <Copy SourceFiles="configs\ServiceDefinition.$(TargetProfile).csdef" DestinationFolder="$(OutputPath)" />
  <Move SourceFiles="$(OutputPath)ServiceDefinition.$(TargetProfile).csdef" DestinationFiles="$(OutputPath)ServiceDefinition.csdef" />
</Target>

然后确保我只需要两个构建配置，但只需更改我传递给MSBuild的TargetProfile参数即可拥有尽可能多的服务配置。

重新提出我的问题：

我是否正确地认为构建配置应仅用于构建代码的方式，以及为服务配置创建多个不同构建配置的人员是错误的？

Answer 1

不同构建配置的一个可能用例可能是需要将服务部署到具有不同功能集的不同客户的多个产品平台。在这种情况下，出于性能和安全原因，构建过程可能有必要定制各个功能集（例如，通过使用C＃预处理器指令）。

Azure构建配置与服务配置

1 个答案: