通过持续交付通过GitLabCI部署Laravel应用程序时是否需要LaravelEnvoy？

我正在将持续集成实现到我的Laravel工作流程中，并且在基本学习过程中，我在Gitlab上遇到了一个示例项目，其中（1.）Laravel Envoys用于编写与应用程序的部署方式有关的任务，然后与（2.）使用Gitlab CI引导过程。

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

 ...

    @setup
        $repository = 'git@gitlab.example.com:/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 Continuous Integration工作流程带来的好处，我将不胜感激。

您是正确的，示例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才能进行部署。