生成管道中的 GitHub Enterprise 支持和自动 GitHub 服务连接 - Sprint 146 更新
在 Azure DevOps 的 Sprint 146 更新 中,我们改进了 GitHub 与 Azure Pipelines 的集成。 现在,“新的生成管道”向导可以为 GitHub Enterprise 存储库创建管道。 它还会分析存储库以提供建议的语言模板。 此外,它可以为所选的 GitHub 存储库创建并重复使用服务连接。
有关详细信息, 请查看下面的功能 列表。
功能
常规:
Azure Boards:
Azure Pipelines:
- 管道向导中的 GitHub Enterprise 支持
- 管道中的自动 GitHub 服务连接
- 显示 GitHub Checks 中每个管道作业的状态
- GitHub 中 YAML 资源的默认授权
- YAML 管道的服务容器
- 版本摘要中与 GitHub 提交关联的工作项
- 针对 YAML 优化的新 Azure 应用服务任务
- 对 Azure SQL 任务的 Azure Active Directory (AD) 身份验证支持
- Grafana 批注服务挂钩
- 查询 Azure Monitor 警报任务
- 部署到 Kubernetes 任务中规范文件的内联输入
- Docker CLI 安装程序任务
- Microsoft 托管代理上的 Java 长期支持 (LTS)
- 用于 Bitbucket 云管道的 YAML 支持
- 避免为拉取请求触发多个 CI 生成
- 更改生成号、在分叉存储库生成中上传和下载项目
- 在发布测试结果任务中使失败测试中的生成失败的新方式
- 汇报 Azure 门户创建 Azure DevOps 项目
- 使用 Azure 门户设置并部署到 CosmosDB 数据库
- 在 Azure 门户中为 Functions 设置生成和发布管道
Azure Artifacts:
Wiki:
常规
还原已删除的项目
在此更新中,我们添加了从 Azure DevOps 门户还原已删除的项目的功能。 如果你有“删除项目”权限,还可以从组织设置>概述页还原已删除的项目。
Azure Boards
使用基本流程简化工作的组织
重要
基本流程以公共预览版提供,作为在美国中部区域创建的新组织内新项目的默认过程。
Agile 一直以来都是新项目的默认流程,它提供一组可靠且灵活的工作项类型和状态,以满足各种项目交付方法的需要。 对于那些更熟悉其他工具或者正在不断发展并希望采用功能更强大的工具集的团队,他们想要使用更熟悉的术语来快速上手。
新基本流程提供三种工作项类型(长篇故事、问题和任务)来计划和跟踪工作。 我们建议使用问题来跟踪用户情景、bug 和功能等事项,使用长篇故事将问题组合到较大的工作单元中。 当你在工作上取得进展时,请按照“待办”、“正在进行”和“已完成”的简单状态工作流移动项目。
请参阅跟踪问题和任务文档,以帮助你开始新项目。
Azure Pipelines
管道向导中的 GitHub Enterprise 支持
以前,可以使用 可视化设计器 为 GitHub Enterprise 存储库创建管道。 现在,还可以使用 “新建生成管道 ”向导来创建管道。
该向导分析 GitHub Enterprise 存储库,以建议与项目语言匹配的 YAML 模板。 然后,可以编辑 YAML 并将其保存为直接提交到默认分支或拉取请求。
有关更多详细信息,请参阅此处创建第一个管道的文档。
管道中的自动 GitHub 服务连接
使用 “新建生成管道”向导为 GitHub 创建管道 时,选择或创建 GitHub 服务连接的页面会导致有关从列表中选择哪个连接感到困惑。 现在,无需选择连接。 向导会自动为所选存储库创建并重新使用服务连接。
如果要手动选择自动选择的连接以外的连接,请按照“选择连接超链接”操作。 有关详细信息,请参阅 生成 GitHub 存储库。
注意
选择基于 Azure Pipelines GitHub 应用 (如果它安装在存储库中)或个人 GitHub 标识(使用 OAuth)。
显示 GitHub Checks 中每个管道作业的状态
以前,即使包含多个平台(例如 Linux、macOS 和 Windows)的作业,单个生成状态也会发布到 GitHub 检查管道。 现在,状态将发布到 GitHub 检查管道中的每个作业。 此外,还可以从 GitHub 检查重新运行整个生成或仅运行单个失败的作业。 若要使用此功能,必须将管道配置为使用 Azure Pipelines GitHub 应用。 有关更多详细信息,请参阅 使用 GitHub 应用集成。 若要为多个平台设置包含作业的管道,请参阅 “创建多平台管道”。
GitHub 中 YAML 资源的默认授权
如果在 GitHub 中管理源代码并使用 YAML 定义管道,则可能遇到资源授权生成失败。 编辑 YAML 文件并添加了对其中一个受保护资源的引用(例如服务连接、代理池、变量组或安全文件),Azure Pipelines 无法验证做出该更改的用户的身份,并且生成失败。 若要解决此问题,在对 YAML 文件进行更改后,必须在 Web 编辑器中保存生成管道。 许多遇到此问题的用户只是希望允许所有管道使用资源。
为了避免资源授权生成失败,我们更改了所有新服务连接、代理池和变量组的默认行为,以授权在所有管道中使用。 如果希望对资源进行更严格的控制,可以禁用默认授权模型(请参阅下图)。 执行此操作时,有权使用该资源的人员必须在将资源引用添加到 YAML 文件后将管道保存在 Web 编辑器中。
YAML 管道的服务容器
以前,如果 YAML 管道使用这些服务,则必须安装、启动和停止数据库或内存缓存等服务。 通过此更新,我们添加了 可以处理这些任务的服务容器 。 例如,如果管道对集成测试使用 redis 缓存,则可以将 redis 容器映像作为服务包含在管道中。 代理会自动提取映像,启动映像并将其网络,以便管道步骤可以通过主机名 redis 来引用它。 管道完成后,代理将完全关闭服务容器。
版本摘要中与 GitHub 提交关联的工作项
12 月,我们引入了将 GitHub 提交链接到工作项的功能。 我们很高兴地宣布,现在可以在发布摘要页中看到链接到 GitHub 提交的所有 Azure Boards 工作项。 这将有助于团队跟踪和检索已部署到环境的提交的详细信息。
针对 YAML 优化的新 Azure App Service 任务
我们现在支持四项新任务,这些任务提供了一种简单而有效的 Azure 应用服务部署方法,适合现代开发人员。 这些任务具有经过优化的 YAML 语法,使你可以简单直观地创作到 Azure AppServices 的部署,包括 Windows 和 Linux 平台上的 WebApps、FunctionApps、WebApps for Containers 以及 FunctionApp for Containers。
我们还支持一个新的实用工具任务,可用于文件转换以及对 XML 和 JSON 格式的可变替换。
对 Azure SQL 任务的 Azure Active Directory (AD) 身份验证支持
我们增强了 Azure SQL 任务,除了现有对 SQL Server 身份验证外的支持外,还使其支持使用 Azure AD(集成和密码)和连接字符串连接到数据库。
Grafana 批注服务挂钩
现在,我们支持一个新的服务挂钩,可用于将部署已完成事件的 Grafana 注释添加到 Grafana 仪表板。 这使你可以将部署关联到在 Grafana 仪表板中可视化的应用程序或基础结构指标更改。
查询 Azure Monitor 警报任务
以前版本的 查询 Azure Monitors 任务 仅支持针对经典监视体验查询警报。 通过该任务的这一新版本,你可以在 Azure Monitor 最近引入的统一监视体验中查询警报。
部署到 Kubernetes 任务中规范文件的内联输入
以前,Kubernetes 部署任务要求提供配置的文件路径。 现在,可通过内联方式添加配置。
Docker CLI 安装程序任务
此任务允许在代理上安装用户指定的任意版本的 Docker CLI。
Microsoft 托管代理上的 Java 长期支持 (LTS)
以前,Microsoft 托管代理预安装了 JDK,这些 JDK 因复杂的许可、最终用户限制和缺乏长期支持而过载。 在此更新中,我们将 JDK 替换为 Azul Systems 中 OpenJDK 的测试、认证、LTS 版本。 现在,使用 Azure 的 Java 开发人员可以使用 OpenJDK 的 Azul Systems Zulu Enterprise 版本生成和运行生产 Java 应用程序,而不会产生额外的支持成本。
此新产品/服务旨在通过整合季度安全更新和 bug 修复以及必要的带外更新和修补程序,使 Microsoft 托管的 Java 版本和部署变得无忧无虑。 如果当前在本地或其他 JDK 上生成或运行 Java 应用,请考虑迁移到 Azure 上的 Zulu,以获取免费支持和维护。 有关详细信息,请参阅博客 Microsoft 和 Azul Systems 为 Azure 提供免费的 Java LTS 支持。
用于 Bitbucket 云管道的 YAML 支持
以前, 基于 YAML 的 管道不支持 Bitbucket Cloud。 现在,可以使用 YAML 来定义 Bitbucket Cloud 管道,也可以使用视觉设计器执行相同的操作。 若要使用 YAML,请将 azure-pipelines.yml 文件添加到存储库。 在 Azure Pipelines 中,依次选择“ 新建生成管道”、“ 使用视觉设计器 超链接”、“Bitbucket Cloud”和“YAML”。 可在此处输入存储库 YAML 文件的路径。
有关详细信息,请参阅 YAML 示例的 YAML 语法指南和 GitHub 存储库。
避免为拉取请求触发多个 CI 生成
Azure Pipelines 随附的 YAML 生成模板配置为触发存储库中任何分支的生成。 这包括拉取请求主题分支。 因此,创建拉取请求时会触发两个生成。 拉取请求分支的一个生成,用于响应持续集成触发器,另一个生成用于拉取请求分支,以响应拉取请求触发器。
通过使用下面的 YAML 代码片段,内置 YAML 模板将配置为仅为 主 分支触发持续集成生成。 新的拉取请求仍将使用拉取请求触发器生成。 有关更多详细信息,请参阅生成管道触发器的文档。
trigger:
- main
更改生成号、在分叉存储库生成中上传和下载项目
到目前为止,拉取请求分叉存储库的验证生成没有上传和下载生成项目或更改生成编号的权限。 权限受到限制,因为它不安全,使代理的范围更广的权限在未知用户触发的分支生成期间可用。 通过此更新,代理权限将限定为作用域,以便管道可以根据需要执行这些操作。
下面是一个 YAML 示例,可用于将 tar.gz 文件中的生成输出存档到项目暂存目录中。 然后,它将输出发布到 Azure Pipelines 以与生成相关联。 有关详细信息,请参阅有关 存档文件任务 和 发布生成项目任务的文档。
- task: ArchiveFiles@2
inputs:
archiveType: 'tar'
tarCompression: 'gz'
includeRootFolder: false
rootFolderOrFile: '$(build.sourcesDirectory)/target'
archiveFile: '$(build.artifactStagingDirectory)/$(build.buildId).tar.gz'
- task: PublishBuildArtifacts@1
inputs:
pathtoPublish: '$(build.artifactStagingDirectory)'
在发布测试结果任务中使失败测试中的生成失败的新方式
使用所选的测试运行程序运行测试时,发布测试结果任务 用于将测试结果发布到 Azure Pipelines。 到目前为止,该任务只会从结果文件发布结果,即使结果文件包含失败的测试,也不会使生成失败。 这意味着你必须编写自定义步骤,使生成在测试失败时失败。
现在,我们已在任务中添加了一个选项,用于在存在任何失败的测试的情况下使生成失败。
汇报 Azure 门户创建 Azure DevOps 项目
Azure 门户现在包含其他功能,用于在创建 Azure DevOps 项目时支持更多框架和服务。 下面是每个区域的更改列表。
框架
Azure IoT 是一项完全托管的服务,可在跨平台 IoT 设备上本地提供云智能。 现在,可以从 Azure 门户创建 Azure DevOps 项目,并使用 Simple IoT 作为应用程序框架。
服务
以前,Azure 门户中的“创建 Azure DevOps 项目”工作流仅支持 “新建 ”作为 Kubernetes 服务的一个选项。 添加了一个新选项,允许选择现有群集作为管道设置的部署目标。
使用 Azure 门户设置并部署到 CosmosDB 数据库
目前,可以使用 Azure 门户中的 Azure DevOps 项目工作流为 Git 存储库设置生成和发布管道。 现在,可以部署到用于容器的 Azure Web 应用(Linux)或Azure Kubernetes 服务,并将 CosmosDB 预配为支持这些目标上的应用的数据库。 这目前适用于所有 Node.js 模板,我们希望将来添加对其他模板的支持。
在 Azure 门户中为 Functions 设置生成和发布管道
现在,可以使用 Azure 门户中的 Azure DevOps 项目工作流为部署 Azure Functions 2.0(Windows)的 Git 存储库设置生成和发布管道。 此功能适用于 Node.js 和 .NET Core。
Azure Artifacts
包使用量统计信息
到目前为止,Azure Artifacts 没有提供一种方法来衡量包的使用情况或受欢迎程度。 通过此更新,我们在包列表和包详细信息页中添加了“下载”和“用户”计数。 可以在其中任一页面的右侧查看这些统计信息。
Wiki
Wiki Markdown 编辑器的等宽字体
随着 wiki Markdown 编辑器中等宽字体的引入,可读性不再是一种挑战。 Markdown 源看起来干净且易于阅读。 此功能基于此建议工单确定优先级。
粗体 Wiki 页面标题
早些时候,Wiki 页面标题和页眉 1 看起来都相同。 这使得读者很难区分它们。 现在,Wiki 页面标题已加粗,与页眉 1 不同。 此功能基于此建议工单确定优先级。
插入 Markdown 表
在 Wiki 中创建 Markdown 表不再是挑战。 现在,可以通过单击按钮添加 Markdown 表。 此功能已根据 此功能建议票证确定优先级。
在 Wiki 中嵌入 Azure Boards 查询结果
你现在可以在 wiki 页面中以表的形式嵌入 Azure Boards 查询结果。 下图显示了 wiki 页面的示例,其中包含已发布的所有功能,以及 wiki 中嵌入的当前冲刺 (sprint) 中所有活动 bug 的列表。 页面中显示的内容使用现有的工作项查询。 利用这项新功能,你可以创建动态内容,而不用费心手动更新 wiki 页面。
可以在两个步骤中添加查询结果
- 单击编辑工具栏中的“查询结果”按钮。
- 选择所需的查询,然后单击“插入”按钮。
现在可以在保存页面后以表的形式查看查询结果。
这已根据以下功能建议确定优先级:
后续步骤
注意
这些功能将在未来两到三周内推出。
阅读以下新功能并转到 Azure DevOps,自行尝试这些功能。
如何提供反馈
我们很想听听你对这些功能的看法。 使用反馈菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获得社区的建议和问题的答案。
此致
杰里米·埃普林