August 12, 2020 - 3 min read
I was in search of a simple way to deploy a straightforward Shopware 6 webshop to our production server. We’ve been building Magento shops since 2011 and in recent years we’ve deployed both Magento 1 and Magento 2 shops using Deployer.
It turns out, there already was a Shopware 6 Deployer recipe, however this turned out to be incomplete/not working 100% correctly. Fabian Blechschmidt and me have done some changes to make it more complete. We’re using Gitlab CI/CD to run the deployment once a merge request to master has been merged.
Update 29-08-2020: Make sure you use the
shopware/productiontemplate for your project. See this blogpost about the difference between
shopware/development. See this blogpost to learn how to switch from the development to the production template, if needed.
First, you’ll need to require Deployer:
composer require deployer/deployer --dev
The Shopware 6 recipe is in the master branch (no tagged release yet), but the Deployer master branch requires
symfony/console version 5 and up, while Shopware requires version 4.4.4 as of writing. So these conflict, which means we can’t use the master branch at this moment. So we’ll need to copy the recipe into our project;
wget -O deployer-shopware6.php https://raw.githubusercontent.com/deployphp/deployer/master/recipe/shopware6.php
Now create your
deploy.php and update as needed;
<?php namespace Deployer; require 'vendor/deployer/deployer/recipe/common.php'; require 'deployer-shopware6.php'; // Project name set('application', 'webshopnamehere'); // Project repository set('repository', 'email@example.com:webshopnamehere/shopware.git'); // Hosts host('yourproductionserver.hypernode.io') ->user('app') ->forwardAgent(true) ->multiplexing(true) ->addSshOption('UserKnownHostsFile', '/dev/null') ->addSshOption('StrictHostKeyChecking', 'no') ->set('deploy_path', '~');
You can test whether this works locally by running
vendor/bin/dep deploy -vvv. The
-vvv flag will make sure you’ll see any errors in your console.
If you’re using Gitlab, you can move on to letting Gitlab CI/CD do the heavy lifting for you on your Gitlab runners instead of having to manually trigger the deployment locally.
This is my
.gitlab-ci.yml file where I’ve only created a deployment step for now;
stages: - deploy cache: key: "changethiskeytosomethingunique" paths: - .composer - .npm deploy: image: docker.hypernode.com/byteinternet/hypernode-buster-docker-php74-mysql57 before_script: - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )' - eval $(ssh-agent -s) - ssh-add <(echo "$SSH_PRIVATE_KEY") - mkdir -p ~/.ssh - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config' stage: deploy only: - master script: - composer install --verbose --prefer-dist --no-progress --no-interaction - vendor/bin/dep deploy -vvv
Note that we’re using the
docker.hypernode.com/byteinternet/hypernode-buster-docker-php74-mysql57 Docker image, but you can use any image as long as it has the PHP version you’re running the shop on.
Also add the SSH private key you’re using to deploy to production with to your Gitlab CI/CD variables with the name
Triggering a pipeline on the master branch will now deploy your site to your production server. Of course, this is a very simple setup. In a more likely scenario you’ll want to build the admin and the storefront on the runner and scp/rsync the artifacts over to the production server instead of pulling the Git repo in and doing the building/composer install on the production server.
Written by Peter Jaap Blaakmeer @PeterJaap