【问题标题】:VSTS Release Management; many release targetsVSTS 发布管理;许多发布目标
【发布时间】:2017-01-20 11:30:42
【问题描述】:

我有一个包含 8 个 Web 项目和 12 个可执行文件的解决方案它们都非常紧密耦合,因为它们之间共享了很多业务库;我们在 VSTS 中有一个针对整个解决方案的构建定义,但有 20 个不同的发布定义。

我们有用于 Dev/QA/Pre-Prod/Production 的单一环境、足够多的并发活动开发和管理限制,因此在所有环境模型中进行单一更改并不完全适合我们;开发和 QA 测试,稍后将转移到发布候选版本的夜间复合构建。

在我看来,我们希望有两组发布定义(一个开发和一个 QA 集,以及一个通过生产集的用户接受),但如果遵循该模型,我们最终会有 40 个发布定义。我错过了什么吗?我们对 EXE 有单独的定义,因为我们不希望一个发布失败影响另一个发布,而且由于它们都是单独目录的单独有效负载,因此它们似乎都应该是不同的。

每个可部署项目 1 个发布定义的模式是否正确,并且在夜间构建的情况下,两组所有可部署发布定义是否正确?

【问题讨论】:

    标签: azure-pipelines ms-release-management azure-pipelines-release-pipeline


    【解决方案1】:

    如果您有某种微服务模式,您应该始终致力于让一个发布定义同时在一个环境中部署整个应用程序,或者至少一次部署整个子系统。 当面临高度耦合的依赖关系时,您不希望触发多个版本。这可能会在循环中引入很多错误,或者至少会引入复杂性。 对于每个环境,该定义也可以多次具有相同的序列。

    【讨论】:

    • 我很好奇你对“整个应用程序”的定义是什么。作为一个简化的例子,我们有一个服务层和 3 个用户界面,一个公共客户,一个用于内部用户,另一个用于业务合作伙伴。它们都与服务层通信,但 3 个 UI 都是不同的应用程序。
    • 确实,这是画线通常比较困难的地方。当我必须做出这样的决定时,我主要做两件事:一个依赖关系图,以确定如果两个部分不在同一级别会破坏什么。这主要是硬限制。然后我在灵活性和简单性之间做出决定:我是否需要这两个部件才能分开发货?回答这些问题有助于我确定哪个部件将作为整体或单独运输。希望有帮助
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-08-19
    • 2017-12-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-05-18
    相关资源
    最近更新 更多