响应合并从Harness碎片信息到DevOps决策的完整拼图一、 引言 (Introduction)钩子 (The Hook): DevOps流水线的“数据孤岛困境”与那个凌晨三点的蓝绿切换惊魂夜各位Harness用户、DevOps工程师、SRE兄弟姐妹们凌晨三点坐在电脑前血压拉满的场景有没有印象深刻的我去年11月就遇到过这么一次负责维护的电商微服务集群做双11前的预演蓝绿切换Harness CD的部署阶段已经全标绿了Kubernetes Deployment就绪探针全过、Istio流量切换占比到了90%、Prometheus的QPS曲线和延迟曲线看着还行——但就在这个时候用户反馈群炸了“首页的商品详情图片全裂了”“支付页面弹出的银行列表是2020年的”赶紧切回Harness查看才发现问题出在各个微服务的验证阶段输出是“孤岛”图片服务的验证阶段有一个自定义的image_validation脚本执行时查出了CDN回源新S3桶失败但脚本的exit code是0——因为脚本逻辑是“查出失败但不阻断测试阶段只输出告警JSON到Harness变量里存着”配置服务的验证阶段跑了consul_config_check发现生产分支漏同步了最新的银行列表配置但**这个脚本是作为“可选验证”Optional Step**放在Stage里的默认失败后自动继续最重要的是预演决策阶段我设置的Manual Approval前的Automated Approval Gate根本没有引用这两个Optional Step和自定义验证脚本的变量只看了Deployment就绪、Prometheus的5xx错误率0.1%这两个硬指标。最后花了40分钟回滚流量、紧急修复两个问题、重新同步CDN配置——预演延迟了1小时不说还惊出一身冷汗要是正式双11的0点遇到这个问题后果不堪设想。定义问题/阐述背景 (The “Why”)Harness的“多源碎片化”数据与统一决策/统一报告的需求那次惊魂夜之后我开始深挖Harness的输出管理机制和数据流转逻辑——不挖不知道Harness作为一个“Everything as Code Event-Driven”的全栈DevOps平台它的核心优势是“多阶段、多服务、多工具链的编排能力”但也正是这个优势带来了数据碎片化的副作用1. Harness数据碎片化的三大来源在日常的Harness CI/CD/GitOps/Security OrchestrationSO流水线中我们的数据会从至少三个维度“打碎”阶段Stage维度一个典型的Harness CD应用部署流水线可能包含以下StageGitOps同步源Sync RepoStage构建基础设施Build Infra比如Terraform Provisioner或者Kustomize Overlay渲染Stage部署微服务A到预环境Deploy A to QAStage部署微服务B到预环境Deploy B to QAStage部署微服务C到预环境Deploy C to QAStageQA自动化测试QA E2E, API, LoadStage安全扫描SCA, SAST, DASTStageManual Approval预演生产Stage部署微服务A/B/C到生产蓝环境Stage蓝绿验证Blue ValidationStage流量切换到绿环境Stage流量验证Green ValidationStage回滚触发条件检查Rollback Trigger CheckStage每个Stage都会产生大量的“状态数据”比如Stage Pass/Fail/Skipped/Timeout、“指标数据”比如QA测试的通过率、Load测试的P95延迟、SCA的Critical漏洞数量、“自定义输出数据”比如Kustomize Overlay渲染后的最终YAML、image_validation脚本查出的CDN回源失败URL列表、consul_config_check漏同步的配置键——这些数据默认只存在于当前Stage的上下文中如果不主动提取、合并下一个Stage比如Approval Gate、Rollback Trigger根本看不到。步骤Step维度每个Stage又由多个Step组成比如“部署微服务A到预环境”Stage可能包含Fetch ManifestStep从Git拉取Helm Chart/KustomizeRender ManifestStep用Harness Variable渲染Chart的values.yamlHelm Install/UpgradeStep部署到K8sVerify Application HealthStepK8s就绪探针检查 自定义HTTP健康检查Optional: Verify Logs with DatadogStep拉取Datadog APM的错误日志同样Step的输出数据默认只在当前Step上下文中比如Verify Application Health的自定义HTTP健康检查返回的JSON包含各API的status code、响应时间、错误信息如果不存到Harness的Output Variable或者Context Variable里Optional Step和下一个Stage根本看不到。工具链Toolchain维度Harness的“连接器Connector”系统可以集成几乎所有主流的DevOps工具——比如代码仓库用GitHub/GitLab/Bitbucket、CI构建用Harness CI/Jenkins/GitLab CI、CD部署用Harness CD/Argo CD、安全扫描用Snyk/Trivy/SonarQube、监控用Prometheus/Grafana/Datadog/New Relic、问题追踪用Jira/Linear……每个工具链的输出格式都是不一样的比如GitHub Actions的输出是GITHUB_OUTPUT、Snyk的扫描结果是JSON/SARIF、Datadog的监控指标是JSON/CSV、Jenkins的构建结果是XML/JSON——这些数据如果不经过Harness的统一格式转换和合并很难用来做统一的决策比如Approval Gate的条件“所有微服务Deploy成功 Snyk Critical漏洞数量0 Datadog 5xx错误率0.1% QA E2E通过率100%”或者生成统一的部署报告比如PDF/HTML的部署总结包含所有Stage/Step/工具链的数据。2. Harness响应合并的核心价值从“碎片感知”到“全局决策”再到“自动化闭环”Harness官方在2022年的Harness NextGen Platform也就是现在大家用的NG平台中重点优化了输出管理Output Management、**上下文变量Context Variables和响应合并Response Aggregation/Response Merging**的功能——这些功能的核心价值就是帮我们解决上面提到的“数据孤岛困境”实现三个层级的提升碎片感知层级Fragment Awareness把散在各个Stage、Step、工具链的数据“提取出来”存到统一的Harness上下文中让所有Stage、Step、工具链都能“看到”彼此的数据全局决策层级Global Decision Making把提取出来的数据“合并起来”按照业务逻辑或者合规要求进行计算、过滤、格式化然后用来驱动自动化决策比如Automated Approval Gate、Rollback Trigger、Alerting Rule自动化闭环层级Automated Closed Loop把合并后的数据“反馈回去”用来更新代码仓库比如提交SARIF扫描结果到GitHub Security Advisories、问题追踪系统比如自动创建Jira Ticket标注Critical漏洞、监控告警比如自动触发PagerDuty告警标注QA E2E失败甚至是自动触发回滚或者修复流程。那次惊魂夜之后我就是用Harness的响应合并功能重构了预演生产的蓝绿验证Gate和回滚Trigger现在再也不用担心“自定义验证脚本exit code为0但有告警”“Optional Step失败被忽略”“多个工具链的结果串不起来”的问题了——预演和正式部署的决策效率提高了至少80%排查问题的时间从平均40分钟降到了平均5分钟因为所有相关数据都在Gate的输出里一目了然。亮明观点/文章目标 (The “What” “How”)本文是一篇关于Harness NextGen Platform中响应合并的深度实战教程最佳实践指南目标读者是有一定Harness NG基础比如会创建CI/CD流水线、会用Stage/Step/Connector、会定义Harness Variable的DevOps工程师、SRE、Harness管理员。读完这篇文章你将学到核心概念什么是Harness的响应响应的类型有哪些响应合并的定义、边界、外延是什么响应提取如何从Harness的Stage、Step、工具链中提取响应如何定义Output Variable如何使用Context Variable响应转换如何把不同工具链的输出格式比如SARIF、XML、CSV转换成Harness统一的JSON格式如何使用Harness的Jinja2模板引擎响应合并如何使用Harness的内置函数比如merge()、concat()、zip()、map()、filter()合并多个响应如何定义自定义合并逻辑如何使用Harness的Pipeline Expression LanguagePEL响应应用如何把合并后的响应用于自动化决策Approval Gate、Rollback Trigger、统一部署报告PDF/HTML、自动化闭环更新代码仓库、创建Jira Ticket、触发PagerDuty告警实战演练用一个完整的电商微服务集群蓝绿预演生产的Harness CD流水线案例从零到一实现响应的提取、转换、合并、应用最佳实践Harness响应合并的常见陷阱与避坑指南、性能优化建议、成本考量、专家级建议行业发展与未来趋势Harness响应合并功能的发展历史、未来规划、DevOps行业中响应合并的最佳实践案例。二、 基础知识/背景铺垫 (Foundational Concepts)在正式开始实战演练之前我们需要先搞清楚Harness响应合并的核心概念、相关工具/技术概览——这些是我们后续操作的基础。2.1 核心概念定义2.1.1 Harness的“响应Response”是什么在Harness NextGen Platform中响应Response是指Stage、Step、工具链连接器执行后产生的所有结构化/非结构化数据的统称——注意这里的“执行后产生的数据”不仅包括“执行结果Execution Result”比如Pass/Fail/Skipped/Timeout还包括“执行输出Execution Output”比如Helm Install的Release Name、QA E2E的通过率、Snyk的Critical漏洞数量、自定义脚本的JSON输出。Harness把响应分成了两大类内置响应Built-in ResponseHarness为每个Stage、Step、工具链连接器默认提供的响应数据不需要我们主动定义就可以直接使用。内置响应通常存储在Harness的Context Variable上下文变量中Context Variable的命名规则通常是ContextType.Property或者ContextType.Object.Property。举几个常见的内置响应Context Variable的例子Stage的内置响应pipeline.stages.StageName.statusStage的执行结果比如SUCCESS、FAILED、SKIPPED、TIMEOUT、pipeline.stages.StageName.durationStage的执行时长单位是毫秒、pipeline.stages.StageName.startTsStage的开始时间戳、pipeline.stages.StageName.endTsStage的结束时间戳Kubernetes Deploy Step的内置响应pipeline.stages.StageName.execution.steps.StepName.output.releaseNameHelm/Kustomize部署的Release Name、pipeline.stages.StageName.execution.steps.StepName.output.deploymentStatusDeployment的状态比如DEPLOYED、FAILED、ROLLBACKED、pipeline.stages.StageName.execution.steps.StepName.output.resources部署的所有K8s资源的YAML列表Snyk Scan Step的内置响应pipeline.stages.StageName.execution.steps.StepName.output.criticalVulnerabilitiesCritical漏洞的数量、pipeline.stages.StageName.execution.steps.StepName.output.highVulnerabilitiesHigh漏洞的数量、pipeline.stages.StageName.execution.steps.StepName.output.sarifReportSnyk扫描结果的SARIF JSON字符串HTTP Step的内置响应pipeline.stages.StageName.execution.steps.StepName.output.httpStatusHTTP响应的状态码比如200、404、500、pipeline.stages.StageName.execution.steps.StepName.output.httpHeadersHTTP响应的头信息JSON格式、pipeline.stages.StageName.execution.steps.StepName.output.httpResponseBodyHTTP响应的主体内容字符串/JSON格式。所有内置响应的Context Variable列表可以在Harness NG Pipeline Editor的**右侧“Context Browser上下文浏览器”**中查看——这个工具非常好用后续我们会经常用到。自定义响应Custom Response我们主动定义的、不属于Harness内置响应的数据通常存储在Harness的Output Variable输出变量或者Context Variable的自定义对象中。自定义响应的数据来源可以是自定义Shell/PowerShell/Python脚本的输出比如用Python脚本查出的CDN回源失败URL列表自定义Jinja2模板渲染的结果比如用Jinja2模板把多个工具链的输出合并成一个统一的部署报告JSON从第三方API获取的额外数据比如从GitHub API获取当前Commit的Author信息、从Jira API获取当前Deployment对应的Issue列表。2.1.2 Harness的“响应合并Response Merging”是什么在Harness NextGen Platform中响应合并Response Merging是指将从多个Stage、Step、工具链中提取的响应包括内置响应和自定义响应按照业务逻辑或者合规要求进行“拼接、合并、计算、过滤、格式化”等操作生成一个新的、统一的、结构化的响应数据的过程。2.1.3 响应合并的“边界Boundary”与“外延Extension”1边界BoundaryHarness响应合并的边界是指响应合并操作可以在Harness NG Platform的哪些组件中执行以及响应合并操作的输入/输出范围是什么。执行组件的边界✅可以执行的组件Pipeline Expression LanguagePEL在任何可以使用PEL的地方比如Approval Gate的条件、Rollback Trigger的条件、Step的Input Variable、Output Variable的定义都可以执行简单的响应合并操作比如用merge()函数合并两个JSON对象、用concat()函数拼接两个数组Jinja2 Template Step内置模板步骤Harness NG的Pipeline Editor中有一个专门的**“Template模板”Step**或者叫“Jinja2 Template Step”可以执行复杂的响应合并操作比如用Jinja2的循环、条件、过滤器合并多个响应、生成统一的部署报告JSON/HTML自定义Shell/PowerShell/Python脚本Step如果Jinja2 Template Step的功能还不够用我们可以用自定义脚本Step执行更复杂的响应合并操作比如用Python的pandas库合并CSV格式的响应、用requests库从第三方API获取额外数据并合并Harness Custom Stage自定义阶段如果我们需要把响应合并的逻辑封装成一个可复用的组件可以把响应合并的Step比如Jinja2 Template Step、自定义脚本Step放在一个Custom Stage中然后在其他Pipeline中引用这个Custom Stage。❌不可以直接执行的组件Connector连接器Connector只负责连接第三方工具不负责处理响应Delegate代理Delegate只负责执行Pipeline的Step比如Helm Install Step、Snyk Scan Step不负责处理响应——但Delegate上可以运行自定义脚本Step所以响应合并的逻辑如果在自定义脚本Step中最终是在Delegate上执行的GitOps Sync StageGitOps同步阶段GitOps Sync Stage只负责从Git拉取Manifest并同步到K8s不负责处理响应——但GitOps Sync Stage的内置响应可以被提取出来然后在其他Stage中合并。输入/输出范围的边界✅可以作为输入的响应当前Pipeline中所有Stage/Step的内置响应当前Pipeline中所有Stage/Step的自定义Output Variable当前Pipeline的Input Variable输入变量当前Pipeline的Runtime Input运行时输入当前Pipeline的Secret密钥——注意Secret只能被读取不能被合并后输出到非Secret的地方比如部署报告否则会导致密钥泄露从第三方API获取的额外数据通过HTTP Step或者自定义脚本Step获取。✅可以作为输出的响应当前Stage的Custom Output Variable当前Step的Custom Output Variable统一的部署报告PDF/HTML/JSON——可以通过Harness的“Upload Artifact Step”上传到Harness Artifact Store比如S3、GCS、Harness自带的Artifact Store或者通过HTTP Step发送到第三方工具比如Slack、Jira、EmailApproval Gate的注释Rollback Trigger的注释Alerting Rule的通知内容。❌不可以作为输出的响应Secret密钥——合并后不能输出到非Secret的地方当前Pipeline的Input Variable/Runtime Input的修改——Input Variable/Runtime Input只能被读取不能被修改后输出除非我们把修改后的值存到Custom Output Variable中。2外延ExtensionHarness响应合并的外延是指响应合并操作可以和Harness NG Platform的哪些其他功能结合使用以及响应合并操作可以解决哪些DevOps场景中的问题。可以结合使用的功能Approval Gate审批门把合并后的响应用于Automated Approval Gate的条件比如“所有微服务Deploy成功 Snyk Critical漏洞数量0 Datadog 5xx错误率0.1% QA E2E通过率100%”或者用于Manual Approval Gate的注释给审批人展示所有相关数据帮助审批人快速做出决策Rollback Trigger回滚触发器把合并后的响应用于Rollback Trigger的条件比如“蓝绿验证Gate的响应中CDN回源失败URL数量0 OR 漏同步的配置键数量0”或者用于Rollback Trigger的注释给SRE展示回滚的原因和所有相关数据Alerting Rule告警规则把合并后的响应用于Alerting Rule的通知内容比如给Slack/Email/PagerDuty发送告警包含Pipeline的执行结果、所有相关Stage/Step的响应、合并后的决策结果Artifact Management制品管理把合并后的部署报告作为Artifact上传到Harness Artifact Store方便后续追溯Issue Management问题管理把合并后的响应比如Snyk的Critical漏洞列表、QA E2E的失败用例列表通过HTTP Step或者自定义脚本Step发送到Jira/Linear自动创建IssueGitOpsGitOps把合并后的响应比如Kustomize Overlay渲染后的最终YAML、Snyk的SARIF扫描结果通过Git Commit Step提交到Git仓库Templates模板把响应合并的逻辑封装成Pipeline Template/Stage Template/Step Template然后在其他Pipeline中引用提高复用性Governance治理把合并后的响应用于Harness Policy as CodeOPA的条件确保Pipeline的执行符合合规要求比如“合并后的响应中Snyk Critical漏洞数量必须0否则Pipeline失败”。可以解决的DevOps场景中的问题统一决策场景比如预演生产的蓝绿验证、正式生产的部署决策、回滚触发决策统一报告场景比如CI构建报告、CD部署报告、安全扫描报告、QA测试报告自动化闭环场景比如自动创建Jira Issue标注安全漏洞、自动提交SARIF扫描结果到GitHub Security Advisories、自动触发PagerDuty告警标注QA E2E失败、自动触发回滚流程数据追溯场景比如把合并后的部署报告作为Artifact上传到Harness Artifact Store方便后续追溯某个Deployment的所有相关数据多服务协调场景比如微服务集群的同时部署验证、多服务的健康检查合并、多服务的测试报告合并。2.2 相关工具/技术概览在Harness NextGen Platform中实现响应合并我们需要用到以下几个核心工具/技术2.2.1 Harness Pipeline Expression LanguagePELHarness Pipeline Expression Language简称PEL是Harness NG Platform专门为Pipeline设计的表达式语言用于在Pipeline的各种组件比如Approval Gate的条件、Rollback Trigger的条件、Step的Input Variable、Output Variable的定义中执行简单的计算、过滤、合并操作。PEL的语法非常简单类似于JavaScript的简化版或者Python的简化版——它支持以下几种基本操作变量访问用.或者[]访问变量的属性或者数组的元素比如pipeline.stages.DeployQA.status、pipeline.stages.DeployQA.execution.steps.ImageValidation.output.failedUrls[0]算术运算支持、-、*、/、%等算术运算符比如pipeline.stages.DeployQA.duration / 1000把毫秒转换成秒比较运算支持、!、、、、等比较运算符比如pipeline.stages.DeployQA.status SUCCESS、pipeline.stages.SnykScan.output.criticalVulnerabilities 0逻辑运算支持与、||或、!非等逻辑运算符比如pipeline.stages.DeployQA.status SUCCESS pipeline.stages.SnykScan.output.criticalVulnerabilities 0字符串运算支持拼接字符串比如Pipeline pipeline.name executed in (pipeline.stages.DeployQA.duration / 1000) seconds内置函数Harness PEL提供了大量的内置函数用于执行常见的操作——这也是我们实现简单响应合并的核心工具字符串函数比如length()获取字符串长度、upper()把字符串转换成大写、lower()把字符串转换成小写、trim()去除字符串首尾的空格、split()把字符串按照分隔符拆分成数组、join()把数组按照分隔符拼接成字符串数组函数比如length()获取数组长度、concat()拼接两个数组、merge()合并两个数组或者两个JSON对象注意PEL的merge()函数的行为和Jinja2的merge()函数的行为有些不一样后续我们会详细对比、zip()把两个数组的元素一一对应组合成一个新的数组、map()对数组的每个元素执行一个操作生成一个新的数组、filter()过滤数组的元素生成一个新的数组、find()在数组中查找符合条件的第一个元素、findAll()在数组中查找符合条件的所有元素、sort()对数组的元素进行排序、reverse()反转数组的元素JSON函数比如toJson()把对象转换成JSON字符串、fromJson()把JSON字符串转换成对象、jsonPath()用JSONPath表达式从JSON对象中提取数据时间函数比如now()获取当前时间戳、formatDate()把时间戳格式化成指定的日期时间字符串、parseDate()把日期时间字符串解析成时间戳其他函数比如if()三元运算符的另一种写法、default()如果变量为空或者未定义返回默认值、isNull()判断变量是否为空、isUndefined()判断变量是否未定义、coalesce()返回第一个非空、非未定义的变量。所有PEL内置函数的详细文档可以在Harness官方文档的“Pipeline Expression Language (PEL) Reference”页面查看。2.2.2 Jinja2 Template EngineJinja2模板引擎Jinja2是一个基于Python的、功能强大的、可扩展的模板引擎被广泛应用于Flask、Django等Python Web框架中——Harness NG Platform把Jinja2集成到了Pipeline Editor中作为一个专门的**“Template模板”Step**或者叫“Jinja2 Template Step”用于执行复杂的响应合并操作。Jinja2的语法比PEL复杂得多但功能也强大得多——它支持以下几种核心功能变量访问用{{ variable }}或者{{ variable.property }}或者{{ variable[index] }}访问变量的属性或者数组的元素和PEL类似条件语句用{% if condition %}、{% elif condition %}、{% else %}、{% endif %}实现条件判断循环语句用{% for item in list %}、{% endfor %}实现循环支持loop.index、loop.index0、loop.first、loop.last等循环变量过滤器Filters用{{ variable | filter }}或者{{ variable | filter1 | filter2 }}对变量进行处理——Jinja2提供了大量的内置过滤器Harness还额外提供了一些和DevOps相关的过滤器Jinja2内置过滤器比如length()获取字符串/数组长度、upper()把字符串转换成大写、lower()把字符串转换成小写、trim()去除字符串首尾的空格、split()把字符串按照分隔符拆分成数组、join()把数组按照分隔符拼接成字符串、default()如果变量为空或者未定义返回默认值、sort()对数组的元素进行排序、reverse()反转数组的元素、tojson()把对象转换成JSON字符串支持格式化选项、fromjson()把JSON字符串转换成对象Harness额外提供的过滤器比如base64encode()把字符串/base64编码、base64decode()把base64编码的字符串解码、sha256sum()计算字符串的SHA256哈希值、md5sum()计算字符串的MD5哈希值、yaml()把对象转换成YAML字符串、fromyaml()把YAML字符串转换成对象、jsonpath()用JSONPath表达式从JSON对象中提取数据。宏Macros用{% macro name(parameters) %}、{% endmacro %}定义可复用的模板片段类似于编程语言中的函数继承Inheritance用{% extends base_template %}、{% block name %}、{% endblock %}实现模板继承类似于面向对象编程中的继承——不过在Harness的Template Step中我们通常不需要用到继承因为我们的模板是一次性的除非我们把模板封装成Step Template。所有Jinja2内置过滤器和Harness额外提供的过滤器的详细文档可以在Harness官方文档的“Use Jinja2 Templates in Harness”页面查看。2.2.3 Harness Context Browser上下文浏览器Harness Context Browser是Harness NG Pipeline Editor的右侧面板中的一个工具用于查看和插入当前Pipeline中所有可用的Context Variable、Input Variable、Runtime Input、Secret、Output Variable——这是我们实现响应提取的核心工具因为它可以帮我们快速找到我们需要的变量不需要记住复杂的命名规则。Context Browser的使用方法非常简单在Harness NG Pipeline Editor中打开右侧面板如果右侧面板没有打开可以点击Pipeline Editor右上角的“”按钮打开点击右侧面板中的**“Context上下文”**标签页在Context标签页中你可以看到以下几个分类Pipeline当前Pipeline的Context Variable比如pipeline.name、pipeline.executionId、pipeline.startTsStages当前Pipeline中所有Stage的Context Variable比如每个Stage的status、duration、startTs、endTs、内置响应、自定义Output VariableInput Variables当前Pipeline的Input VariableRuntime Inputs当前Pipeline的Runtime InputSecrets当前Pipeline的Secret注意Secret的内容是隐藏的只能用{{ secrets.secretName }}的形式插入到Step的Input Variable中Artifacts当前Pipeline中所有Step上传的ArtifactConnectors当前Pipeline中所有Connector的Context Variable比如Connector的ID、名称、类型——不过Connector的内容通常不需要用到。找到你需要的变量后点击变量右侧的**“Copy复制”按钮或者“Insert插入”**按钮就可以把变量的表达式复制到剪贴板或者插入到当前正在编辑的输入框中。2.3 本章小结在本章中我们首先搞清楚了Harness响应合并的核心概念响应ResponseStage、Step、工具链连接器执行后产生的所有结构化/非结构化数据的统称分为内置响应和自定义响应响应合并Response Merging将从多个Stage、Step、工具链中提取的响应按照业务逻辑或者合规要求进行“拼接、合并、计算、过滤、格式化”等操作生成一个新的、统一的、结构化的响应数据的过程响应合并的边界可以在PEL、Jinja2 Template Step、自定义脚本Step、Custom Stage中执行输入可以是当前Pipeline中所有Stage/Step的内置响应、自定义Output Variable、Input Variable、Runtime Input、Secret、从第三方API获取的额外数据输出可以是当前Stage/Step的Custom Output Variable、统一的部署报告、Approval Gate的注释、Rollback Trigger的注释、Alerting Rule的通知内容响应合并的外延可以和Approval Gate、Rollback Trigger、Alerting Rule、Artifact Management、Issue Management、GitOps、Templates、Governance等功能结合使用解决统一决策、统一报告、自动化闭环、数据追溯、多服务协调等DevOps场景中的问题。然后我们介绍了Harness响应合并的三个核心工具/技术Harness Pipeline Expression LanguagePEL用于执行简单的响应合并操作Jinja2 Template Engine用于执行复杂的响应合并操作Harness Context Browser用于快速找到我们需要的变量实现响应提取。在下一章中我们将进入核心实战演练环节——用一个完整的电商微服务集群蓝绿预演生产的Harness CD流水线案例从零到一实现响应的提取、转换、合并、应用。
Harness 中的响应合并：将多个片段组装为完整输出
发布时间：2026/6/1 0:00:11
响应合并从Harness碎片信息到DevOps决策的完整拼图一、 引言 (Introduction)钩子 (The Hook): DevOps流水线的“数据孤岛困境”与那个凌晨三点的蓝绿切换惊魂夜各位Harness用户、DevOps工程师、SRE兄弟姐妹们凌晨三点坐在电脑前血压拉满的场景有没有印象深刻的我去年11月就遇到过这么一次负责维护的电商微服务集群做双11前的预演蓝绿切换Harness CD的部署阶段已经全标绿了Kubernetes Deployment就绪探针全过、Istio流量切换占比到了90%、Prometheus的QPS曲线和延迟曲线看着还行——但就在这个时候用户反馈群炸了“首页的商品详情图片全裂了”“支付页面弹出的银行列表是2020年的”赶紧切回Harness查看才发现问题出在各个微服务的验证阶段输出是“孤岛”图片服务的验证阶段有一个自定义的image_validation脚本执行时查出了CDN回源新S3桶失败但脚本的exit code是0——因为脚本逻辑是“查出失败但不阻断测试阶段只输出告警JSON到Harness变量里存着”配置服务的验证阶段跑了consul_config_check发现生产分支漏同步了最新的银行列表配置但**这个脚本是作为“可选验证”Optional Step**放在Stage里的默认失败后自动继续最重要的是预演决策阶段我设置的Manual Approval前的Automated Approval Gate根本没有引用这两个Optional Step和自定义验证脚本的变量只看了Deployment就绪、Prometheus的5xx错误率0.1%这两个硬指标。最后花了40分钟回滚流量、紧急修复两个问题、重新同步CDN配置——预演延迟了1小时不说还惊出一身冷汗要是正式双11的0点遇到这个问题后果不堪设想。定义问题/阐述背景 (The “Why”)Harness的“多源碎片化”数据与统一决策/统一报告的需求那次惊魂夜之后我开始深挖Harness的输出管理机制和数据流转逻辑——不挖不知道Harness作为一个“Everything as Code Event-Driven”的全栈DevOps平台它的核心优势是“多阶段、多服务、多工具链的编排能力”但也正是这个优势带来了数据碎片化的副作用1. Harness数据碎片化的三大来源在日常的Harness CI/CD/GitOps/Security OrchestrationSO流水线中我们的数据会从至少三个维度“打碎”阶段Stage维度一个典型的Harness CD应用部署流水线可能包含以下StageGitOps同步源Sync RepoStage构建基础设施Build Infra比如Terraform Provisioner或者Kustomize Overlay渲染Stage部署微服务A到预环境Deploy A to QAStage部署微服务B到预环境Deploy B to QAStage部署微服务C到预环境Deploy C to QAStageQA自动化测试QA E2E, API, LoadStage安全扫描SCA, SAST, DASTStageManual Approval预演生产Stage部署微服务A/B/C到生产蓝环境Stage蓝绿验证Blue ValidationStage流量切换到绿环境Stage流量验证Green ValidationStage回滚触发条件检查Rollback Trigger CheckStage每个Stage都会产生大量的“状态数据”比如Stage Pass/Fail/Skipped/Timeout、“指标数据”比如QA测试的通过率、Load测试的P95延迟、SCA的Critical漏洞数量、“自定义输出数据”比如Kustomize Overlay渲染后的最终YAML、image_validation脚本查出的CDN回源失败URL列表、consul_config_check漏同步的配置键——这些数据默认只存在于当前Stage的上下文中如果不主动提取、合并下一个Stage比如Approval Gate、Rollback Trigger根本看不到。步骤Step维度每个Stage又由多个Step组成比如“部署微服务A到预环境”Stage可能包含Fetch ManifestStep从Git拉取Helm Chart/KustomizeRender ManifestStep用Harness Variable渲染Chart的values.yamlHelm Install/UpgradeStep部署到K8sVerify Application HealthStepK8s就绪探针检查 自定义HTTP健康检查Optional: Verify Logs with DatadogStep拉取Datadog APM的错误日志同样Step的输出数据默认只在当前Step上下文中比如Verify Application Health的自定义HTTP健康检查返回的JSON包含各API的status code、响应时间、错误信息如果不存到Harness的Output Variable或者Context Variable里Optional Step和下一个Stage根本看不到。工具链Toolchain维度Harness的“连接器Connector”系统可以集成几乎所有主流的DevOps工具——比如代码仓库用GitHub/GitLab/Bitbucket、CI构建用Harness CI/Jenkins/GitLab CI、CD部署用Harness CD/Argo CD、安全扫描用Snyk/Trivy/SonarQube、监控用Prometheus/Grafana/Datadog/New Relic、问题追踪用Jira/Linear……每个工具链的输出格式都是不一样的比如GitHub Actions的输出是GITHUB_OUTPUT、Snyk的扫描结果是JSON/SARIF、Datadog的监控指标是JSON/CSV、Jenkins的构建结果是XML/JSON——这些数据如果不经过Harness的统一格式转换和合并很难用来做统一的决策比如Approval Gate的条件“所有微服务Deploy成功 Snyk Critical漏洞数量0 Datadog 5xx错误率0.1% QA E2E通过率100%”或者生成统一的部署报告比如PDF/HTML的部署总结包含所有Stage/Step/工具链的数据。2. Harness响应合并的核心价值从“碎片感知”到“全局决策”再到“自动化闭环”Harness官方在2022年的Harness NextGen Platform也就是现在大家用的NG平台中重点优化了输出管理Output Management、**上下文变量Context Variables和响应合并Response Aggregation/Response Merging**的功能——这些功能的核心价值就是帮我们解决上面提到的“数据孤岛困境”实现三个层级的提升碎片感知层级Fragment Awareness把散在各个Stage、Step、工具链的数据“提取出来”存到统一的Harness上下文中让所有Stage、Step、工具链都能“看到”彼此的数据全局决策层级Global Decision Making把提取出来的数据“合并起来”按照业务逻辑或者合规要求进行计算、过滤、格式化然后用来驱动自动化决策比如Automated Approval Gate、Rollback Trigger、Alerting Rule自动化闭环层级Automated Closed Loop把合并后的数据“反馈回去”用来更新代码仓库比如提交SARIF扫描结果到GitHub Security Advisories、问题追踪系统比如自动创建Jira Ticket标注Critical漏洞、监控告警比如自动触发PagerDuty告警标注QA E2E失败甚至是自动触发回滚或者修复流程。那次惊魂夜之后我就是用Harness的响应合并功能重构了预演生产的蓝绿验证Gate和回滚Trigger现在再也不用担心“自定义验证脚本exit code为0但有告警”“Optional Step失败被忽略”“多个工具链的结果串不起来”的问题了——预演和正式部署的决策效率提高了至少80%排查问题的时间从平均40分钟降到了平均5分钟因为所有相关数据都在Gate的输出里一目了然。亮明观点/文章目标 (The “What” “How”)本文是一篇关于Harness NextGen Platform中响应合并的深度实战教程最佳实践指南目标读者是有一定Harness NG基础比如会创建CI/CD流水线、会用Stage/Step/Connector、会定义Harness Variable的DevOps工程师、SRE、Harness管理员。读完这篇文章你将学到核心概念什么是Harness的响应响应的类型有哪些响应合并的定义、边界、外延是什么响应提取如何从Harness的Stage、Step、工具链中提取响应如何定义Output Variable如何使用Context Variable响应转换如何把不同工具链的输出格式比如SARIF、XML、CSV转换成Harness统一的JSON格式如何使用Harness的Jinja2模板引擎响应合并如何使用Harness的内置函数比如merge()、concat()、zip()、map()、filter()合并多个响应如何定义自定义合并逻辑如何使用Harness的Pipeline Expression LanguagePEL响应应用如何把合并后的响应用于自动化决策Approval Gate、Rollback Trigger、统一部署报告PDF/HTML、自动化闭环更新代码仓库、创建Jira Ticket、触发PagerDuty告警实战演练用一个完整的电商微服务集群蓝绿预演生产的Harness CD流水线案例从零到一实现响应的提取、转换、合并、应用最佳实践Harness响应合并的常见陷阱与避坑指南、性能优化建议、成本考量、专家级建议行业发展与未来趋势Harness响应合并功能的发展历史、未来规划、DevOps行业中响应合并的最佳实践案例。二、 基础知识/背景铺垫 (Foundational Concepts)在正式开始实战演练之前我们需要先搞清楚Harness响应合并的核心概念、相关工具/技术概览——这些是我们后续操作的基础。2.1 核心概念定义2.1.1 Harness的“响应Response”是什么在Harness NextGen Platform中响应Response是指Stage、Step、工具链连接器执行后产生的所有结构化/非结构化数据的统称——注意这里的“执行后产生的数据”不仅包括“执行结果Execution Result”比如Pass/Fail/Skipped/Timeout还包括“执行输出Execution Output”比如Helm Install的Release Name、QA E2E的通过率、Snyk的Critical漏洞数量、自定义脚本的JSON输出。Harness把响应分成了两大类内置响应Built-in ResponseHarness为每个Stage、Step、工具链连接器默认提供的响应数据不需要我们主动定义就可以直接使用。内置响应通常存储在Harness的Context Variable上下文变量中Context Variable的命名规则通常是ContextType.Property或者ContextType.Object.Property。举几个常见的内置响应Context Variable的例子Stage的内置响应pipeline.stages.StageName.statusStage的执行结果比如SUCCESS、FAILED、SKIPPED、TIMEOUT、pipeline.stages.StageName.durationStage的执行时长单位是毫秒、pipeline.stages.StageName.startTsStage的开始时间戳、pipeline.stages.StageName.endTsStage的结束时间戳Kubernetes Deploy Step的内置响应pipeline.stages.StageName.execution.steps.StepName.output.releaseNameHelm/Kustomize部署的Release Name、pipeline.stages.StageName.execution.steps.StepName.output.deploymentStatusDeployment的状态比如DEPLOYED、FAILED、ROLLBACKED、pipeline.stages.StageName.execution.steps.StepName.output.resources部署的所有K8s资源的YAML列表Snyk Scan Step的内置响应pipeline.stages.StageName.execution.steps.StepName.output.criticalVulnerabilitiesCritical漏洞的数量、pipeline.stages.StageName.execution.steps.StepName.output.highVulnerabilitiesHigh漏洞的数量、pipeline.stages.StageName.execution.steps.StepName.output.sarifReportSnyk扫描结果的SARIF JSON字符串HTTP Step的内置响应pipeline.stages.StageName.execution.steps.StepName.output.httpStatusHTTP响应的状态码比如200、404、500、pipeline.stages.StageName.execution.steps.StepName.output.httpHeadersHTTP响应的头信息JSON格式、pipeline.stages.StageName.execution.steps.StepName.output.httpResponseBodyHTTP响应的主体内容字符串/JSON格式。所有内置响应的Context Variable列表可以在Harness NG Pipeline Editor的**右侧“Context Browser上下文浏览器”**中查看——这个工具非常好用后续我们会经常用到。自定义响应Custom Response我们主动定义的、不属于Harness内置响应的数据通常存储在Harness的Output Variable输出变量或者Context Variable的自定义对象中。自定义响应的数据来源可以是自定义Shell/PowerShell/Python脚本的输出比如用Python脚本查出的CDN回源失败URL列表自定义Jinja2模板渲染的结果比如用Jinja2模板把多个工具链的输出合并成一个统一的部署报告JSON从第三方API获取的额外数据比如从GitHub API获取当前Commit的Author信息、从Jira API获取当前Deployment对应的Issue列表。2.1.2 Harness的“响应合并Response Merging”是什么在Harness NextGen Platform中响应合并Response Merging是指将从多个Stage、Step、工具链中提取的响应包括内置响应和自定义响应按照业务逻辑或者合规要求进行“拼接、合并、计算、过滤、格式化”等操作生成一个新的、统一的、结构化的响应数据的过程。2.1.3 响应合并的“边界Boundary”与“外延Extension”1边界BoundaryHarness响应合并的边界是指响应合并操作可以在Harness NG Platform的哪些组件中执行以及响应合并操作的输入/输出范围是什么。执行组件的边界✅可以执行的组件Pipeline Expression LanguagePEL在任何可以使用PEL的地方比如Approval Gate的条件、Rollback Trigger的条件、Step的Input Variable、Output Variable的定义都可以执行简单的响应合并操作比如用merge()函数合并两个JSON对象、用concat()函数拼接两个数组Jinja2 Template Step内置模板步骤Harness NG的Pipeline Editor中有一个专门的**“Template模板”Step**或者叫“Jinja2 Template Step”可以执行复杂的响应合并操作比如用Jinja2的循环、条件、过滤器合并多个响应、生成统一的部署报告JSON/HTML自定义Shell/PowerShell/Python脚本Step如果Jinja2 Template Step的功能还不够用我们可以用自定义脚本Step执行更复杂的响应合并操作比如用Python的pandas库合并CSV格式的响应、用requests库从第三方API获取额外数据并合并Harness Custom Stage自定义阶段如果我们需要把响应合并的逻辑封装成一个可复用的组件可以把响应合并的Step比如Jinja2 Template Step、自定义脚本Step放在一个Custom Stage中然后在其他Pipeline中引用这个Custom Stage。❌不可以直接执行的组件Connector连接器Connector只负责连接第三方工具不负责处理响应Delegate代理Delegate只负责执行Pipeline的Step比如Helm Install Step、Snyk Scan Step不负责处理响应——但Delegate上可以运行自定义脚本Step所以响应合并的逻辑如果在自定义脚本Step中最终是在Delegate上执行的GitOps Sync StageGitOps同步阶段GitOps Sync Stage只负责从Git拉取Manifest并同步到K8s不负责处理响应——但GitOps Sync Stage的内置响应可以被提取出来然后在其他Stage中合并。输入/输出范围的边界✅可以作为输入的响应当前Pipeline中所有Stage/Step的内置响应当前Pipeline中所有Stage/Step的自定义Output Variable当前Pipeline的Input Variable输入变量当前Pipeline的Runtime Input运行时输入当前Pipeline的Secret密钥——注意Secret只能被读取不能被合并后输出到非Secret的地方比如部署报告否则会导致密钥泄露从第三方API获取的额外数据通过HTTP Step或者自定义脚本Step获取。✅可以作为输出的响应当前Stage的Custom Output Variable当前Step的Custom Output Variable统一的部署报告PDF/HTML/JSON——可以通过Harness的“Upload Artifact Step”上传到Harness Artifact Store比如S3、GCS、Harness自带的Artifact Store或者通过HTTP Step发送到第三方工具比如Slack、Jira、EmailApproval Gate的注释Rollback Trigger的注释Alerting Rule的通知内容。❌不可以作为输出的响应Secret密钥——合并后不能输出到非Secret的地方当前Pipeline的Input Variable/Runtime Input的修改——Input Variable/Runtime Input只能被读取不能被修改后输出除非我们把修改后的值存到Custom Output Variable中。2外延ExtensionHarness响应合并的外延是指响应合并操作可以和Harness NG Platform的哪些其他功能结合使用以及响应合并操作可以解决哪些DevOps场景中的问题。可以结合使用的功能Approval Gate审批门把合并后的响应用于Automated Approval Gate的条件比如“所有微服务Deploy成功 Snyk Critical漏洞数量0 Datadog 5xx错误率0.1% QA E2E通过率100%”或者用于Manual Approval Gate的注释给审批人展示所有相关数据帮助审批人快速做出决策Rollback Trigger回滚触发器把合并后的响应用于Rollback Trigger的条件比如“蓝绿验证Gate的响应中CDN回源失败URL数量0 OR 漏同步的配置键数量0”或者用于Rollback Trigger的注释给SRE展示回滚的原因和所有相关数据Alerting Rule告警规则把合并后的响应用于Alerting Rule的通知内容比如给Slack/Email/PagerDuty发送告警包含Pipeline的执行结果、所有相关Stage/Step的响应、合并后的决策结果Artifact Management制品管理把合并后的部署报告作为Artifact上传到Harness Artifact Store方便后续追溯Issue Management问题管理把合并后的响应比如Snyk的Critical漏洞列表、QA E2E的失败用例列表通过HTTP Step或者自定义脚本Step发送到Jira/Linear自动创建IssueGitOpsGitOps把合并后的响应比如Kustomize Overlay渲染后的最终YAML、Snyk的SARIF扫描结果通过Git Commit Step提交到Git仓库Templates模板把响应合并的逻辑封装成Pipeline Template/Stage Template/Step Template然后在其他Pipeline中引用提高复用性Governance治理把合并后的响应用于Harness Policy as CodeOPA的条件确保Pipeline的执行符合合规要求比如“合并后的响应中Snyk Critical漏洞数量必须0否则Pipeline失败”。可以解决的DevOps场景中的问题统一决策场景比如预演生产的蓝绿验证、正式生产的部署决策、回滚触发决策统一报告场景比如CI构建报告、CD部署报告、安全扫描报告、QA测试报告自动化闭环场景比如自动创建Jira Issue标注安全漏洞、自动提交SARIF扫描结果到GitHub Security Advisories、自动触发PagerDuty告警标注QA E2E失败、自动触发回滚流程数据追溯场景比如把合并后的部署报告作为Artifact上传到Harness Artifact Store方便后续追溯某个Deployment的所有相关数据多服务协调场景比如微服务集群的同时部署验证、多服务的健康检查合并、多服务的测试报告合并。2.2 相关工具/技术概览在Harness NextGen Platform中实现响应合并我们需要用到以下几个核心工具/技术2.2.1 Harness Pipeline Expression LanguagePELHarness Pipeline Expression Language简称PEL是Harness NG Platform专门为Pipeline设计的表达式语言用于在Pipeline的各种组件比如Approval Gate的条件、Rollback Trigger的条件、Step的Input Variable、Output Variable的定义中执行简单的计算、过滤、合并操作。PEL的语法非常简单类似于JavaScript的简化版或者Python的简化版——它支持以下几种基本操作变量访问用.或者[]访问变量的属性或者数组的元素比如pipeline.stages.DeployQA.status、pipeline.stages.DeployQA.execution.steps.ImageValidation.output.failedUrls[0]算术运算支持、-、*、/、%等算术运算符比如pipeline.stages.DeployQA.duration / 1000把毫秒转换成秒比较运算支持、!、、、、等比较运算符比如pipeline.stages.DeployQA.status SUCCESS、pipeline.stages.SnykScan.output.criticalVulnerabilities 0逻辑运算支持与、||或、!非等逻辑运算符比如pipeline.stages.DeployQA.status SUCCESS pipeline.stages.SnykScan.output.criticalVulnerabilities 0字符串运算支持拼接字符串比如Pipeline pipeline.name executed in (pipeline.stages.DeployQA.duration / 1000) seconds内置函数Harness PEL提供了大量的内置函数用于执行常见的操作——这也是我们实现简单响应合并的核心工具字符串函数比如length()获取字符串长度、upper()把字符串转换成大写、lower()把字符串转换成小写、trim()去除字符串首尾的空格、split()把字符串按照分隔符拆分成数组、join()把数组按照分隔符拼接成字符串数组函数比如length()获取数组长度、concat()拼接两个数组、merge()合并两个数组或者两个JSON对象注意PEL的merge()函数的行为和Jinja2的merge()函数的行为有些不一样后续我们会详细对比、zip()把两个数组的元素一一对应组合成一个新的数组、map()对数组的每个元素执行一个操作生成一个新的数组、filter()过滤数组的元素生成一个新的数组、find()在数组中查找符合条件的第一个元素、findAll()在数组中查找符合条件的所有元素、sort()对数组的元素进行排序、reverse()反转数组的元素JSON函数比如toJson()把对象转换成JSON字符串、fromJson()把JSON字符串转换成对象、jsonPath()用JSONPath表达式从JSON对象中提取数据时间函数比如now()获取当前时间戳、formatDate()把时间戳格式化成指定的日期时间字符串、parseDate()把日期时间字符串解析成时间戳其他函数比如if()三元运算符的另一种写法、default()如果变量为空或者未定义返回默认值、isNull()判断变量是否为空、isUndefined()判断变量是否未定义、coalesce()返回第一个非空、非未定义的变量。所有PEL内置函数的详细文档可以在Harness官方文档的“Pipeline Expression Language (PEL) Reference”页面查看。2.2.2 Jinja2 Template EngineJinja2模板引擎Jinja2是一个基于Python的、功能强大的、可扩展的模板引擎被广泛应用于Flask、Django等Python Web框架中——Harness NG Platform把Jinja2集成到了Pipeline Editor中作为一个专门的**“Template模板”Step**或者叫“Jinja2 Template Step”用于执行复杂的响应合并操作。Jinja2的语法比PEL复杂得多但功能也强大得多——它支持以下几种核心功能变量访问用{{ variable }}或者{{ variable.property }}或者{{ variable[index] }}访问变量的属性或者数组的元素和PEL类似条件语句用{% if condition %}、{% elif condition %}、{% else %}、{% endif %}实现条件判断循环语句用{% for item in list %}、{% endfor %}实现循环支持loop.index、loop.index0、loop.first、loop.last等循环变量过滤器Filters用{{ variable | filter }}或者{{ variable | filter1 | filter2 }}对变量进行处理——Jinja2提供了大量的内置过滤器Harness还额外提供了一些和DevOps相关的过滤器Jinja2内置过滤器比如length()获取字符串/数组长度、upper()把字符串转换成大写、lower()把字符串转换成小写、trim()去除字符串首尾的空格、split()把字符串按照分隔符拆分成数组、join()把数组按照分隔符拼接成字符串、default()如果变量为空或者未定义返回默认值、sort()对数组的元素进行排序、reverse()反转数组的元素、tojson()把对象转换成JSON字符串支持格式化选项、fromjson()把JSON字符串转换成对象Harness额外提供的过滤器比如base64encode()把字符串/base64编码、base64decode()把base64编码的字符串解码、sha256sum()计算字符串的SHA256哈希值、md5sum()计算字符串的MD5哈希值、yaml()把对象转换成YAML字符串、fromyaml()把YAML字符串转换成对象、jsonpath()用JSONPath表达式从JSON对象中提取数据。宏Macros用{% macro name(parameters) %}、{% endmacro %}定义可复用的模板片段类似于编程语言中的函数继承Inheritance用{% extends base_template %}、{% block name %}、{% endblock %}实现模板继承类似于面向对象编程中的继承——不过在Harness的Template Step中我们通常不需要用到继承因为我们的模板是一次性的除非我们把模板封装成Step Template。所有Jinja2内置过滤器和Harness额外提供的过滤器的详细文档可以在Harness官方文档的“Use Jinja2 Templates in Harness”页面查看。2.2.3 Harness Context Browser上下文浏览器Harness Context Browser是Harness NG Pipeline Editor的右侧面板中的一个工具用于查看和插入当前Pipeline中所有可用的Context Variable、Input Variable、Runtime Input、Secret、Output Variable——这是我们实现响应提取的核心工具因为它可以帮我们快速找到我们需要的变量不需要记住复杂的命名规则。Context Browser的使用方法非常简单在Harness NG Pipeline Editor中打开右侧面板如果右侧面板没有打开可以点击Pipeline Editor右上角的“”按钮打开点击右侧面板中的**“Context上下文”**标签页在Context标签页中你可以看到以下几个分类Pipeline当前Pipeline的Context Variable比如pipeline.name、pipeline.executionId、pipeline.startTsStages当前Pipeline中所有Stage的Context Variable比如每个Stage的status、duration、startTs、endTs、内置响应、自定义Output VariableInput Variables当前Pipeline的Input VariableRuntime Inputs当前Pipeline的Runtime InputSecrets当前Pipeline的Secret注意Secret的内容是隐藏的只能用{{ secrets.secretName }}的形式插入到Step的Input Variable中Artifacts当前Pipeline中所有Step上传的ArtifactConnectors当前Pipeline中所有Connector的Context Variable比如Connector的ID、名称、类型——不过Connector的内容通常不需要用到。找到你需要的变量后点击变量右侧的**“Copy复制”按钮或者“Insert插入”**按钮就可以把变量的表达式复制到剪贴板或者插入到当前正在编辑的输入框中。2.3 本章小结在本章中我们首先搞清楚了Harness响应合并的核心概念响应ResponseStage、Step、工具链连接器执行后产生的所有结构化/非结构化数据的统称分为内置响应和自定义响应响应合并Response Merging将从多个Stage、Step、工具链中提取的响应按照业务逻辑或者合规要求进行“拼接、合并、计算、过滤、格式化”等操作生成一个新的、统一的、结构化的响应数据的过程响应合并的边界可以在PEL、Jinja2 Template Step、自定义脚本Step、Custom Stage中执行输入可以是当前Pipeline中所有Stage/Step的内置响应、自定义Output Variable、Input Variable、Runtime Input、Secret、从第三方API获取的额外数据输出可以是当前Stage/Step的Custom Output Variable、统一的部署报告、Approval Gate的注释、Rollback Trigger的注释、Alerting Rule的通知内容响应合并的外延可以和Approval Gate、Rollback Trigger、Alerting Rule、Artifact Management、Issue Management、GitOps、Templates、Governance等功能结合使用解决统一决策、统一报告、自动化闭环、数据追溯、多服务协调等DevOps场景中的问题。然后我们介绍了Harness响应合并的三个核心工具/技术Harness Pipeline Expression LanguagePEL用于执行简单的响应合并操作Jinja2 Template Engine用于执行复杂的响应合并操作Harness Context Browser用于快速找到我们需要的变量实现响应提取。在下一章中我们将进入核心实战演练环节——用一个完整的电商微服务集群蓝绿预演生产的Harness CD流水线案例从零到一实现响应的提取、转换、合并、应用。
