铁路领域是一个快速变化的环境。为了更快地为你提供最新的改进和修复，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容器中。这样：
可伸缩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文件，我们运行来测试每个合并请求的推送。 仍然测试但只需要点击按键并且移动。 我们获得良好的红色或者绿色的状态，非常有用的"构建成功后会自动合并"的按键并且，在合并之前作为我们测试的分支，更少的构建中断。 准备合并了。 平滑的 UIGitLab-CI 提供 “管线（Pipelines）”，它对你构建的工作会有一个概览。你构建失败，哪个阶段的发生问题，都可以被快速指出来。当一切都是绿色的，它会让你感到温暖，隐约当中就感到安全。 所有的管线都是绿色的，并已经部署。 总而言之我们发现总体的体验都是相当积极的。一旦最初的障碍在Docker 容器中通过，将他集成到GitLab-CI 就已经很简单了。它给了我们大量积极的信号，新的特性都可以被简洁地集成。 我们的安卓团队也在迁移他们的管线，现在构建集成和产生安卓 APK 都可以在GitLab-CI 内完成。 进一步参考资料，你可以在官网上发现一篇写得很好的GitLab-CI 特性概览和一些gitlab-ci.yml 文件的例子。 ◆◆◆ 本文来自开源中国协作翻译平台，详情请点击阅读原文阅读 本文翻译：昌伟兄，无若，xufuji456 了解详情请点击阅读原文 开源中国｜ID：oschina2013 每天为你送上精选资讯早点 还有每天的 OSChina乱弹哦 本文转载自：微信公众账号 - 开源中国，版权归原作者所有！ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
