我有一个VSTS项目，目前我正在设置CI / CD。一切都很好，但我似乎有2个选项用于发布步骤：
选项1：作为CI构建的一部分，它是一项任务，例如请参阅此处的构建步骤3： https://medium.com/@flu.lund/setting-up-a-ci-pipeline-for-deploying-your-angular-application-to-azure-using-visual-studio-team-f686c8f190cf
选项2：构建阶段产生工件，作为单独发布阶段的一部分，这些工件已发布，请参见此处： https://docs.microsoft.com/en-us/vsts/build-release/actions/ci-cd-part-1?view=vsts
MS文档中似乎都支持这两个选项，其中一个选项比另一个更好吗？或者是专业人士的案例？每个人的利弊取决于具体情况等等？
谢谢！
答案 0 :(得分：1)
你绝对应该使用＆＃34;选项2＆＃34;。您的构建不应该在您的环境中进行任何更改，这完全是＆＃34;发布＆＃34;是。您在＆＃34;选项1＆＃34;下的链接这是错误的方法，构建应该只是编译代码和制作工件，而不是实际部署代码。
当您将构建/发布一起构建时，您很难调试构建问题。由于您的代码总是被释放，因此您必须禁用＆＃34; deploy＆＃34;步骤以了解部署之前构建的内容。
此外，创建工件的好处是你有一个可部署的软件包，如果将来你需要回滚到以前的工作版本，那么你已经准备好了。使用＆＃34;仅限构建＆＃34;策略，您必须还原您的代码或进行不必要的备份才能实现此目标。
我认为您会发现任何新的Microsoft文档都指向您使用此方法，并且VSTS完全按此设置。甚至是＆＃34;在Azure中配置持续交付......＆＃34; Visual Studio 2017中的功能将创建构建和发布。
答案 1 :(得分：0)
几乎所有构建任务都与发布任务相同，因此您可以在构建过程中构建项目后部署应用程序。
此外，发布和构建之间存在许多差异，例如，许多环境，发布中的部署组阶段。
因此，根据您的详细要求，哪种方式更好，例如，如果构建＆gt;部署＆gt;其他过程很简单，你可以在构建时完成。
关于发布工件任务，它用于将文件发布到VSTS服务器或其他地方（例如共享文件夹），可以在发布中用作工件（点击添加工件＆gt; Build in release definition），你也可以下载它们进行故障排除，例如，如果您使用的是无法访问的托管代理，但是想要获取某些文件（例如构建结果），则可以添加发布工件任务以发布到VSTS服务器，然后下载它们（打开构建结果＆gt;工件）