问题描述
在使用Azure DevOps构建和部署应用程序时，遇到了一个问题。他有一个项目N，被其他相关应用程序使用。为了解决这个问题，他决定将项目N部署为NuGet包，并在构建过程中使用它。由于项目N可能经常发生变化，他希望能够定义一个可靠的设置，以满足以下要求：
1. 只有在项目N及其依赖项发生更改时才创建NuGet包。
2. 确保如果需要创建NuGet包，按照1）的要求，管道在任何其他操作之前先创建NuGet包。
目前，他已经设置了两个不同的管道：一个用于创建和部署NuGet包（NuGet管道），另一个用于使用该NuGet包构建和部署应用程序（主管道）。
问题是，当项目N相关文件和解决方案的其他文件都发生更改时，他不知道如何制定一个规则，即“在主管道之前运行NuGet管道”。因此，他必须依靠运气，希望这样的顺序发生，如果不是，他将不得不在两个构建完成后手动触发主管道。因为他希望确保项目N中引入的新更改不会破坏解决方案。
有没有一种优雅的方法来解决这个问题？他可以设置一个触发器，每当NuGet管道完成时触发主管道，但这样做的话，每当对项目N和解决方案的其余部分进行更改时，都会触发两次主管道。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
根据你的描述，两个管道都是由相同的源提交触发的。如果是这样的话，你可以使用CI触发器源路径过滤器，以便构建仅在相关代码提交时发生。
如果开发人员进行了一次提交，同时提交了主应用程序和包库的更改（无论过滤器如何，这仍然会触发两个管道），你应该考虑提高代码提交的实践。提交应该是针对适当上下文的原子操作（例如，不要同时提交独立的库和使用它的应用程序）。首先提交（并在Git中推送）包的更改，以便它们将构建和发布，然后提交（并推送）主应用程序。这将确保触发器过滤器起到应有的作用。
我不知道ADO中是否有一种功能可以按照你希望的方式序列化管道的执行顺序。正如你所建议的，从另一个管道触发一个管道的替代方法可能会有点奏效，但最终并不能解决核心问题。
另外，考虑到“项目N”经常发生变化，并且如果它与主项目之间的关系非常紧密。也许将其作为包来使用并不合适。如果该库还将被其他具有较松散关系的应用程序使用，可以考虑直接将依赖项作为主项目的代码进行使用，而将其包发布作为主应用程序构建的一部分，而不是作为独立的管道。（我在API应用程序中使用了这种模型，该应用程序发布了一个数据合同库。API应用程序本身直接将项目作为项目引用进行使用，因为两者之间的关系非常紧密，但其他应用程序则作为已发布的包进行使用。）
方案2
请注意以下操作注意版本差异及修改前做好备份。
根据你的描述，你可以使用Azure DevOps的多阶段管道来解决这个问题。多阶段管道允许你在一个管道中定义多个阶段，并且可以按照你的需求设置阶段的顺序。
以下是如何设置多阶段管道的步骤：
1. 打开Azure DevOps中的项目，并导航到你的管道。
2. 在管道的编辑器中，选择“添加阶段”按钮。
3. 添加两个阶段：一个用于创建和部署NuGet包，另一个用于构建和部署应用程序。
4. 在每个阶段中，配置相应的任务和步骤，以满足你的需求。
5. 在管道的编辑器中，使用拖放功能将两个阶段按照你希望的顺序排列。
请注意，多阶段管道允许你在同一个管道中定义多个阶段，并且可以按照你的需求设置阶段的顺序。这样，你就可以确保NuGet管道在主管道之前运行。
方案3
请注意以下操作注意版本差异及修改前做好备份。
根据你的描述，你可以使用Azure DevOps的条件控制来解决这个问题。条件控制允许你根据特定条件来控制任务和步骤的执行顺序。
以下是如何使用条件控制来设置管道执行顺序的步骤：
1. 打开Azure DevOps中的项目，并导航到你的管道。
2. 在管道的编辑器中，选择要设置条件的任务或步骤。
3. 在任务或步骤的属性中，找到“控制选项”或类似的设置。
4. 在控制选项中，配置条件控制，以满足你的需求。例如，你可以设置一个条件，只有当NuGet管道成功完成时，才执行主管道。
请注意，条件控制允许你根据特定条件来控制任务和步骤的执行顺序。这样，你就可以确保NuGet管道在主管道之前运行。
以上是几种可能的解决方案，你可以根据你的需求选择其中一种或多种方案来解决你的问题。希望对你有帮助！