标签: azure-pipelines-release-pipeline

我正在通过 Azure DevOps 中的 DACPAC 版本管理 SQL Server 数据库。我的项目目前正在开发中，但我预计在产品上线后开发会继续进行。

默认情况下，如果即将发生数据丢失，尤其是在 Prod 中，我将发布配置设置为 b0rk - 大多数更改不应导致它，而且我的直觉是，总体数据丢失更有可能表明存在错误，而不是错误故意放弃数据。

但自然地，我预计在某些情况下迁移会故意丢弃数据，这是预期的并且可以接受。

我希望以一种可控且稳健的方式来设置 DevOps，以便我能够实现这一目标。实现这一目标的最佳方法是什么？

我的理想本质上是“是的，部署这个版本……是的，我知道这会导致数据丢失，没关系。”

我有一个想法，我会将其作为答案发布。但我正在寻找其他想法，或任何“标准”或“官方”方法。（或者只是更好的想法：D）

我正在查看天蓝色触发器文档，但仍然无法找到合适的解决方案。在管道 1 执行过程中，如何触发管道 2，等待其成功完成或失败，并根据管道 2 的结果继续执行管道 1 或失败？

作为Azure DevOps - 处理 UI 和 Dotnet API 层的单独代码存储库的单一版本的延续，我尝试通过在存储库下定义它来继续检查 yaml 中的多个存储库，如下所示。我无法理解在哪里更改分支以确保我的结帐等任务不会发生在主分支上，而是发生在我的自定义分支上。

resources: 
repositories:
  - repository: mybitbucketrepo
    type: bitbucket
    endpoint: myserviceconnection
    trigger:  # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos)
      branches:
        include: [ custom-branch ]
    name: orgname/reponame

到目前为止我尝试过的方法如下，但出现错误 - 仅支持“self”、“none”或存储库别名。任何帮助将不胜感激。

- checkout: mybitbucketrepo@custom-branch

我正在致力于从旧的手动实现的 ci/cd 解决方案到 Azure DevOps 的管道迁移。我仍在重用一些预构建的函数/流程。

例如。就像他们如何将所有解决方案打包为工件一样。

我试图尽可能减少代码更改。

构建管道创建 ClickOnce 包.zip。

然后在发布阶段，myapp.exe.config应用程序文件中的内容通过 XML-Document-Transform 进行转换。此外，应用程序清单<ApplicationName>.application也是通过 Powershell 手动编辑的。<deploymentProvider codebase="http://1.1.1.1/samplefolder/myapp.application" />根据要部署到的环境/路径，发布时会发生变化。

申请清单

<asmv1:assembly ...>
<deployment ...>
    <subscription>
      <update>
        <beforeApplicationStartup />
      </update>
    </subscription>
    <deploymentProvider codebase="http://1.1.1.1/samplefolder/myapp.application" />
</deployment>
</asmv1:assembly>

现在我明白这种方法需要对整个包进行重新签名。他们有一个自定义.exe 文件来重新签名整个包（不是mage.exe）。不幸的是，我无法重复使用上述可执行文件来重新签名。

我所拥有的只是他们的证书指纹。但我不知道该怎么办。

问题：

1. 重新签署包裹还有哪些其他选择？
2. 有一个更好的方法吗？我是否需要为此解决方案执行另一个构建步骤？

我有以下场景：

updates branch develop -> triggers DEV-CI -> triggers Release X
updates branch master -> triggers QA-CI -> triggers Release X
updates branch release -> triggers Prod-CI -> triggers Release X

在“Release X”中，我添加了所有 3 个工件（dev、qa 和 prod）和 3 个独立的阶段（dev、qa 和 prod）。我的目标是，如果分支开发更新，则发布到 DEV，如果主分支更新，则发布到 QA，依此类推，但发布管道不会启动，因为它需要所有 3 个工件都可用。

仅当我只有一对一时它才有效，如下所示：

如果我添加其他工件，即使在每个特定工件的预部署条件中添加工件过滤器之后，发布也不会开始，直到所有 3 个工件都可用。

是否可以做我在这里尝试的事情，或者我必须为每个 CI 创建一个版本？

谢谢！

编辑

听完李老师的回答，我又试了一次，还是不行。即使只运行了 QA CI，这两个环境都会被触发。

结果是这样的：

这里 QA 版本正在下载两个工件，即使有一个特定的工件过滤器：

这是生成该结果的设置：

要求是对需要在 Azure DevOps 发布管道中进行身份验证的网站执行 OWASP ZAP 扫描。无法找到对经过身份验证的网页执行此操作的方法。请指导我。我可以从 Azure DevOps 市场找到使用 OWASP ZAP 扫描仪扩展的方法，但无法找到有关如何在管道中使用身份验证进行配置的正确说明。

提前致谢。

首先 - 我知道根据 MS 官方文档，通过部署控制更新具有发布状态的工作项的内置功能仅在发布管道中受支持，而不是多阶段 YAML 管道（请参阅此处记录的第一个注释：https: // /learn.microsoft.com/en-us/azure/devops/boards/work-items/work-item-deployments-control?view=azure-devops）

是否有人使用 powershell 或 Azure DevOps Rest api 创建插件或集成，可以使用正确的信息更新工作项，以自动将工作项链接到发布环境信息，因为此功能似乎不适用于yaml 发布管道？

我有一个 shell 脚本，用于将容器部署到 Azure 容器实例，该脚本使用 Azure CLI（在 Linux 上）在本地运行良好，但我在从管道任务执行登录到 Azure 时遇到问题。

在本地，以下命令将打开浏览器进行登录：

docker login azure

文档建议，要在管道任务中执行相同的操作，我可以传入客户端 ID 和客户端密钥。我认为它应该看起来像这样：

docker login azure --client-id $servicePrincipalId --client-secret $servicePrincipalKey --tenant-id $tenantId

但是，当我在管道中运行它时，我收到此错误：

unknown flag: --client-id

docker login azure --helprun local 告诉我这--client-id是一个有效的标志，所以我想知道是否有另一种方法可以在 Azure DevOps 管道中执行此操作？

我有一些嵌入式C软件存储在TFS下,并且还有一个相应的TFS构建定义,可以成功检出代码并使用相关的编译器构建它.所以要明确一点,虽然这是TFS,但我没有构建.NET应用程序.

现在我已经构建了工作,我正在尝试提供整体软件版本控制支持,这应该与构建过程相关联.我目前的目标如下:

正在构建的源代码有一个头文件,其中包含三个变量的#defines,Major Version,Minor Version和Build Number.然后,此头文件用于在编译时将版本号烘焙到软件中.概念是开发人员负责仅更新主要版本号和次要版本号作为开发的一部分.内部版本号始终保持为0,并且不应由开发人员修改.

在开发人员在自己的机器上本地生成构建的实例中,主要版本和次要版本将按照代码中的定义进行设置,但构建编号将保持为0,这表示不受控制的构建.但是,对于服务器上的官方构建,我希望TFS自动增加构建号,以便指定相同主要版本和次要版本的后续构建会导致构建号的增量,以提供整体唯一版本描述符.

在做了一些阅读之后,我特别看到这个工作是如何定义TFS内部版本号格式如下所示:$ MajorVersion.$ MinorVersion.$(Rev:.rr)其中MajorVersion和MinorVersion是我定义为的变量构建过程的一部分.

我意识到修订版基于整个构建号格式保持唯一性.所以我认为从源代码中提取主要版本和次要版本并在尝试评估修订版本和更广泛的版本号之前填充两个构建变量至关重要.我创建了一个Powershell脚本,使用正则表达式从头文件中提取主要版本和次要版本,然后在脚本中设置变量.

现在终于到了问题所在.看来我的方法存在缺陷.一旦我对构建进行排队,就立即评估TFS构建号,似乎为排队的构建命名.在这个阶段,我无法运行我的脚本来提取主要版本和次要版本,因此也得到了错误的版本号.因此,基于我之前提到的内部版本号格式,我最终得到的内容编号和结果名称类似于"..01"或"0.0.01",具体取决于我是否初始化构建定义中的主要和次要变量.

那么,在我有机会通过Powershell构建步骤从源代码中读取我的主要和次要版本之前,我是否可以看到一种方法可以推迟对TFS内部版本号的评估？如果我能这样做,则应根据真实的主要版本和次要版本正确计算修订版本.然后我将使用另一个脚本在我的头文件中仅设置Build号#define以匹配TFS内部版本号中的修订版.此外,由于TFS似乎使用内部版本号作为排队构建的名称,我不知道如何处理这个,因为我不知道构建排队时的最终TFS内部版本号.可以在构建过程中修改名称吗？

请帮忙.我认为我的想法相当简单,但我很难用其他非常好的TFS 2015构建系统来实现.

我正致力于通过VSTS管道部署arm模板.我有一个powershell脚本获取子网ID,我需要将此子网ID值传递给VSTS中的另一个任务.如何将变量从powershell脚本传递到vsts,然后将其作为parmae​​ter传递给azure资源组部署任务？