3

我正在将持续集成实现到我的 Laravel 工作流程中，在完成基本操作时，我在 Gitlab 上遇到了一个示例项目，其中 (1.) Laravel Envoys 用于编写与应用程序应如何部署相关的任务，然后 (2.)使用 Gitlab CI 引导流程。

我有点困惑，在我看来，使用 Enovy 定义任务的部分（下面）在.gitlab-ci.yml文件中定义作业时很容易复制，这使得 Envoy 的使用变得多余：

 ...

    @setup
        $repository = 'git@gitlab.example.com:<USERNAME>/laravel-sample.git';
        $releases_dir = '/var/www/app/releases';
        $app_dir = '/var/www/app';
        $release = date('YmdHis');
        $new_release_dir = $releases_dir .'/'. $release;
    @endsetup

    ...

    @task('update_symlinks')
        echo "Linking storage directory"
        rm -rf {{ $new_release_dir }}/storage
        ln -nfs {{ $app_dir }}/storage {{ $new_release_dir }}/storage

        echo 'Linking .env file'
        ln -nfs {{ $app_dir }}/.env {{ $new_release_dir }}/.env

        echo 'Linking current release'
        ln -nfs {{ $new_release_dir }} {{ $app_dir }}/current
    @endtask

   ...

如果我错了，如果有人能纠正我，或者解释 Envoy 可以为 Gitlab 持续集成工作流程带来什么好处，我将不胜感激。

4

1 回答 1

5

您是正确的，示例 shell 脚本可以在.gitlab-ci.yml文件或Envoy.blade.php文件中轻松实现（所以“不”，Laravel 应用程序的 gitlab-ci 部署不需要 Envoy。）我看到用户可能选择的三个主要原因通过 gitlab 在 Envoy 中执行部署任务：

熟悉度

Laravel 开发人员可能更熟悉 Envoy 用于部署的语言（PHP 和 Blade 语法），而不是 gitlab 使用的语言（使用 gitlab 管道语法的 Yaml 格式）。

保持不太熟悉的.gitlab-ci.yml文件简单并将大部分复杂性添加到更熟悉的 Envoy 文件中可以节省开发人员的时间。

可移植性

一些开发人员可能想要在 CI 平台之间切换的选项。通过保持 gitlab-ci 文件简单并在 Envoy 文件中包含大量部署逻辑，开发人员可以切换到另一个 CI 服务器，例如 Jenkins，而无需重写部署代码。（或者，就像我看到的那样，开发人员可能同时使用 gitlab-ci 和 Jenkins 来构建他们的软件。使用 Envoy 意味着两个 CI 平台之间有更多的共享代码。）

现有堆栈

Envoy Task Runner 使用 Laravel 部署（PHP 和 Composer）已经需要的软件。另一方面，Gitlab 需要在机器上安装 gitlab-runner 才能进行部署。

于 2017-10-29T08:35:50.143 回答