7

我一直在思考如何使用 GitLab CI 实现持续交付?

我为 CD 阅读的每个解决方案都依赖于多步管道(例如 Jenkins),或者是侦听 webhook 并提供自己的部署接口的自定义应用程序(例如,GitHub 的 HuBot + Heaven + Janky)。

如果我们只关心在 Master 分支上执行 CD,并且我们的测试套件/部署步骤非常快,您可以简单地将其包含在 GitLab CI 运行的 shell 脚本中......但是,如果您的测试套件不快?或者您的部署可能需要几分钟来下载软件包等?然后你的 CI Runner 正忙着做一些事情。

我能想出的最佳解决方案是:

  1. 创建一个接受来自 GitLab 和 GitLab CI 的 Web Hooks 的 Web 应用程序,并跟踪所做的每个单独的提交和构建状态。
  2. 启动自己的自定义运行程序,尝试为收到的每个通过的 webhook 执行交付到暂存站点。应用程序可以使用,例如,fabistrano,以便于部署/回滚。
  3. 收听合并请求以合并到通过所有测试的 GitLab 中被接受的 master。

有什么想法吗?有人用 GitLab CI 实现过 CD 吗?

4

1 回答 1

3

我会从 gitlab CI 开发一个 webhook 的监听器,并且只为跟踪的分支处理成功的构建,然后需要检出和交付。特别是,我认为不需要处理来自 gitlab 的 webhook 和协调,来自 gitlab CI 的信息似乎足够了(它包含构建状态、参考分支和提交 ID)。

根据您的存储库布局,您可以通过以下方式下载存档

gitlab.example.net/namespace/repository/archive.zip?ref=gitash

或签出相关的提交并调用您的 CD 脚本。

如果您想整合您的 CD 脚本的反馈(部署是否有效),您可以从运行器中调用所有这些。请记住,如果您的设置时间过长,您可以拥有多个跑步者。

于 2014-08-11T08:47:44.593 回答