云效流水线 Flow 是开箱即用的企业级持续集成和持续交付工具，支持丰富的代码源、构建、自动化测试工具、多种部署类型和部署方式，与阿里云深度集成，还提供多种企业级特性，助力企业高效完成从开发到上线 CICD 过程。
在业界，流水线产品通常有 2 种使用方式，一种是可视化界面操作，另一种是使用 YAML 语言像写代码一样编排流水线。
自 2020 年上线以来，云效 Flow 一直以其
白屏化操作、开箱即用、简单易上手、与阿里云深度集成
等特性，赢得了数万家企业的信赖。
去年，为了帮助企业解决多条流水线快速创建、批量管理、满足跳过/分支等复杂流程编排场景，云效全新上线了 Pipeline as Code 能力。企业可以用 YAML 方式创建流水线，基于云效提供的 YAML 模板，只需少量修改，就可以快速编排出满足业务场景的流水线。
提到 YAML，不少同学首先想到的是使用门槛。云效 Flow 内置了丰富的 YAML 模板以及 YAML 手册，支持 YAML 语法自动补齐、实时校验并推荐修复方案，以及多种快捷键操作等，旨在帮助开发者降低 YAML 使用门槛，提升 YAML 编写效率。
Flow 内提供了常用的流水线 YAML 模板，包含 Java、PHP、Node.js、Go、Python、.Net Core、C++ 等多种语言的常用构建、部署模板。新建流水线时，选择合适的 YAML 模板后，只需少量修改，就可以快速编排出满足业务场景的流水线。
一条流水线往往包含多个任务，Flow 提供了常用任务 YAML 模板，包含代码扫描、测试、构建、部署以及其他工具等。选择需要的任务步骤后，即可一键复制示例 YAML 到流水线中，快速编排流水线。
为了方便 YAML 的编写，云效 Flow YAML 编辑器内置了 YAML 手册，开发者可以一边编写 YAML，一边查阅手册。同时，YAML 手册开启自动定位，文档支持自动切换到鼠标光标定位的语法篇幅，做到随写随看，贴身“小抄”。
不仅如此，YAML 编辑器还支持语法自动补齐，包括静态语法片段补齐、静态语法关键字补齐、动态资源 ID 等自动补齐（如构建集群 ID、主机组 ID、服务连接 ID 等），支持 Cmd + I 快捷键唤起自动补全。
Flow 的 YAML 编辑器还支持语法实时校验，支持代码行内实时展示错误标记，鼠标悬浮查看错误详情及修复方案。支持问题面板统一查看错误、错误原因、修复方案，以及错误行列坐标，点击错误就能自动定位到相关代码行。
1）快速复制 YAML 或调用 OpenAPI，轻松管理多条流水线
使用可视化方式操作流水线，当流水线多的时候，每条流水线修改起来比较复杂。有了 YAML 之后，开发者复制 YAML，只需做少量的修改，即可轻松配置多条流水线。
同时，基于 YAML ，云效提供了流水线创建、更新的 OpenAPI，企业可以调用这些 OpenAPI，轻松批量管理多条流水线，实现三方系统集成。
2）支持 condition 条件判断，满足跳过/分支等复杂流程编排场景
云效 Flow 流水线 YAML 支持 condition 控制某个 Job 是否执行，满足跳过、分支等复杂流程编排场景。典型场景示例如下：
分支场景：一次构建按需部署多环境
研发团队场景有多套测试环境，按需使用。可以根据指定环境名称按需部署到测试环境。
sources: my_repo: type: gitSample name: 示例代码源 endpoint: https://atomgit.com/flow-example/spring-boot.git branch: masterstages: build_stage: name: 构建 jobs: build_job: name: 构建任务 steps: command_step: name: 执行命令 step: Command with: run: | echo This is build job... deploy_stage: name: 部署测试环境 jobs: deploy_job1: name: 部署测试环境一套 # 根据指定环境名按需部署 condition: | "${ENVNAME}" == "EVN1" steps: command_step: name: 执行命令 step: Command with: run: echo This is deploy env 1... deploy_job2: name: 部署测试环境二套 # 根据指定环境名按需部署 condition: | "${ENVNAME}" == "EVN2" steps: command_step: name: 执行命令 step: Command with: run: echo This is deploy env 2...
跳过场景：非窗口期发布需要额外审批；窗口期无需审批，直接跳过
生产发布场景，非发布窗口期需要人工审核、窗口期可以跳过人工审核。
sources: my_repo: type: gitSample name: 示例代码源 endpoint: https://atomgit.com/flow-example/spring-boot.git branch: masterstages: build_stage: name: 构建 jobs: build_job: name: 构建任务 steps: command_step: name: 执行命令 step: Command with: run: | echo This is build job... approve_stage: name: 审批 jobs: approve_job: name: 人工卡点 # 运行分支为 master 时执行审批任务，请替换为实际的审批判断条件 condition: | "${CI_COMMIT_REF_NAME}" == "master" component: ManualValidate with: validatorType: users # 验证者类型为企业成员，通过阿里云 ID 确定审核人员 validateMethod: and # 验证方式 and:会签（须所有审批人同意）or:或签（一名审批人同意或拒绝即可） validators: - 290591284908846966 #通过阿里云控制台获取阿里云 ID deploy_stage: name: 部署 jobs: deploy_job: name: 部署任务 steps: command_step: name: 执行命令 step: Command with: run: echo This is deploy job...
跳过场景：前端应用未更新跳过构建，仅构建后端应用
某些前后端应用依赖场景，先构建前端应用生成静态文件、后端应用构建时引用前端静态文件，但并不是每个需求都涉及前端应用修改，则可根据条件判断前端应用是否需要构建。
示例中，使用流水线自定义环境变量 "${FRONT_APP_CHANGED}" == "true" 作为任务 condition 条件，变量值为 true 时执行前端应用构建，否则跳过。
sources: my_repo: type: gitSample name: 示例代码源 endpoint: https://atomgit.com/flow-example/spring-boot.git branch: masterstages: build_stage: name: 构建 jobs: front_build_job: name: 前端应用构建 condition: | "${FRONT_APP_CHANGED}" == "true" steps: command_step: name: 执行命令 step: Command with: run: | echo This is front app build job... backend_build_job: name: 后端应用构建 needs: front_build_job steps: command_step: name: 执行命令 step: Command with: run: | echo This is backend app build job... deploy_stage: name: 部署 jobs: deploy_job: name: 部署任务 steps: command_step: name: 执行命令 step: Command with: run: echo This is deploy job...
3）支持 needs 依赖设置，支持跨阶段并行执行，流程执行效率 up up
跨阶段依赖场景：多应用并行测试构建，app1 构建任务依赖 app1 单元测试和 app1 代码扫描任务都完成，app2 构建任务依赖 app2 单元测试和 app2 代码扫描任务都完成，app1 和 app2 之间测试和构建阶段无相互依赖可以并行执行，用于提升效率。
sources: my_repo1: type: gitSample name: app1代码源 endpoint: https://atomgit.com/flow-example/spring-boot.git branch: master my_repo2: type: gitSample name: app2代码源 endpoint: https://atomgit.com/flow-example/node-expressjs.git branch: masterdefaultWorkspace: my_repo1stages: build_stage: name: 构建 jobs: test_job1: name: app1单元测试 steps: command_step: name: 执行命令 step: Command with: run: | echo This is test job1... scan_job1: name: app1代码扫描 steps: command_step: name: 执行命令 step: Command with: run: | echo This is scan job1... test_job2: name: app2单元测试 steps: command_step:
