Shopware 6 - Simple deployments with Deployer

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/production template for your project. See this blogpost about the difference between shopware/production and 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', 'git@gitlab.elgentos.nl: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 SSH_PRIVATE_KEY.

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