Azure Pipelines发布构件的作用是什么？两种部署方案哪种更优？

发布构件（Publishing Artifacts）的核心作用 #

发布构件的本质是将流水线运行过程中生成的可部署包、编译产物、日志等需要留存的文件，上传到Azure DevOps服务端的专属存储区，与本次流水线运行记录永久绑定，不受代理节点本地文件生命周期的限制。 #

两种实现方案的优劣势对比 #

方案1：包含PublishBuildArtifacts任务 #

- task: ArchiveFiles@2
  inputs:
    rootFolderOrFile: '$(Build.SourcesDirectory)'
    includeRootFolder: false
    archiveType: 'zip'
    archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'  
    replaceExistingArchive: true
    displayName: Archive files

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip' 
    artifactName: 'drop' 
     
- task: AzureFunctionApp@1
  inputs:
    azureSubscription: $(azureSubscription)
    appType: 'functionAppLinux'
    appName: $(appName)
    package: '$(System.ArtifactsDirectory)/**/*.zip'
    displayName: Deploy Azure Function

方案2：跳过发布构件直接部署 #

- task: ArchiveFiles@2
  inputs:
    rootFolderOrFile: '$(Build.SourcesDirectory)'
    includeRootFolder: false
    archiveType: 'zip'
    archiveFile: $(System.ArtifactsDirectory)/build$(Build.BuildId).zip  
    replaceExistingArchive: true
    displayName: Archive files

- task: AzureFunctionApp@1
  inputs:
    azureSubscription: $(azureSubscription)
    appType: 'functionAppLinux'
    appName: $(appName)
    package: '$(System.ArtifactsDirectory)/build$(Build.BuildId).zip'
    displayName: Deploy Azure Function

结论：绝大多数场景下方案1更优，原因如下： #

• 支持多阶段/跨代理流水线：如果后续你要拆分流水线为独立的构建阶段、测试阶段、多环境部署阶段，不同阶段大概率运行在不同的代理节点上，代理节点的本地工作空间是互相隔离的，只有发布为服务端存储的构件，才能被后续阶段下载复用。
• 便于问题排查与版本回滚：如果部署失败或者线上出现故障，你可以直接从对应流水线运行记录里下载当时构建的构件包，直接校验包内容是否正确，也可以直接用历史构件包回滚，不需要重新构建，避免重新构建引入的代码变更风险。
• 符合DevOps最佳实践：遵循「一次构建，多处部署」原则，同一个构件包可以复用在测试、预发、生产等多个环境，不会出现多次构建导致的产物不一致问题。
• 不受代理节点生命周期影响：微软托管代理每次运行完任务就会被销毁，自托管代理也会定期清理工作空间，不发布构件的话，你打包的产物跑完流水线就会丢失，后续无法追溯。

只有在临时测试流水线、不需要留存任何产物、所有任务都运行在同一个代理的同一个作业的场景下，方案2可以节省少量的构件上传时间，没有其他优势，生产环境不推荐使用。 #

内容的提问来源于stack exchange，提问作者Olgaraa