openSUSE:OpenStack 和 Crowbar 开发过程

在 openSUSE 上开发、测试和持续集成 OpenStack 和 Crowbar

我们使用 Jenkins 自动将上游 git 仓库中的更改打包成 rpm，在 openSUSE 环境中。如果构建和安装成功，Jenkins 会将这些更改提交到开放构建服务 (OBS)，OBS 会自动构建和发布规范包和镜像。

详细工作流程

让我们从代码更改到最终包，再到最终产品，按时间顺序开始。

OpenStack

让我们首先查看对已发布 OpenStack 版本（图表和文本使用 Liberty 版本）的更改。

OpenStack 在 git.openstack.org 上开发，一旦 Liberty 分支发生提交，每日 Jenkins trackupstream 任务 会检出更改，创建新的 tar 包，构建和安装包，如果成功，则将其提交到 OBS 暂存项目。

一旦所有包及其依赖项构建完成，Jenkins 会运行测试任务（例如功能测试：cloud-cleanvm）。如果新包通过这些测试，该包将自动从 OBS 暂存项目（例如 Cloud:OpenStack:Liberty:Staging）推送到主项目（例如 Cloud:OpenStack:Liberty）。所有包都会一起推送，以确保版本都兼容。

openSUSE 发行版始终提供最新的稳定 OpenStack 客户端版本（撰写本文时为 Newton）。openSUSE 的包提交工作流程与常规 OpenStack 打包工作分离。为了方便 openSUSE:Factory 开发模型，包会在 Cloud:OpenStack:Factory 项目中准备，并定期提交到 openSUSE:Factory 进行审查和包含在 openSUSE 开发分支 (Factory) 中。

Chef

目前 Chef 10 和 11 都直接从上游构建，分别在 systemsmanagement:chef:10 和 systemsmanagement:chef:master 中构建。systemsmanagement:chef:10:staging 是 systemsmanagement:chef:10 的一个分支，允许测试打包更改，而不会破坏整体构建。但是，由于我们没有定期跟踪上游更改，因此这里没有涉及 Jenkins 任务。

Crowbar

更改通过 github pull requests 发送到 https://github.com/crowbar 上游仓库。这受到手动同行代码审查、Travis 和持续 CI 检查的限制。

systemsmanagement:crowbar:3.0:staging 紧密跟踪 github 上游，此过程通过名为 'crowbar-trackupstream' 的 Jenkins 任务自动执行。此外，Travis CI 运行相同的上游单元测试。