GitLab CI 英文原文：building-our-web-app-on-gitlab-ci

铁路领域是一个快速变化的环境。为了更快地为你提供最新的改进和修复，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 文件的例子 。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务