I am implementing Continuous Integration into my Laravel workflow, and while going through the basic I came across a sample project on Gitlab where (1.) Laravel Envoys was used to write tasks related to how the app should be deployed and then (2.) bootstrapping the process using Gitlab CI.
I got a bit confused, it seems to me that the part (bellow) where you define the tasks using Enovy is easily replicable when defining jobs inside the .gitlab-ci.yml file, which makes the use of Envoy redundant:
...
@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
...
I would be grateful if someone could correct me if I'm wrong, or explain what benefits Envoy could bring into the Gitlab Continuous Integration workflow.
You are correct that the example shell script could be easily implemented in either a .gitlab-ci.yml file or an Envoy.blade.php file (so 'no', Envoy is not necessary for gitlab-ci deployments of Laravel apps.) I see three main reasons why a user might choose to have their deployment tasks in Envoy over gitlab:
Laravel developers are likely to have more familiarity with the languages that Envoy uses for deployment (PHP and the Blade syntax) than they are with the languages that gitlab uses (Yaml formatting with gitlab's pipeline syntax.)
Keeping the less familiar .gitlab-ci.yml file simple and adding the bulk of the complexity to the more familiar Envoy file may save the developer time.
Some developers may want the option to switch between CI platforms. By keeping the gitlab-ci file simple and having the bulk of the deployment logic in the Envoy file, the developer could switch to another CI server, like Jenkins, without needing to rewrite the deployment code. (Or, as in a case that I've seen, the developer may be using both gitlab-ci and Jenkins to build their software. Using Envoy would mean more shared code between the two CI platforms.)
Envoy Task Runner uses software that is already required for Laravel deployment (PHP and Composer.) Gitlab, on the other hand, requires the installation of gitlab-runner on a machine in order to deploy.