生成项目和管道项目任务之间有什么区别？
在Azure DevOps中，我们有下载/发布构建工件任务和下载/发布管道工件任务。
构建工件任务和管道工件任务之间的区别是什么？我们什么时候会选择其中一个？
共有1个答案
Azure DevOps GitHub中有一个关于它的问题，Microsoft回答：
大家好——我来自Azure工件团队，我们构建了你们在Azure Pipelines中发现的管道工件特性。
我将解决关于文档的最重要的评论——我们已经有了一个全新的关于Azure Pipelines中的工件的页面，它列出了我们支持的每个工件类型和它们的用途，以及特定文档的链接。我们认为这应该回答了你的大部分问题。
因为在我们发布它之前，它仍在编辑中，所以我想我会给你30，000英尺的视角来看管道工件和构建工件之间的区别，并且提到管道工件如何与通用包相关联。
构建工件（通过发布构建工件任务发布）已在Azure DevOps中存在很长时间，是Azure Pipelines的内置工件存储机制。目前，大多数存储非包工件的构建都可能使用此任务。该任务可以将内容推送到服务器/云，但也可以将文件复制到本地文件共享。
管道工件（使用发布管道工件任务发布）旨在替代构建工件。它们现在处于预览状态，我们还需要做一些事情来达到奇偶校验。管道工件的好处是它们可以大大减少上传和下载大型工件所需的时间。我们首先检查正在上传的内容是否存在于服务中。我们不仅在每个文件级别这样做，而且在子文件级别（最多128K块）也这样做。它可以带来真正显著的性能改进。
Universal Packages（通用软件包）-也在预览中使用与Pipeline Artifacts相同的存储/传输技术。当您想要创建一个生命周期独立于创建它的管道的工件时，您可以使用Universal Packages。您可以在管道通过工件UX完成后下载管道工件，但如果您想要真正独立于管道存在的东西，您可以选择Universal Packages。两者之间不应有性能差异。
希望这能有所帮助。随时提出更多问题，我会继续回答。
-
问题内容： 我认为标题总结了这一点。我只是想知道为什么对于从Svn进行Java项目的持续集成构建而言，一个或另一个更好。 问题答案： 作为CruiseControl的长期提交者 以及 从未使用过Hudson的人，我颇有偏见，但我的看法是： Hudson的安装和运行起来非常容易（很大程度上是通过一个不错的Web界面），并且拥有一个非常活跃的插件开发社区。 CruiseControl获得了很多第三方的
-
我正在处理另一个关于我的构建的问题。gradle需要理解我的Android项目中的工作区项目依赖关系。我已经使用Java和Android有一段时间了，但我仍然很容易对添加依赖项的所有不同方法感到困惑。一种方法是放一个标签。libs/文件夹中的jar文件。另一种方法是具有工作区项目依赖关系。另一种方法（如果使用Android）是在Android选项菜单中添加项目依赖项？我觉得如果我真的理解了为什么会
-
我正在开始使用Azure管道（您将很快从问题中弄清楚），我有一个v.basic构建管道，步骤为Nuget= 作业完成了，但是它做了什么吗？构建的输出应该是< code > $(build . artifactstagingdirectory)\ web app . zip 。我可以检查这个文件是否存在吗？我有一个发布管道，它将这个构建管道作为其工件的来源。它当前失败，出现错误“错误:未找到具有指定
-
对于我的新JAVA应用程序，我希望开始使用IntelliJ创建一个新的JSF2.2项目。该项目将是一个web应用程序，并将使用Maven。
-
我有一个非常基本的多项目分级设置，如下所示： 文件包括这两个子项目。根项目不应用java插件，但两个子项目都应用了。使用时，所有东西都按预期生成。 但是，据我所知，由于我没有在根项目中应用插件，因此它不应该有任务。 的输出显示任务。 但的输出只显示列有和。 所以我的问题是--在这个场景中到底执行了什么？gradle只是找到所有子项目中匹配供应模式的每一个任务吗？是否有关于此任务名称解析的特定规则？
-
创建人可对项目进行管理，包括修改项目信息，添加项目成员，关闭项目等。项目成员对项目有一定操作权，但不可关闭项目。