我们大部分程序员都是只想安安静静的写代码，但是总是绕不过去的一个问题就是打包和发布。

我们团队的流程是这样子的

  • vs编写代码
  • gitlab merge request
  • 审核合并
  • jenkins打包发布

然而我们还是会常常遇到一些问题，比如打包不过呀，低级bug呀等等各种问题

然后revert，hotfix

那么问题来了，我们程序员有限的生命这么宝贵，为什么要浪费在这些问题上。

CI

ci持续集成，参加持续集成 - 维基百科，自由的百科全书

其实我们这边有做持续集成，比如定期build，定期converity

但是我们可以做的更多一些

Jenkins+Gitlab

实操一下jenkins+gitlab做ci

  1. 我们在jenkins上建立一个工程，这个工程可以做build或者test或者publish

    1535340744971

  2. 添加源码管理，对我们项目来说是gitlab

    1535341430819

  3. 设置触发器，这个是最有用的地方，可以决定我们在什么时机去运行这个jenkins工程

    1535342903000

    • merge request触发

      1535343239580

    • webhook触发

      这个是一个比较简单的方式，可以实现对gitlab本身触发器的集成。

      这里我们选择push events

      1535343990039

      回到gitlab项目，在settings-intergrations

      将刚刚jenkins中的webhook的URL粘贴过来，然后选择触发事件。例如我期望每次添加一个tag的时候跑一边发布，那么就勾选Tag push events

      1535344215615

      创建的webhook会在下面列出了，我们可以点击右侧的test发送一个测试的Tag push events

      1535344427821

      我们可以看到jenkins跑了一次构建，里面还显示了相应的信息

      1535344574967

What can we do

  • merge request自动跑单元测试
  • 合并后跑build
  • 添加tag后发布
  • ……

限制的只是想象力

本文会经常更新，请阅读原文： https://xinyuehtx.github.io/post/%E4%BD%BF%E7%94%A8jenkins+gitlab%E8%BF%9B%E8%A1%8CCI.html ，以避免陈旧错误知识的误导，同时有更好的阅读体验。

知识共享许可协议 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布，但务必保留文章署名黄腾霄（包含链接： https://xinyuehtx.github.io ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请 与我联系 。

相关文章