在 Azure DevOps 中管理组织计费 - Sprint 150 更新
在 Azure DevOps 的 Sprint 150 更新 中,我们添加了在门户中管理组织计费的功能。
在新的计费选项卡中,可以选择用于计费的 Azure 订阅,并为其他用户付费。 不再需要转到 Visual Studio 市场或Azure 门户来管理计费。
有关详细信息,请查看下面的 功能 列表。
功能
常规:
Azure Boards:
Azure Repos:
Azure Pipelines:
- Kubernetes 清单任务
- 升级到 Docker 任务
- Kubectl 工具安装程序
- Docker 注册表服务连接中的Azure 容器注册表
- 托管 Ubuntu 池上的 cgroup 支持
- 运行一次代理
- 支持 Visual Studio 测试任务中的 Visual Studio 2019 (VS2019)
- 代理池用户界面更新
- 用于编辑 YAML 文件的任务助手
- 托管管道映像更新
- ServiceNow 集成的改进
- 支持Azure PowerShell Az 模块
- 资源授权改进
- 简化生成管道的保留策略
- 在发布中自动提取的管道项目
- Cobertura 代码覆盖率报告更新
报表:
Wiki:
管理:
常规
深色主题正式发布
去年 10 月,我们发布了深色主题的公共预览版,作为新导航的一部分。 经过几个月的预览、听取反馈和优化体验,我们很高兴地宣布深色主题正式发布。
通过 Azure DevOps 管理组织的帐单
我们很高兴地宣布,你现在可以从 Azure DevOps 门户管理组织的计费。 管理员不再需要通过Azure 门户设置计费。 若要管理计费设置,请转到 “组织设置” ,然后选择“ 计费”。
下面是可从“ 计费 ”选项卡管理的设置列表。
可以选择用于计费的 Azure 订阅。
可以通过选择其他订阅来更改组织用于计费的 Azure 订阅。 以前,必须删除计费,然后仔细重新购买每个付费资源( (基本用户、包管理用户、MS 托管管道等)的相同级别...) 。此过程繁琐且容易出错。 现在,可以通过选择其他订阅并单击“保存”来更改组织用于计费的 Azure 订阅。
不再需要转到 Visual Studio Marketplace 来管理计费设置。 我们添加了支付额外基本、测试管理器和包管理 (Azure Artifacts) 用户的功能。 可以通过新的“ 计费 ”选项卡增加或减少组织正在支付的用户数。
Azure Boards
基于 Azure Active Directory 组的查询工作
随着 Azure Active Directory 的日益采用和使用组来管理安全性的普及,团队越来越多地寻找在Azure Boards中利用这些组的方法。 现在,除了使用 “组内 ”或“ 不在组 内”运算符查询特定人员分配或更改的工作项外,还可以直接使用 Azure Active Directory 组。
有关详细信息,请参阅 查询运算符 文档。
使用徽章共享团队的版块
存储库的自述文件通常是项目团队查找的主页,以获取有关如何为解决方案做出贡献和使用的信息。 现在,就像在 Azure Pipelines 中使用生成或部署状态一样,可以在 Azure Boards 中为团队董事会添加徽章。 可以将锁屏提醒配置为仅显示“正在进行”列或所有列,甚至可以在项目开放源代码时公开显示锁屏提醒。
如果自述文件基于 Markdown,只需从状态锁屏提醒设置页复制示例 Markdown 并将其粘贴到文件中。
查询与日、周、月或年开始时间相关的工时
虽然团队通常专注于在下一个即将发生的情况或基于冲刺迭代的情况下工作,但通过日历的视角回顾工作,报告上个月或今年第一季度发生的所有工作通常很有趣。 现在,可以使用以下新的 @StartOf 宏集以及任何基于日期的字段,以便基于日、周、月或年的开始时间进行查询:
- @StartOfYear
- @StartOfMonth
- @StartOfWeek
- @StartOfDay
其中每个宏还接受一个新的修饰符字符串,该字符串允许按不同的日期单位移动数据。 例如,可以通过查询状态更改日期 = 和<@StartOfYear(“+3M”)状态更改日期 >= @StartOfYear 来编写查询来查找今年第一季度完成的所有工作项。 有关详细信息,请参阅 查询宏 文档。
将查询结果导出到 CSV 文件
现在可以直接从 Web 将查询结果导出到 CSV 格式化文件。
Azure Repos
用于完成拉取请求的新合并类型
现在,在将更改从拉取请求合并到目标分支时,有更多选项。 我们在开发者社区添加了对两个最需要的功能的支持:快进合并和半线性合并 (也称为“变基和合并”) 。
现在,你将在“ 完成拉取请求 ”对话框中看到这些新选项:
更新的策略管理页允许管理员控制分支或分支文件夹中允许的合并策略。
注意
仍会强制实施现有策略。 例如,如果分支当前具有“仅 squash merge”策略,则必须编辑该策略才能使用新的合并策略。
在某些情况下,无法在拉取请求完成期间重新设置基数:
- 如果目标分支上的策略禁止使用重基策略,则需要“替代分支策略”权限。
- 如果拉取请求的源分支具有策略,则无法对其进行重定基。 重新设置基数将修改源分支,而无需完成策略审批过程。
- 如果已使用 合并冲突扩展 来解决合并冲突。 应用于三向合并的冲突解决方法很少成功, (甚至有效的) 一次重新设置所有提交拉取请求的基数。
在所有这些情况下,你仍可以选择在本地重定分支基并推送到服务器,或者在完成拉取请求时压缩合并更改。
Azure Pipelines
Kubernetes 清单任务
我们在发布管道中添加了一个新任务,以简化使用清单文件部署到 Kubernetes 群集的过程。 与在脚本中使用 kubectl 二进制文件相比,此任务具有以下优势:
项目替换 - 部署操作将容器映像列表作为输入,该列表可以连同其标记或摘要一起指定。 在将清单文件应用到群集之前,将其替换为清单文件的非模板版本,以确保群集的节点拉取正确的映像版本。
清单稳定性 - 针对部署的 Kubernetes 对象检查推出状态,以合并稳定性检查,同时将任务状态计算为成功/失败。
可跟踪性注释 - 注释添加到已部署的 Kubernetes 对象,以叠加有关原始组织、项目、管道和运行的可跟踪性信息。
烘焙清单 - 任务的烘焙操作允许将 Helm 图表烘焙到 Kubernetes 清单文件中,以便可以将其应用于群集。
部署策略 - 选择具有部署操作的 Canary 策略会导致创建后缀为 -baseline 和 -canary 的所需百分比工作负载,以便在任务期间
ManualIntervention
比较它们,然后再利用任务的提升/拒绝操作最终确定要保留的版本。
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
helmChart: charts/sample
overrides: 'image.repository:nginx'
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
containers: |
nginx: 1.7.9
升级到 Docker 任务
我们升级了 Docker 任务以简化管道创作体验。 buildAndPush 命令现在可用于为特定容器存储库生成多个标记,并通过一个步骤将其推送到多个容器注册表。 该任务可以使用 Docker 注册表服务连接登录到容器注册表。 有关源存储库、提交和生成来源的可跟踪性元数据作为标签添加到使用此任务生成的映像。
steps:
- task: Docker@2
displayName: Container registry login - ACR1 service connection
inputs:
command: login
containerRegistry: acr1
- task: Docker@2
displayName: Container registry login - ACR2 service connection
inputs:
command: login
containerRegistry: acr2
- task: Docker@2
displayName: Build and push images
inputs:
repository: test
tags: |
d1
d2
Kubectl 工具安装程序
我们添加了一个新任务,可用于在代理上安装特定版本的 Kubectl 二进制文件。 最新和 semver 版本字符串(如“v1.14.0”)被接受为 Kubectl 版本规范输入的有效值。
Docker 注册表服务连接中的 Azure 容器注册表
现在,可以从项目的设置页创建 Docker 注册表服务连接。 若要创建连接,请在与 Azure Active Directory (Azure AD) 标识关联的订阅之一中选择一个 Azure 容器注册表。 需要服务连接到容器注册表(如 Docker@2 和 KubernetesManifest@0) 的所有任务都支持通过单一方式指定连接。
托管 Ubuntu 池上的 cgroup 支持
在 Linux 上,当内存使用率过高时,内核将终止某些进程以保护其余进程。 如果选择 Azure Pipelines 代理进程终止,管道运行将失败,并显示有关失去与代理的通信的错误消息。 在 Microsoft 托管的 Ubuntu 池中,我们通过在自定义 cgroup 中运行步骤来减少代理终止的可能性。 如果超出可用内存,管道仍可能失败,但代理进程更有可能幸存下来并正确报告故障。 如果运行专用 Linux 代理,我们已 发布 我们使用的设置,以便你可以考虑类似的设置。
运行一次代理
如果使用 Azure 容器实例 等基础结构来运行弹性专用代理,通常希望每个代理在离开前只接受一个作业。 到目前为止,这并不容易,因为必须终止代理 (可能导致) 报告失败,或者接受代理可能收到另一个作业的风险,然后才能将其关闭。 在此更新中,我们向代理配置添加了 --once 标志。 以这种方式配置代理时,它将只接受一个作业,然后自行关闭。
Visual Studio 测试任务中对 Visual Studio 2019 (VS2019) 的支持
我们已向管道中的 Visual Studio 测试任务添加了对 VS2019 的支持。 若要使用 VS2019 的测试平台运行测试,请从“测试平台版本”下拉列表中选择 “最新 ”或“ Visual Studio 2019 ”选项。
代理池用户界面更新
项目设置中的代理池管理页已使用新的用户界面进行了更新。 现在,可以轻松查看池中运行的所有作业。 此外,还可以了解作业未运行的原因。
用于编辑 YAML 文件的任务助手
我们不断收到大量反馈,要求更轻松地编辑管道的 YAML 文件。 在以前的更新中,我们添加了 Intellisense 支持。 现在,我们要将任务助手添加到 YAML 编辑器。 这样,你将获得与在经典编辑器中相同的熟悉体验,将新任务添加到 YAML 文件。 此新助手支持大多数常见的任务输入类型,例如选取列表和服务连接。 若要使用新任务助手,请在基于 YAML 的管道上选择“编辑”,然后选择“任务助手。
托管管道映像更新
我们很高兴地宣布将托管 macOS 池 更新到 OS X Mojave (10.4) 其中还包括对 Xcode 10.2 的支持。 如果基于设计器的管道使用 托管 macOS 池,则管道将自动升级到 Mojave。 如果想要继续使用 OS X High Sierra (10.3) ,请将运行生成的池更改为 Hosted macOS High Sierra。
如果使用 YAML,可以使用的新 vmImage 标签如下:
- 始终指向最新版本的 macOS(当前为 10.4)的图像标签
vmImage: 'macOS-latest'
- 如果想要确保管道针对 Mojave 运行,此映像标签专门针对 mac OS 10.4
vmImage: 'macOS-10.4'
- 如果想要确保管道针对 High Sierra 运行,将专门面向 mac OS 10.3 的图像标签
vmImage: 'macOS-10.3'
我们还更新了托管 Azure Pipelines 的 Windows Server 2019 映像。 可 在此处找到最新版本。 此更新包括 VS2019 预览版、Docker、PowerShell Core、Node.js、npm 等的新版本。
有关托管 macOS VM 映像中包含的内容的详细信息,并了解映像上可用的工具,请访问 GitHub 上的 映像生成存储库 。
ServiceNow 集成的改进
去年 12 月,我们发布了 ServiceNow Change Management 与发布管道的集成。 跨团队协作的一项关键功能,使每个团队都能使用自己选择的服务,并具有有效的端到端交付。 通过此更新,我们增强了集成,以支持 (正常、标准和紧急) 的所有类型的更改。 此外,你现在可以根据组织中遵循的 ITSM 流程,指定用于使用现有模板创建新更改请求的入口。 最后,还可以根据现有更改请求限制发布。 这使你能够采用 CD,而无需更改 IT 团队建议的过程。
支持Azure PowerShell Az 模块
Azure PowerShell提供了一组 cmdlet,可用于从命令行管理 Azure 资源。 去年 12 月,Azure PowerShell Az 模块可用,现在是用于管理 Azure 资源的目标模块。
以前,我们未在托管代理中提供对 Azure PowerShell Az 模块的支持。 随着生成和发布管道中的新 Azure PowerShell 任务版本 4.*,我们添加了对所有平台的新 Az 模块的支持。 Azure PowerShell任务版本 3.* 将继续支持 AzureRM 模块。 但是,为了跟上最新的 Azure 服务和功能,我们建议你尽快切换到Azure PowerShell任务版本 4.*。
Az 模块具有兼容性模式,可帮助你在更新现有脚本以使用新语法时使用现有脚本。 若要启用 Az 模块的兼容性,请使用 Enable-AzureRmAlias
命令。 别名允许在 Az 模块中使用旧的 cmdlet 名称。 可在此处获取有关从 Azure RM 模块迁移到 Azure PowerShell Az 模块的详细信息。
注意
如果使用专用代理,则需要在代理计算机上安装 Az 模块。
有关 Azure PowerShell Az 模块的详细信息,请参阅此处的文档。
资源授权改进
我们需要为受保护的资源提供安全性, (例如,在 YAML 文件中引用时,服务连接、变量组、代理池、安全文件) 。 同时,我们希望更轻松地设置和使用这些类型的资源的管道,以用于非生产方案。 以前,我们添加了一个设置,用于将资源标记为“已授权在所有管道中使用”。
通过此更新,即使尚未将资源标记为此类资源,我们也能更轻松地解决资源授权问题。 在新体验中,当生成因资源授权错误而失败时,你将看到一个选项,用于显式授权在管道中使用这些资源,然后继续。 有权授权资源的团队成员将能够直接从失败的生成中完成此操作。
简化生成管道的保留策略
我们简化了所有生成管道(包括 YAML 生成)的保留模型。 项目级别有一个新设置,可用于控制要保留每个管道生成的天数,以及要保留每个生成的项目的天数。 如果使用经典编辑器创建生成管道,则旧版保留设置将继续使用,但较新的管道将使用新设置。 可以在项目设置的管道设置页下管理保留期。
在发布中自动提取的管道项目
以前,如果链接到发布的生成管道使用 发布管道项目 任务发布了项目,则不会在发布中自动提取项目。 相反,你必须在发布管道中显式添加 “下载管道项目 ”任务才能下载项目。
现在,生成管道发布的任何管道项目都将自动下载并在发布中提供。 还可以从发布管道的阶段属性自定义管道项目的下载。
Cobertura 代码覆盖率报告更新
以前,在管道中运行测试并将代码覆盖率结果发布到 Azure DevOps 时,需要同时指定 XML 摘要和 HTML 报告文件。 此外,HTML 报表中的样式在代码覆盖率选项卡中呈现之前已删除。从安全角度来看,这种样式删除是必要的,因为可以上传任意 HTML 文件。
通过此更新,我们解决了 Cobertura 覆盖率报告的这些限制。 发布代码覆盖率报表时,不再需要指定 HTML 文件。 报表是自动生成的,并在代码覆盖率选项卡中以适当的样式呈现。此功能使用开放源代码工具 ReportGenerator。
报表
生成失败和持续时间报告
必须提供指标和见解,以便不断提高管道的吞吐量和稳定性。 作为提供管道分析的第一步,我们添加了两个报表来提供有关管道的指标和见解。
失败报告将显示生成通过率和失败趋势。 此外,它还会显示任务失败趋势,以提供有关哪些任务导致最大失败数的见解。
持续时间报表将包含管道持续时间及其趋势。
Analytics 正式发布
我们很高兴地宣布,Azure DevOps 中将包含以下分析功能,无需额外付费。
分析小组件是可配置的模块,可在仪表板上显示数据,并帮助你监视工作进度。 包括的小组件如下:
燃尽图和燃尽 图可监视一段时间内一组限定范围的工作的进度。
周期时间和提前期 ,用于可视化工作如何通过团队的开发周期
累积流程图 (CFD) 跟踪工作项通过各种状态的进度。
速度 跟踪团队如何在多个冲刺中交付价值。
测试结果趋势 :监视测试趋势,检测单个或多个管道测试的失败和持续时间模式。
在产品中,我们将包括 失败排名靠前的测试报告 ,以获取有关管道中失败排名靠前的测试的见解,以帮助提高管道可靠性并减少测试债务。
我们还将继续为所有Azure DevOps Services客户提供通过分析视图和直接访问 OData 终结点预览版的 Power BI 集成。
如果使用 Analytics 市场扩展,则可以像以前一样继续使用 Analytics,无需执行任何其他步骤。 这意味着我们将为托管客户弃用 Analytics 市场扩展 。
Azure DevOps Analytics 产品/服务是报告的未来,我们将继续投资于 Analytics 驱动的新功能。 可以在以下链接中找到有关 Analytics 的详细信息。
Wiki
Wiki 页面上的通知
直到现在,你还没有办法知道 Wiki 页面上的内容何时发生更改。 现在,您可以关注 Wiki 网页,在编辑、删除或重命名页面时通过电子邮件获得通知。 若要跟踪对 Wiki 所做的更改,请在 Wiki 页面中选择“ 关注 ”按钮。
此功能已基于 此 建议票证确定优先级。 若要了解详细信息,请参阅 此处的文档。
管理
通过 Azure DevOps 管理组织的帐单
我们很高兴地宣布,你现在可以从 Azure DevOps 门户管理组织的计费。 管理员不再需要通过Azure 门户设置计费。 若要管理计费设置,请转到 “组织设置” ,然后选择“ 计费”。
下面是可从“ 计费 ”选项卡管理的设置列表。
可以选择用于计费的 Azure 订阅。
可以通过选择其他订阅来更改组织用于计费的 Azure 订阅。 以前,必须删除计费,然后仔细重新购买每个付费资源( (基本用户、包管理用户、MS 托管管道等)的相同级别...) 。此过程繁琐且容易出错。 现在,可以通过选择其他订阅并单击“保存”来更改组织用于计费的 Azure 订阅。
不再需要转到 Visual Studio Marketplace 来管理计费设置。 我们添加了支付额外基本、测试管理器和包管理 (Azure Artifacts) 用户的功能。 可以通过新的“ 计费 ”选项卡增加或减少组织正在支付的用户数。
后续步骤
注意
这些功能将在未来两到三周内推出。
前往 Azure DevOps 并查看。
如何提供反馈
我们很想听听你对这些功能的看法。 使用反馈菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获得社区的建议和问题的答案。
此致
杰里米·埃普林