带有各种环境中代码进度的msbuild

我来自Java Web应用程序的持续集成和持续交付（CI-CD）实现项目背景。现在我正在为基于.NET的项目工作。微软技术对我来说是全新的。它通过Jenkins为构建过程使用了MsBuild。我正在学习MsBuild。我读得越多，我对微软的这种做法就越困惑。带有各种环境中代码进度的msbuild

我注意到，将使用各种基于部署环境的配置和配置文件部署应用程序的每个环境都会执行msbuild。下面是

C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=PIE /m:4 /nr:false src/myapp.sln 

C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=TEST /t:Rebuild /m:2 /p:DeployOnBuild=true /p:PublishProfile=TEST src/myapp.sln 

C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=STAGE /t:Rebuild /p:DeployOnBuild=true /p:PublishProfile=STAGE /m:2 SprintA/src/myapp.sln

我可能是错的2个不同的环境（PIE & TEST）一些MSBuild的命令，但我觉得代码被部署到两个环境（当从PIE编码进度进行测试）正在为每个不是真正的代码进度概念的环境构建。恕我直言，构建只需完成一次，并且只要代码中没有错误，就可以将其发展到后续测试/验证环境。各种环境特定设置通过包内的配置文件处理，容器（用于java应用程序的tomcat）通过读取/解析confif文件的参数启动。

有没有办法在.NET中处理这个问题？该应用程序部署在IIS

UPDATE：我做的研究性阅读各种文档和博客的越多，我碰到使用msbuild每个配置和部署/发布配置Web发布方法。这只是大众对.net项目的CICD所遵循的标准方式吗？

来源

2016-01-22 OK999

是的，这是一个反模式。你可以这样做，如果你使用可憎的MSDeploy，那么它会推动你走下去。进行单一构建的方式要好得多。您需要分离构建位和部署位。 –

是的，这是微软意识到的问题，并使用新的Release System执行。

基本上你有一个“流程”（构建）建立你的代码，并在这个过程中生成工件（即网站文件结构，nuget包，安装程序等），你通常照顾的东西，如应用版本值最小化js和css文件或与任何特定环境无关的任何东西。

然后你有另一个“进程”（发布）来配置你的工件基于他们将部署的环境（即从你的网站修改web.config文件），并部署这些工件到所需的环境，而不必再次构建它们。（即推nuget包到一些预生产nuget饲料，复制你的网站结构到服务器等）

你如何实现这两个“过程”？那么，这取决于你的偏好和工具。如果您使用Visual Studio Team Services，则您可以通过基础架构明确定义这些流程，并提供大量内置任务以支持它们。

我还没有和Jenkins一起工作，但只要你可以使用msbuild，你就可以有2个msbuild项目，它们可以从不同分支上的源代码构建你的工件，另一个基于某些配置部署到不同的环境。你的PIE & TEST），当然你也可以使用powershell或MSbuild自定义任务等工具来支持流程中更高级的场景。

来源

2016-01-24 16:49:38

看起来MS Release Management现在是一个全新的动物吗？而不是像Maven发布管理那样可以通过Jenkins集成的东西。如果这是真的，那就需要移动一些山来说服人们改变。你有什么要求，我可以参考使用MSbuild部署到各种环境，而不涉及构建，即使用预构建工件？ – OK999

带有各种环境中代码进度的msbuild

回答

相关问题