Azure 集成 CICD 的最佳实践 [关闭]

Posted

技术标签:

【中文标题】Azure 集成 CICD 的最佳实践 [关闭]【英文标题】:Best practice for Azure Integration CICD [closed] 【发布时间】:2021-12-21 14:05:03 【问题描述】:

我们有一堆逻辑应用程序、天蓝色函数、服务总线等,可满足多种集成用例。所有资源目前都在一个开发资源组中,我们希望将其发布到测试中,并最终使用 CICD 发布到产品资源组中。

问题

我们拥有所有资源,包括 ARM 模板中的逻辑应用程序,每次工作流程中的某些内容作为错误修复的一部分或新版本发生更改时,是否需要部署整个逻辑应用程序或是否可以正常工作流可以部署吗?

如果没有对逻辑应用或任何其他资源进行任何更改,再次部署其 ARM 模板是否会导致任何副作用?

【问题讨论】:

【参考方案1】:

您的问题的答案将根据您将要使用的部署模式以及您在 ARM 模板中定义资源的结构而有所不同。

将资源部署到 Azure 资源组时,您必须设置部署模式:

完成:替换目标 RG 中的所有内容 增量:仅将更改应用于目标 RG 内的资源,这些资源是您的部署包的一部分。

查看完整文档here

根据您构建 ARM 模板的方式(一个 ARM 模板中的所有资源,每个资源 1 个 ARM 模板,...),您将能够定义一个单一的目标将有多少 Azure 资源部署管道。

现在,回答您的问题:

Q1:确保您的 ARM 模板中具有明确定义的结构。 例如,创建一个 infrastructure-ARM 模板 + CI/CD-pipelines,它将只处理基本组件的创建/配置,例如存储帐户、服务总线、... 接下来,创建一个特定于域/接口的模板 + 管道,它只处理单个接口所需的那些逻辑应用程序等。 这样,如果您修改/修复属于特定接口的逻辑应用,则只会重新部署该特定接口。

Q2:即使使用增量部署模式,所有设置也会重新应用 -> 确保您的部署过程可以在需要时处理(重新)存储状态。

【讨论】:

以上是关于Azure 集成 CICD 的最佳实践 [关闭]的主要内容,如果未能解决你的问题,请参考以下文章

建立Azure Dev Ops持续集成和持续交付(CICD)(使用 Azure Pipelines 建立CICD)

建立Azure Dev Ops持续集成和持续交付(CICD)(准备好Azure DevOps的帐号并上传代码)

建立Azure Dev Ops持续集成和持续交付(CICD)(准备好Azure DevOps的帐号并上传代码)

建立Azure Dev Ops持续集成和持续交付(CICD)(准备好Azure Web App资源)

建立Azure Dev Ops持续集成和持续交付(CICD)(准备好Azure Web App资源)

建立Azure Dev Ops持续集成和持续交付(CICD)(准备好ServicePrincipal并配置相应的权限)