云效 Pipeline as Code 来了！这些场景，用好它效率翻倍！

从可视化编排到支持 YAML 编排

云效流水线 Flow 是开箱即用的企业级持续集成和持续交付工具，支持丰富的代码源、构建、自动化测试工具、多种部署类型和部署方式，与阿里云深度集成，还提供多种企业级特性，助力企业高效完成从开发到上线 CICD 过程。

在业界，流水线产品通常有 2 种使用方式，一种是可视化界面操作，另一种是使用 YAML 语言像写代码一样编排流水线。

自 2020 年上线以来，云效 Flow 一直以其白屏化操作、开箱即用、简单易上手、与阿里云深度集成等特性，赢得了数万家企业的信赖。

去年，为了帮助企业解决多条流水线快速创建、批量管理、满足跳过/分支等复杂流程编排场景，云效全新上线了 Pipeline as Code 能力。企业可以用 YAML 方式创建流水线，基于云效提供的 YAML 模板，只需少量修改，就可以快速编排出满足业务场景的流水线。

简单几步就可以把 YAML 用起来

提到 YAML，不少同学首先想到的是使用门槛。云效 Flow 内置了丰富的 YAML 模板以及 YAML 手册，支持 YAML 语法自动补齐、实时校验并推荐修复方案，以及多种快捷键操作等，旨在帮助开发者降低 YAML 使用门槛，提升 YAML 编写效率。

1）内置丰富的流水线 YAML 模板

Flow 内提供了常用的流水线 YAML 模板，包含 Java、PHP、Node.js、Go、Python、.Net Core、C++ 等多种语言的常用构建、部署模板。新建流水线时，选择合适的 YAML 模板后，只需少量修改，就可以快速编排出满足业务场景的流水线。

2）提供常用任务 YAML 模板

一条流水线往往包含多个任务，Flow 提供了常用任务 YAML 模板，包含代码扫描、测试、构建、部署以及其他工具等。选择需要的任务步骤后，即可一键复制示例 YAML 到流水线中，快速编排流水线。

3）编辑器内置 YAML 手册，随手查阅

为了方便 YAML 的编写，云效 Flow YAML 编辑器内置了 YAML 手册，开发者可以一边编写 YAML，一边查阅手册。同时，YAML 手册开启自动定位，文档支持自动切换到鼠标光标定位的语法篇幅，做到随写随看，贴身“小抄”。

4）支持 YAML 语法自动补齐

不仅如此，YAML 编辑器还支持语法自动补齐，包括静态语法片段补齐、静态语法关键字补齐、动态资源 ID 等自动补齐（如构建集群 ID、主机组 ID、服务连接 ID 等），支持 Cmd + I 快捷键唤起自动补全。

5）支持 YAML 语法实时校验、推荐修复方案

Flow 的 YAML 编辑器还支持语法实时校验，支持代码行内实时展示错误标记，鼠标悬浮查看错误详情及修复方案。支持问题面板统一查看错误、错误原因、修复方案，以及错误行列坐标，点击错误就能自动定位到相关代码行。

这些场景用 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: master
stages:
  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: master
stages:
  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: master
stages:
  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: master
defaultWorkspace: my_repo1
stages:
  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:
            name: 执行命令
            step: Command
            with:
              run: |
                echo This is test job2...
      scan_job2:
        name: app2代码扫描
        steps:
          command_step:
            name: 执行命令
            step: Command
            with:
              run: |
                echo This is scan job2...
      build_job1:
        name: app1构建
        # 声明依赖任务，app1构建依赖app1单元测试和代码扫描任务都完成
        needs: 
          - test_job1
          - scan_job1
        steps:
          command_step:
            name: 执行命令
            step: Command
            with:
              run: |
                echo This is build job2...
      build_job2:
        name: app2构建
        # 声明依赖任务，app2构建依赖app2单元测试和代码扫描任务都完成
        needs: 
          - test_job2
          - scan_job2
        steps:
          command_step:
            name: 执行命令
            step: Command
            with:
              run: |
                echo This is build job2...
  deploy_stage:
    name: 部署
    jobs:
      deploy_job1:
        name: app1部署
        steps:
          command_step:
            name: 执行命令
            step: Command
            with:
              run: echo This is deploy env 1...
      deploy_job2:
        name: app2部署
        # 声明依赖任务，app2部署依赖app1部署任务完成
        needs: deploy_job1
        steps:
          command_step:
            name: 执行命令
            step: Command
            with:
              run: echo This is deploy env 2...

4）支持 template 语法，满足多个相同或类似逻辑 Job 批量配置场景

云效 Flow 支持使用 template 语法来动态渲染流水线 YAML，满足多个相同或类似逻辑 Job 批量配置场景，满足多 Job 按需动态生成场景，帮助降低流水线 YAML 重复代码，灵活编排多任务。同时，还支持使用 {{ }} 定义模板，遵循 go template 原生语法。

典型使用场景有：

多操作系统、多 SDK 版本兼容性测试场景：遍历 [“linux”, “windows”] 2 个操作系统、遍历 [“10”, “11”, “17”] 3 个 JDK 版本，使用 template 的 range 循环，生成 6 个相同逻辑的 Job。
多应用动态按需构建部署：流水线配置多个应用代码源、多个应用构建任务、多个应用部署任务，一次迭代仅涉及部分应用更新，可根据运行时输入环境变量如 appnames 动态构建部署有修改的应用。

关于这部分能力，我们将在下篇文章中详细介绍。

云效 Flow 邀你来评测：

如果你对云效 Flow 的 Pipeline as Code 能力感兴趣，欢迎点击此处，参加云效 Flow 的评测活动，发布你对 Flow 的看法。

4 月 26 日 - 6 月 15 日期间，发布评测内容，将有机会获得如下奖励：