[yun]

Posted on Jun 22

从“能用”到“好用”：高效运用CloudBees CD/RO 的使用心得

#devops

在软件交付的世界里，CI/CD 流水线已经不是什么新鲜事。我们用 Jenkins、GitLab CI 或其他工具构建、测试、打包我们的应用。但当交付的规模和复杂度上升时，尤其是在需要协调多个应用、跨多个环境、并涉及严格发布流程的企业场景下，简单的 CI 流水线就显得力不存心了。

这就是 CloudBees CD/RO (Continuous Delivery / Release Orchestration) 发挥作用的地方。它不仅仅是一个执行脚本的工具，更是一个强大的平台，用于建模、管理和可视化你的整个软件交付流程。

然而，很多团队仅仅是用它来替代旧的部署脚本，没有真正发挥其潜力。今天，我想分享一些心得，帮助你从“能用” CloudBees CD/RO，迈向“好用”和“高效”。

1. 核心概念：像写代码一样思考你的部署

CloudBees CD/RO 的核心是其强大的对象模型。要高效使用它，首先必须理解并接受这个模型。把它想象成部署世界的“面向对象编程”：

Application (应用): 这是你要部署的东西。它不是代码库，而是包含了部署逻辑（Components）和流程（Processes）的集合。一个应用可以包含一个后端服务、一个前端UI和一个数据库脚本。
Environment (环境): 这是你要部署到的地方（如 DEV, QA, PROD）。它不关心“如何部署”，只关心“部署到哪”，并存储该环境特定的配置，如服务器地址、数据库凭证等。
Process (流程): 这是“如何做”的定义。例如，一个 Deploy 流程可能包含“从 Artifactory 拉取构件”、“停止应用服务器”、“部署文件”、“启动应用服务器”等步骤。

高效实践的关键在于：将部署逻辑（Process）与环境配置（Environment）彻底分离。你的部署流程应该是一套代码，无需任何修改就能在所有环境中运行。

2. “一切皆代码”：全面拥抱 DSL

如果你还在 UI 上拖拖拽拽来创建流程，请立刻停下来。CloudBees CD/RO 提供了强大的 Groovy/Kotlin DSL（领域特定语言），让你能够以代码的形式定义所有配置。

为什么必须用 DSL？

版本控制: 你可以将你的整个发布流程和应用模型存储在 Git 中，享受版本控制、分支、合并带来的所有好处。
代码审查: 对发布流程的任何修改都必须通过 Pull Request 和同行评审，极大地提高了变更的可靠性。
可复用性: 你可以编写通用的 DSL 模块，并在多个项目中共享。
自动化: 可以通过脚本自动创建和更新成百上千个应用，这在微服务架构中至关重要。

示例：用 DSL 定义一个简单的应用

// file: project/applications/my-web-app.groovy

application 'my-web-app', {
    projectName = 'My Awesome Project'
    description = 'Main web application'

    // 定义一个组件，指向构件仓库
    component 'war-file', {
        artifactName = 'my-app'
        artifactVersion = '$[pipeline.buildNumber]' // 使用运行时参数
        retrievalMode = 'artifact'
        artifactType = 'REPOSITORY'
        repositoryName = 'artifactory-prod' // 指向配置好的仓库
    }

    // 定义一个部署流程
    process 'deploy', {
        formalParameter 'target_server', required: true, type: 'entry'

        step 'retrieve_artifact', {
            command = null
            subprocedure = 'retrieve'
            subprocedureType = 'component'
            actualParameter 'componentName', 'war-file'
            actualParameter 'target', '/tmp'
        }

        step 'deploy_to_tomcat', {
            command = "scp /tmp/my-app-$[artifactVersion].war $[/myJob/target_server]:/opt/tomcat/webapps/"
            shell = 'bash'
        }
    }
}

通过 evalDsl 命令，你就可以将这段代码应用到你的 CloudBees CD/RO 服务器上。

3. 可重用性是关键：构建模块化的流程

不要在应用流程（Application Process）中编写具体的执行逻辑。相反，你应该创建通用的程序（Procedures），然后在应用流程中调用它们。

反模式 ❌:

在 my-web-app 的 deploy 流程中硬编码所有 Tomcat 部署细节。

最佳实践 ✅:

创建一个名为 Tomcat/Deploy 的通用 Procedure。
这个 Procedure 接受参数，如 warFilePath, targetServer, tomcatManagerUser。
在 my-web-app 的 deploy 流程中，简单地调用这个通用 Procedure，并传入参数。

这样做的好处是显而易见的。当你需要部署另一个 Java Web 应用时，你只需复用 Tomcat/Deploy 这个 Procedure，而无需重写任何逻辑。如果 Tomcat 的部署方式需要更新，你只需要修改这一个地方。

参数化是你的好朋友:
CloudBees CD/RO 的参数系统非常强大。学会使用 $[propertyName] 语法来引用属性。

$[formal_parameter_name]：引用流程的输入参数。
$[credential:credName.userName]：安全地引用凭证。
[/myEnvironment/server_ip]：从环境模型中获取属性。

4. 编排的力量：从部署到发布

CloudBees CD/RO 的 “RO” (Release Orchestration) 是它的真正亮点。一个发布（Release）不仅仅是部署一个应用，而是协调多个应用、多个团队、自动化测试、手动审批和业务决策的复杂过程。

利用发布流水线（Release Pipeline）来建模你的价值流：

阶段 (Stages): 将发布过程分解为逻辑阶段，如 SI, QA, PROD。
闸 (Gates): 在阶段之间设置自动或手动的审批门。例如，只有当自动化测试通过率 > 95% 并且 SI 经理手动批准后，才能进入 QA 阶段。
任务 (Tasks): 在每个阶段内定义具体任务，这些任务可以是并行的，也可以是串行的。
- 部署 backend-service。
- 部署 frontend-ui。
- Parallel Process（并行执行）运行集成测试。
- 通知 Jira 更新工单状态。

通过这种方式，你可以将从代码提交到生产上线的整个路径可视化、自动化和可审计。

5. 集成与插件：打造你的 DevOps 工具链

CloudBees CD/RO 不是要取代你所有现有的工具，而是要将它们“粘合”在一起。它拥有一个庞大的插件库，可以轻松与你的 DevOps 生态系统集成：

CI 服务器: 用 Jenkins/GitLab CI 做好构建和单元测试，然后触发 CloudBees CD/RO 进行部署和发布。
源码管理: 与 Git 集成，自动触发流程。
构件库: 从 Artifactory/Nexus 拉取构件。
配置管理: 调用 Ansible Playbook 或 Chef Recipe 来配置环境。
测试工具: 集成 Selenium, JMeter 等进行自动化测试，并根据结果驱动流水线。
工单系统: 与 Jira/ServiceNow 集成，实现工单状态的自动更新和关联。

总结

高效使用 CloudBees CD/RO 的核心思想是：把它当作一个开发平台，而不是一个运维工具。

建模优于脚本: 用其对象模型（应用、环境）来组织你的交付物。
代码优于点击: 全面拥抱 DSL，将你的交付流程纳入版本控制和代码审查。
抽象优于具体: 构建可重用的、模块化的 Procedure，而不是在每个应用中重复造轮子。
编排优于执行: 利用发布流水线来管理端到端的价值流，而不仅仅是单个部署任务。

将这些原则付诸实践，你的交付流程将不仅仅是自动化，更是变得可靠、可扩展且易于管理。你将从救火队员的角色，转变为交付流程的架构师。

希望这些技巧对你有用！欢迎在评论区分享你的经验和问题。

DEV Community