我来自Java Web应用程序的持续集成和持续交付（CI-CD）实现项目背景。现在我正在为一个基于.NET的项目工作。微软技术对我来说是全新的。它通过Jenkins使用MsBuild进行构建过程。我正在学习MsBuild。我读的越多，我对微软这样做的方式就越困惑。
我注意到，将根据部署环境使用各种配置和配置文件为将要部署应用程序的每个环境执行msbuild。以下是针对2种不同环境（PIE＆amp; TEST）的一些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
我可能错了，但我觉得部署到两个环境的代码（当代码从PIE进展到TEST时）正在为每个不是真正的代码进程概念的环境构建。恕我直言，只要代码中没有错误，构建就会完成一次并进入后续环境进行测试/验证。各种环境特定设置通过包内的配置文件处理，容器（java应用程序的tomcat）以读取/解析confif文件的参数启动。
有没有办法在.NET中处理这个问题？该应用程序部署在IIS
中更新：
我越是研究阅读各种文档和博客，我就使用msbuild为每个配置和部署/发布配置文件找到了Web发布方法。这只是质量跟随.net项目的CICD的标准方式吗？
答案 0 :(得分：1)
是的，这是微软实现的，并使用新的Release System强制执行。
基本上你有一个“进程”（Build）构建代码并生成工件（即网站文件结构，nuget包，安装程序等），在这个过程中你通常要处理诸如将版本值应用到程序集之类的事情，minifiying js和css文件或任何与任何特定环境无关的任何内容。
然后你有另一个“进程”（Release）来根据它们将被部署的环境（即从你的网站修改web.config文件）来配置你的工件，并将这些工件部署到所需的环境而不必构建他们又来了。 （即将nuget包推送到一些预生产的nuget feed，将你的网站结构复制到服务器等）
你如何实现这两个“过程”？那么，这取决于您的偏好和工具。如果您使用Visual Studio Team Services，您可以通过基础架构明确定义这些流程，并提供大量内置任务来支持它们。
我没有和Jenkins合作，但只要你可以使用msbuild就可以拥有2个msbuild项目，一个用于根据不同分支上的源代码构建工件，另一个用于基于某些配置部署到不同环境（ei。您的PIE＆amp; TEST）当然您可以使用PowerShell或MSbuild自定义任务等工具来支持流程中的更高级场景。