GitLab 推出了一种全新的“绿色 DevOps”方法，展示了软件工程团队如何衡量其 CI/CD 管道产生的碳排放量。GitLab 认为，不应该只把可持续发展视为基础设施层面的问题，而是应该从环境的角度出发观测软件交付管道本身，使工程团队能够在关注执行时间和成本等传统指标的同时，了解构建、测试、部署以及执行器利用率对碳排放的影响。
尽管长期以来各组织一直致力于优化持续集成/持续交付（CI/CD）管道的速度、可靠性和成本，但 GitLab 认为，碳排放应该逐步成为软件质量的另一个可量化维度。通过在现有的 DevOps 工作流中展示环境数据，团队可以在不从根本上改变软件开发方式的前提下，做出明智的决策，达到同时提升运营效率和环境表现的效果。
本文展示了工程团队如何结合持续集成/持续交付（CI/CD）执行数据、外部碳强度信息以及能耗模型，来估算软件交付过程中产生的碳排放量。GitLab 提出的方法并非试图直接测量每台构建服务器的用电量，而是通过关联管道执行时长、执行器利用率、计算资源以及区域电网碳强度，来估算单次管道执行对环境的影响。
所得的测量结果可以整合到现有的工程仪表盘中，使团队能够比较不同项目、识别低效工作流，并观察架构或管道变更随时间推移对可持续性的影响。就像监控构建时长或部署频率一样，碳排放成了软件交付过程中另一项可观测的指标。
在 GitLab 上的讨论中，一个贯穿始终的核心主题是：减少排放往往与提高工程效率天然契合。那些执行不必要任务、重新构建未更改的构建产物、过度配置执行器或反复运行冗余测试的管道，不仅会消耗额外的计算资源，还会增加成本和碳排放。
因此，通过智能缓存、并行执行、选择性测试、构建产物复用、临时基础设施以及规模适配的构建环境等技术来优化 CI/CD 管道，能够同时带来多重效益。企业利用许多相同的工程实践，既能降低基础设施成本、加速软件交付，又能减少对环境的影响。这进一步印证了这样一个观点：可持续发展可以成为优秀工程实践的自然结果，而非与业务目标相冲突的独立目标。
随着企业越来越多地采用 AI 辅助软件开发，这种可见性可能会变得更加重要。AI 生成的代码有可能显著提高构建频率、自动化测试和部署活动，但在缺乏全面遥测数据的情况下，这可以会更难以理解开发实践对运营的影响。具有碳意识的持续集成/持续交付（CI/CD）为企业提供了一个评估工程效率的全新视角。
通过将环境指标直接嵌入交付工作流，平台团队可以制定全组织范围的工程标准，在确保安全、可靠性和性能的同时，兼顾资源效率。平台不要求各个开发团队手动计算碳排放量，而是自动提供有意义的可持续发展洞察。
在探索更环保的软件交付方面，GitLab 并非孤军奋战。绿色软件基金会（Green Software Foundation）制定了“软件碳强度”（SCI）规范，帮助组织衡量与软件系统相关的排放量；而包括微软 Azure、谷歌云和亚马逊云科技在内的超大规模云服务提供商，如今也提供了碳报告仪表盘，用于展示云基础设施对环境的影响。工程组织也越来越多地集成 Cloud Carbon Footprint、Scaphandre 和 Kepler（基于 Kubernetes 的高效能耗指标导出工具）等工具，估算 Kubernetes 环境中的应用级能耗。
然而，在持续集成/持续交付（CI/CD）层面上，环境可观测性相对来说还不成熟。GitLab 的工作突显了如何将可持续性指标直接融入软件交付管道，而非仅局限于基础设施报告工具之中。各组织也在不断采用 FinOps 实践来优化云支出。
GitLab 的提案展示了可持续性指标如何从基础设施报告中融入日常工程工作流，使团队能够在评估部署频率、构建时长和成本的同时，一并评估环境影响。
原文链接：https://www.infoq.com/news/2026/07/gitlab-carbon-awareness/
