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 回答