Deployment Hook

[shyim]

Current projects execute a lot of commands when deploying Shopware. Shopware-cli should abstract it and make it easy as possible:

Build Hook

This is kinda of our shopware-cli project ci command.

New to this step, we generate a deployment-manifest

This deployment manifest contains some meta information we might need in the deploy hook like:

• Changes files (so we can skip steps, like updating plugins, compiling theme)

Before Hook

• Uninstall plugins, which will be removed in next deploy?
  • We can't uninstall a Plugin when the source code is missing

Deploy Hook

Tasks:

• Install or Update Shopware
• Install, Update, or Activate Plugins
• Compile the Storefront Theme if needed
• Copy assets if an external storage is used

We should allow to run custom commands to do custom stuff.

• Maybe just allow running bash scripts or inline in our config?
• Or we use something like starlark to add fancy wrapper

[Schrank]

I love the idea - although I would prefer to implement it in deployer 🙈 But overall this is awesome! And the "uninstall a plugin before removing it" is a problem we just encountered. Thankfully only once.

[shyim]

That is the exact reason why it should not be implemented into the deployer. Deployer is one "the tools". We don't want to implement this specific for each tools, the tools should use this :)

[vanWittlaer]

I love the idea too, though it sounds a real challenge to me. Deployment is a complex process.

When I look at my procedures for different projects at different hosters (cloud, traditional hosters like Profihost, maxcluster ...) I'd say some 2/3rd to 3/4th of the task is server technology related (like setting ownership and permissions, make switched symlinks work etc.), so Shopware related stuff is just the minor part (no real challenge by itsefl, though a some more documentation would not be wasted :smile:)

For the server related stuff, I still believe bash is the most efficient and shortest way to go. My gitlab or bitbucket script for the runner part is typically just a handfull of lines. The bash script for the target server business on the other hand typically around 70 lines. (I never understood how deployer is of use here - just adds complexity in my mind.) The server specific requirements are just so diverse (starting with the question under which user the deployment runs, and is a root, or just sudo, identical with webserver user or not ...)

But what I really miss, is some kind of "version management" for those things in a deploy, like the uninstall/install of plugins, that need only to be done in connection with a specific commit. So something that would allow to track what was changed in the system (plugin install/uninstall, config settings) over time/commit history. (For example, if, with one commit I'd install a new plugin, I would have to put the install for this plugin within my deployment script, and then take it out again with the next commit - whichever that is. This is clumsy and difficult to track.)

Ideally, my deployment script should look for some instructions similiar to a db migration, and just apply it once. I guess this it what you have in mind with the pre and post deploy hooks? But it must have this "only once" functionality. So in essence, this would just be a kind of - let me call it that - "cli installation migration" command.

[jochenmanz]

i would prefere a version that is independent to deployer or other similar tools, too. We are facing the challenge that new customers often need tailored solutions for their deployments. So something that only depends on shopware-cli is a good thing :)

Things our deployment does with own commands using bin/console

• Composer Install
• Build administration and storefront
• Run DB Migrations (shopware itself)
• Plugin Refresh, Plugin Updates (with some jq magic to only update when version changes)
  • Plugins are managed only via composer, removing them is only done through composer
• Restart messengers
• compile themes
• cache clears

All deployments happen with some sort of release directory and switch the htdocs symlink if all above steps are successfull. So we don't really need a check if some files are changed and only then compile the theme - the cache folders inside the release folder and not shared, so it will always be necessary to compile the js, css and themes up till now.

[JoshuaBehrens]

I assume make, bash and gnu-text (grep, awk, ...) are sufficient. I do not see a reason to install yet another deployment support tool.

[shyim]

I am with you @JoshuaBehrens , but bash and UNIX tools aren't really portable. There is bsd/musl/glibc variants of grep, awk which makes portable bash scripts kinda impossible

[JoshuaBehrens]

I do have issues between MacOS and debian binaries. I cannot/will not deny it :D but I am hardly on any other environment and thus I would not use shopware-cli for that. I fear, that eventually I would have to do pull requests in Go to change e.g. order of scripts executed because it just wont fit my project. To use the fix I need to wait for a binary, that needs to be built and shared. And for that there are already scripting solutions, that are more flexible (bash / php).

[shyim]

What would you guys think about having a additional composer package shopware/maintenance or something like that. Which brings a new vendor/bin/shopware-maintaince command line with abstracts the command execution and allows to configure further things with a .shopware-project.yaml

[JoshuaBehrens]

This would improve a way to get the binary. Right now I have this in my makefiles:

UNAME := $(shell sh -c 'uname -s 2>/dev/null || echo not')
ifeq ($(UNAME),Linux)
    SHOPWARE_CLI_ARCHIVE := https://github.com/FriendsOfShopware/shopware-cli/releases/download/0.4.29/shopware-cli_Linux_x86_64.tar.gz
endif
ifeq ($(UNAME),Darwin)
    SHOPWARE_CLI_ARCHIVE := https://github.com/FriendsOfShopware/shopware-cli/releases/download/0.4.29/shopware-cli_Darwin_arm64.tar.gz
endif
SHOPWARE_CLI_FILE := dev-ops/bin/shopware-cli

.PHONY: clean
clean: ## Cleans up all ignored files and directories
    [[ ! -f $(SHOPWARE_CLI_FILE) ]] || rm -f $(SHOPWARE_CLI_FILE)

.PHONY: build-assets
build-assets: $(SHOPWARE_CLI_FILE) ## Builds assets
    $(SHOPWARE_CLI_FILE) extension build .

$(SHOPWARE_CLI_FILE): ## Install shopware-cli executable
    $(CURL) -L $(SHOPWARE_CLI_ARCHIVE) -o $(SHOPWARE_CLI_FILE).tar.gz
    cd $(dir $(SHOPWARE_CLI_FILE)) && $(TAR) -xvzf $(notdir $(SHOPWARE_CLI_FILE)).tar.gz shopware-cli
    rm $(SHOPWARE_CLI_FILE).tar.gz

[shyim]

This will be solved in https://github.com/shopwareLabs/deployment-helper