小编hit*_*126的帖子

我们的组织内有许多项目。其中一个项目创建了一个项目范围的 Azure Artifact 源，他们希望与我们的其他项目共享。

但是，当其他项目访问其工件页面时，从提要下拉列表中，他们只能看到“组织范围的提要”，而“项目范围的提要”下没有任何内容。我们需要做什么才能使此源可见并可供其他项目使用，特别是在他们的管道中使用。

我很茫然，因为到目前为止我完全一片空白。

我正在努力寻找 Az-Cli 命令来注册或创建 Azure AD B2C 应用程序。有人能指出我正确的方向吗？

顺便说一句，我也不介意将 Azure Powershell 作为可能的解决方案。

我们计划很快从本地 TFS 实例迁移到 VSTS。在迁移之前，我们运行先决条件验证任务并获得以下关于 TPC 数据库大小的输出报告：

“数据库当前为 191GB。这高于使用 DACPAC 导入方法的 150GB 的推荐大小。目前最大的表大小为 172GB。这高于使用 DACPAC 导入方法的 20GB 的推荐大小。

验证完成“验证集合数据库大小”，结果为警告，消息最大表大小当前为 172GB。这超出了使用 DACPAC 导入方法的 20GB 的推荐大小。”

因此，我们热衷于减少 TPC 数据库的大小，并有两个主要考虑：

1. 缩小数据库并从结果输出生成 DACPAC。

2. 删除以下任何未使用或冗余的对象：

   a) 较旧的工作区
   b) 构建结果
   c) 冗余团队项目
   d) 未使用的文件
   e) 在测试运行期间创建的测试附件
   f) XAML 构建
   

因此，希望能就这两种方法的优缺点提供一些建议或反馈，并建议采用哪种方法。

我希望在 Azure Pipeline 任务中运行一些 CURL 命令（主要是 GET），以从几个来源列出/下载一些工件。如果有任何关于如何使用 CURL、Powershell、Windows 命令或任何其他适当方法通过管道任务实现此目的的示例，我将不胜感激。

谢谢

我们目前有 4 个 Azure DevOps 团队项目，需要为其 SIT 和 UAT 发布管道创建两个部署组。所有 4 个团队项目将共享两个部署组，其想法是从一个团队项目创建部署组，然后共享或扩展到其他 3 个项目（我认为这是常见做法）。

但我主要担心的是，由于一些预算限制，我们决定在单个目标服务器上创建 SIT 和 UAT 部署组。尽管我坚信这可能不是最佳实践，但是否有任何技术原因导致这不能或不应该实施？

我们在 Azure 中的 terraform 远程状态文件已被完全破坏，我们现在面临着从头开始重新创建状态文件的挑战。我的选择是使用 Terraform 导入命令，使用以下简单语法：

terraform import <Terraform Resource Name>.<Resource Label> <Azure Resource ID>

例如，要导入现有资源组，我将在 main.tf 文件中创建以下配置。

provider "azurerm" {
    version="1.39.0"
}

# create resource group
resource "azurerm_resource_group" "rg"{
    name = "rg-terraform"
    location = "uksouth"
}

现在，我遇到的问题如下：

当现有的 Azure 资源最初创建时，它们被分配的名称使用了极其复杂的命名约定，有些字符甚至是随机生成的。更复杂的是，它们都是独一无二的，而且有数百个。如果为它们分配一个像“main”这样的简单名称（正如许多 Terraform 示例中常用的那样），那么一切都会很美好，但不幸的是，情况并非如此。

因此，我的问题是：

1. 将我的 main.tf 配置文件放在一起以用于导入时，是否绝对要求我的“资源标签”（在导入命令中给出）必须与创建资源时的原始“资源标签”名称相匹配？

2. 如果这是强制性要求，是否有任何方法可以从 Azure 检索原始“资源标签”，就像我可以从 Azure 门户甚至 Az CLI 查询获取“Azure 资源 ID”一样？

3. 如何确保导入中包含任何子资源（例如子网），而无需手动通过 Azure 门户进行搜索来识别其中的每一项？

我需要将一个任务合并到我的 VSTS 构建定义中，该任务执行许多我能够在 Postman 中成功运行的 cURL 命令。

本质上，我有许多 cURL 命令执行以下各自的任务：

1. 通过随机生成的访问令牌登录到应用程序数据库。
2. 获取保存在数据库中的解决方案 ID 列表。
3. 从选定的解决方案 ID 中，检索存储文件的列表。

为简洁起见，我不会列出整个任务集，但我相信以上内容很好地说明了此要求的含义。

仅使用上述三个场景，因此我想要设置的是三个 cURL 命令，它们可以转换为三个单独的 VSTS 构建定义任务，使用 cURL 作为语言类型，或任何其他 VSTS 支持的脚本语言。