我是 Aure DevOps 的新手。尝试创建构建和发布管道有一件我不明白的事情：
通常，每种构建最终都会产生一些输出，称为工件。
使用 Azure DevOps 似乎总是需要一个最终的复制或发布任务来将创建的工件从 A 复制到 B，因此发布任务可以访问已编译的工件。
为什么这些工件不能直接从它们构建的位置被发布管道访问？为什么构建任务不自动设置一个指向正确文件夹的变量，以便发布管道可以直接从那里访问文件？
或者这已经发生了，我只是从我看过的教程中遗漏了一些东西？
问问题
231 次
2 回答
1
原因有很多。
两个简单的：
- 不能保证代理的工作文件夹仍然包含这些文件。代理在构建和发布之间重复使用，并且给定的构建或发布将始终使用相同的工作文件夹。在构建之间清理工作文件夹。
- 版本可以在不同的代理上运行。在不同的机器上。在不同的领域。或任何组合。无法保证运行版本的代理可以访问运行构建的代理。发布工件可以保证：只要运行发布的机器能够与 Azure DevOps 通信（这是代理首先运行的要求），它就可以获得所需的工件。
于 2019-10-11T00:21:44.647 回答
0
为什么这些工件不能直接从它们构建的位置被发布管道访问？
同意丹尼尔。
对我来说主要原因是因为我们不能一直持有托管代理。由于MS要高效保护资源，所以不会长时间占用。
当我们对构建进行排队时，MS 会为我们分配一个全新的干净代理来执行我们的任务，构建完成后，MS 将回收分配给我们构建的代理并将代理恢复到其初始状态，以准备接受下一个任务的分配。
因此，我们无法保留托管代理以在下一个发布管道中使用它。我们必须将工件存储在云/服务器中，然后我们可以在发布管道中下载它。否则，我们无法从已恢复的代理中获得所需的工件。
此外，MS 是随机分配给代理的，我们不能保证在发布管道期间会分配和构建相同的代理。
这就是我们需要复制或发布工件的主要原因。
如果您不想复制或发布工件，您可以设置自己的私有代理，并且在执行发布管道之前不要清理代理。
更新：
为什么用户会费心手动寻找工件的位置？我本来希望每个构建管道都带有一个个人空间来存储最新的构建工件。Azure DevOps 自动将生成项目复制到的空间。对我来说，似乎必须手动将内容从 A 复制到 B，然后再从 B 复制到 C。
那是因为不是所有的输出都需要，例如测试项目，我们需要的是测试项目的测试结果/代码覆盖率，而不是解决方案的输出。在这种情况下，我们不需要将输出复制到工件。另一方面，我们需要将一些特殊文件复制到 artfacts 中，然后自动复制构建工件将不符合您的要求。
这也是我们提供将文件复制到工件的任务的原因，以便我们可以定制我们的个性需求。
当然，如果您认为手动复制是多余的，您可以使用 MSBuild 参数/p:output=$(build.artifactstagingdirectory)将输出直接设置为工件。
如果我需要在构建管道中将内容从 A 复制到 B，那么应该如何阻止我立即将其复制到 C？如果不是多余的，那么单独的发布管道将是相当可选的。
如果您在构建管道中，还有另一个任务Download build artifacts，它可以下载构建工件。
如果您在发布管道中，您只需选择构建工件作为源，发布管道将自动下载该工件：
查看此文档以获取更多详细信息。
希望这可以帮助。
于 2019-10-14T10:04:25.803 回答