有懂这行的吗

appletree777

大家帮我看看，到底谁对。

我们的一个application是部署在客户Azure云上的，我们负责application，客户负责infra。同事A会上提到用terraform部署，我当场反对他，和terraform有什么关系。Terraform只能用于infra的部署，但infra和我们无关，我们的application code用Azure DevOps就好了。然后搞技术的同事B支持A，说terraform支持各种云。如果code已经在terraform上了，当然可以用。我的点在于，terraform只是用于部署infra的资源。app的code，还是需要Azure DevOps。而AB的意思似乎是应用也可以用terraform。最关键的是，会上有领导，两个人都反驳我，搞得我什么也不懂的感觉。

不知道这里有没有懂的，帮我看看是我对还是AB对。

DDD888

挺好的，做了后，可以在CV上加进去

我没用过，我是用RUST LANGUAGE开发，直接代码放到运行的服务器上编译啦

eltonfive

Terraform 是deployment 工具之一，CI/CD还是要依靠Github/ADO. Application code 只要build/package放在repo里，不管ARM/Bicep/Terraform都可部署

automationtest

你们和客户的责任边界在哪里， code在哪里build？如果客户只管部署，它们当然可以terraform。如果你们负责e2e，那不合适

sheepYY

a和b是对的。

你把部署工具混淆了。

当你考虑部署你的code的时候，你需要一个部署的工具，比如terraform 比如azure cli 比如ARM

而azure devops是cicd的平台，相比较于github action， bitbucket pipeline，jenkins这些

如果你的infra已经用terraform部署了，那么code如果也可以用terraform部署，会比较容易集中化管理，减少学习成本。但是terraform有时候更新延迟，那么用更native的部署工具会有优势。

不管用什么工具，你的平台在azure devops上，都只能用azure devops做cicd的工具，这个和你用不用terraform没关系

yrqin

我不太懂运维，帮你问了一下GPT：

你的理解更贴合业界最佳实践。下面分几点说明：

1. **Terraform 的定位：Infrastructure as Code**

   * Terraform 是用来声明式地**创建、修改和销毁云上资源**（VM、网络、存储、App Service、容器集群等）的工具，关注点在基础设施层面。
   * 它会根据你写好的 HCL（HashiCorp Configuration Language）配置，去“对齐”目标环境的资源状态。

2. **应用代码部署的职责更适合 CI/CD 平台**

   * 应用代码的编译、打包、测试、发布等流程，需要**流水线管理**、**工件存储**、**分阶段审批**、**回滚策略**、**制品版本控制**等功能，这些都是 Azure DevOps（或 GitHub Actions、GitLab CI/CD 等）擅长的。
   * 用 Terraform 来做这部分会把工具的关注点混到一起，也缺少流水线可视化、分支策略集成、动态变量注入等特性。

3. **Terraform 虽然“能”做到，但不等于“该”这么做**

   * 确实存在 Terraform 的第三方 Provider（比如 `azuredevops` provider）可以管理 Azure DevOps 的 Pipeline、Service Connection、Variable Group 等，甚至触发一次 Release；也可以用 `null_resource` + `local-exec`/`remote-exec` 去跑脚本、拷代码。但：

     * 这样做会让配置文件里掺杂大量与基础设施无关的脚本逻辑，难以维护。
     * Terraform 在“什么时候执行、执行到哪一步失败如何回滚”方面，也不如专门的 CI/CD 工具灵活和可控。

4. **职责分离、角色清晰**

   * 既然贵司负责应用代码交付，把构建与发布交给 Azure DevOps，利用它的**Pipeline、Artifact、环境审批**等功能；
   * 客户负责云上资源管理，则用 Terraform 或 ARM Template 来统一管理、版本化基础设施；
   * 这样既能保持流程清晰，也能各司其职、相互配合。

---

**结论**：

> Terraform 最核心的价值在于「资源声明与管理」，并不是一个完整的应用部署流水线工具。
> 应用的构建、测试、发布，仍然推荐用 Azure DevOps 这类 CI/CD 平台来做。

因此，你的观点在职责与工具定位上是正确的；A/B 的说法固然在技术上可行，但不符合最佳实践，也带来运维复杂度。

flip

不懂

appletree777

yrqin 发表于 2025-6-9 23:01
我不太懂运维，帮你问了一下GPT：

你的理解更贴合业界最佳实践。下面分几点说明：

谢谢，我一直认为terraform只能用来部署infra，和Azure A RM一样。但是AB意思app 的code也用terraform。我自认为这两个人比我懂技术。我又问了ChatGPT,和我理解一致。而你楼上的那位站AB。到底谁对？

appletree777

继续。这里到底有没有做这个的。其实只要是个码农,就很清楚了。

fnf2000

你的azure devops指的是啥？是ado cloud上面用UI生成cicd之类的嘛？如果你是指这个那你同事是对的，他们要infra as code用terraform写pipeline无疑比ado cloud上面用ui要更加灵活强大且易于跟随code。

如果你 cicd这块已经是infra as code了，那换terraform意义不大。

DDD888

appletree777 发表于 2025-6-10 06:17
继续。这里到底有没有做这个的。其实只要是个码农,就很清楚了。

我有三十年以上编程经验的程序员，我没用过你说的，我喜欢写RUST LANGUAGE代码，为了增加我的知识，我就问了下CHATGPT

这是连接
https://chatgpt.com/share/68480557-ea48-8009-99f6-6967a964bb52

根据回答，好像用了更好

交易人生

用过azure很多年，关键是你们的应用是什么？部署指的是架构的deployment 还是代码release?

如果只是代码的deployment (app service 或者vm已经建好），azure 的pipeline能够轻松完成所有工作，从repository 管理，到build, 到release。。。这时候用terraform多此一举，徒添了工作量。

如果你所说的部署指的是每次代码release，需要重新创建app service或者vm，terraform倒是个方案。如果只是one off 创建app service，也没必要terraform，手动几分钟就完成了。

terraform的应用场景就是不断重复地创建app service或者vm或者db server等等，其他没啥用途，azure cli也能做到，terraform更通用些。

appletree777

交易人生 发表于 2025-6-11 14:36
用过azure很多年，关键是你们的应用是什么？部署指的是架构的deployment 还是代码release?

如果只是代码的 ...

修改了下原文，应用指application。你说的应该和我理解一致。application code用Azure DevOps部署到Azure上。Azure 的resource， VM， DB这些ARM， Terraform都可。我们场景是客户负责Azure cloud的部署，我们负责application的部署。所以我反驳AB， 关terra form啥事。

marco_lw

感觉你们甲方和乙方都是业余，这种环境应该比较好混。

netman

Terraform本身只是infra as a code的工具，说白了是提供给程序员一个熟悉的编程界面去完成基础设施的部署，从而去除对infra团队的依赖，提高部署效率。它和应用本身的部署工具是衔接和集成关系而不是替代。

交易人生

appletree777 发表于 2025-6-14 08:20
修改了下原文，应用指application。你说的应该和我理解一致。application code用Azure DevOps部署到Azure ...

因为ab不理解terraform的被微软支持目的是什么，微软的一般逻辑是可以移植其平台比如竞争对手的产品，第二是你支持我也支持，口碑上不落后，第三才是个工具做infra的deployment. 技术人员喜欢新鲜玩意儿，很多时候浪费时间。

另外，可以说服你的客户用app service 而非vm，app service省钱灵活，支持slot，类似热插拔;也能scale up/down, 动态地load balance，failover等等优点。