使用 Gitlab CI 构建 web 应用

铁路领域是一个快速变化的环境。为了更快地为你提供最新的改进和修复,Captain Train这个web-app要经常进行更新,有时每天要更新多次。

你是不是很想知道我们是如何平滑地构建和部署这个app的呢?那就接着往下读:下面列出了我们工程过程中的一些技术要点。

从Jenkins到GitLab-CI

我们过去使用Jenkins构建我们的web-app。Jenkins是一个稳定且成熟的构建方案,它每分钟都会对我们的仓库进行轮询,并且构建合适的集成产品分支。

然而最近我们改用一个新的系统来构建我们的web-app。我们使用GitLab的一个自托管实例来托管源代码和执行合并请求。它很优秀而且开源,并且具有一个集成的构建系统:GitLab-CI

看它有点像Travis,但它是集成的:只是在你的仓库根目录下增加了一个定制的.gitlab-ci.yml文件,GitLab会按照你指定的方式自动开始构建app。

那么推荐的理由是什么呢?

稳定的Docker化构建

Jenkins 构建完全是在资源紧张服务器上进行,这就使得构建的速度缓慢且不稳定。比如,我们注意到在测试期间PhantomJS的崩溃随机发生过多次:看起来很不像 是在同一时刻运行在同一机器上的多个构建,并且某一个PhantomJS进程崩溃会造成其它的所有进程终止。

所以迁移的第一步就是要使构建独立运行在Docker容器中。这样:

  • 每个构建和其它的构建之间彼此独立,进程的随机崩溃不会彼此影响。
  • 在不同的架构上构建同一个项目很容易,这是一个好消息,因为我们需要其支持多个Debian版本。
  • 项目维护人员对构建环境的设置有更多的控制: 在共享构建机器上升级一个SDK时无需担心是否是管理员用户。

可伸缩

GitLab-CI可以让我们很容易地添加更多runner。既然构建是在Docker容器中进行, 我们就没有必要配置runner专门采用我们的构建工具:任何一个开箱即用服务器都可以。

一旦声明了一个新的runner, 伸缩就是自动化的: 将会挑选出最有效的runner来启动每个新的构建。这很简单,甚至你可以增加自己的机器用于本地构建。

通过改用功能更强的runner,我们已经缩短了构建时间—如果转而使用Jenkins,那将会更难。虽然我们要经常优化测试包的运行时间,但有时你还需要为其投入更多的CPU。

更加容易控制

有了Jenkins,构建工作的配置存储于一个仅限管理员使用的工具。你需要拥有编辑构建配置的权利,如何操作不是很明显的。

使 用GitLab-CI,构建工作由仓库中的.gitlab-ci.yml文件唯一决定。这就使得它编辑起来很简单,你可以获取你工作流程的所有细节:版本 控制、合并请求等等。你不需要请求权限向你的工程增加CI。降低CI入门的门槛对于工程质量和愉快开发是一件美妙的事情。

合并请求测试

GitLab-CI使得它能够简单地编译,并且测试一个合并请求的分支(或者在GitHub俚语的一个“Pull 请求”)。只需要几行代码添加到.gitlab-ci.yml文件,我们运行来测试每个合并请求的推送。

仍然测试——但只需要点击按键并且移动。

我们获得良好的红色或者绿色的状态,非常有用的"构建成功后会自动合并"的按键——并且,在合并之前作为我们测试的分支,更少的构建中断。

准备合并了。

平滑的 UI

GitLab-CI 提供 “管线(Pipelines)”,它对你构建的工作会有一个概览。你构建失败,哪个阶段的发生问题,都可以被快速指出来。当一切都是绿色的,它会让你感到温暖,隐约当中就感到安全。

所有的管线都是绿色的,并已经部署。

总而言之

我们发现总体的体验都是相当积极的。一旦最初的障碍在 Docker 容器中通过,将他集成到 GitLab-CI 就已经很简单了。它给了我们大量积极的信号,新的特性都可以被简洁地集成。

我们的安卓团队也在迁移他们的管线,现在构建集成和产生安卓 APK 都可以在 GitLab-CI 内完成。

进一步参考资料,你可以在官网上发现一篇写得很好的 GitLab-CI 特性概览 和一些 gitlab-ci.yml 文件的例子 。

  1. da shang
    donate-alipay
               donate-weixin weixinpay

发表评论↓↓