Azure devops 是否有可能一次实现一整套可能依赖的工件（微服务）？

传统上，我们必须在测试和预生产平台上逐个交付我们的应用程序，通常是手动使用设置。像前端javascript SPA UI这样的应用程序链接到后端服务，它们的交付有时会同时进行。 每个服务和应用程序都有自己的git存储库。目前，我们正在使用内部部署的TFS 2018 然后，当需要投入生产时，我们会立即交付所有经过验证的前端服务和应用程序

我们希望自动化我们的过程，但我们不知道Azure Devops是否合适。 据我对Azure Devops的了解，我们可以为每个微服务和每个前端应用程序创建一个独立的工件。我们也可以独立交付

在我看来，Azure Devops默认允许您管理特定微服务的交付周期，但不允许管理组成完整系统的程序集的交付周期，对吗

---

但是有可能交付一组项目，每个项目都有一个特定的版本吗？为此，我们的所有项目都必须在同一个解决方案或同一个git存储库中吗？

是的，您可以使用来自不同来源的多个工件在单个管道或发布定义中构建工件、存储库、包提要、github、docker hub、Azure容器注册表、++。对于经典版本定义和现代多阶段管道实现来说都是如此

例如，您可以定义一个管道或发布定义，该管道或发布定义使用来自RepoA的构建工件的前端web应用，从最初来自RepoB的容器注册表使用的后端服务工件，并可以说是来自RepoC的Git工件形式的脚本库。从那里，您可以一起部署这些工件中的每一个，或者以并行阶段、顺序、部分、有批准、有条件等方式部署，所有这些都来自同一管道

---

作为代码YAML管道的完整配置仍在预览中，因此有些工作流编排更难实现。但是经典的发布定义已经足够了，我默认使用多阶段来满足任何新的需求

是的，在问了我的问题之后，我确实看到我们可以有多个工件作为发布管道的输入。但我不知道的是：例如，我们在prepod环境下验证一个版本的全局系统，比如说，使用两个微服务：Service.AUTH.Api version 1.02.03和Service.Product.Api 1.01.01。我们可以将两个完全相同的验证版本推到发布管道中，还是我们必须为其指定相同的版本为生产环境的每次交付交付。