Tony Ding's Blog

OpenStack 社区持续集成简介

社区工具 云计算

什么是持续集成

  持续集成是一种软件开发时间，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成问题，让团队能够更快的开发内聚的软件。

持续集成的前提

    - 统一的代码库
    - 自动构建
    - 自动测试
    - 每个人每天都要想代码库主干提交代码
    - 每次迭代递交后都会在持续集成服务器触发一次构建
    - 保证快速构建
    - 模拟生产环境的自动测试
    - 每个人都可以很容易的获取最新可执行的应用程序
    - 每个人都清楚正在发生的状况
    - 自动化部署

OpenStack社区CI体系

如图所示，为OpenStack社区CI框架，主要使用如下几种组件：

    - Gerrit：代码审查和git资源库管理
    - Zull、Git：代码库控制系统。
    - Jenkins：持续集成服务器，构建持续集成任务、用于定时管理任务。
    - Nodepool：部署在OpenStack云上的智能的Jenins衍生工具。
    - Github：用于存放Gerrit上被Merge的代码。
    - 其他

  持续测试软件作为持续集成的重要组成部分，为软件质量保证和改进体系的重要手段，社区用到的持续测试系统如下所示：

    - Selenium：用于自动化测试Dashboard UI
    - Tempest: 用于自动化测试OpenStack API
    - Rally: 用于自动化测试OpenStack性能
    - Unit Tests： 用于每个项目的单元测试
    - Testlink系统： 用于管理各个测试用例。
    - 其他

  开发人员在Gerrit上，提交了一个Patch、Commit，那怎么来确保这个新的Patch不会影响别的其他代码，以及这个patch本身是OK的呢。那就是用冒烟测试方法。现在，我们的一个暂时做法是，将这个新的Patch打成一个rpm包，放在一个集成了其他测试工具的由DevStack方法（均用自己产品的rpm包）部署的all-in-one平台上，做回归测试。

18 Aug 2016 #持续集成