It is a very tedious & time consuming task to deploy a website to it's destination trough FTP, not to mention the possibility of human errors due to this cherry picking process.

It all started with: hmmmm....FTP is so 1990

The search

To eliminate the possible errors, and to speed up the process, I went on a search how to automate the deployments of a WordPress website. I found many ways, from Ansible, DeployBot (online deployments, also uses GIT) to the final solution: GIT.
All projects done by the AppSaloon team, are by default in GIT. 

The learning

Starting point: a trail & error situation, figuring out how to setup the server to accept GIT, understand what a bare Git repository is, adding remotes to your local Git repository, learning about Git Hooks and how to use them.
And finally I had a very basic, simple deploy script, able to deploy my code changes to any environment I had setup.

The result

#!/bin/bash
while read oldrev newrev ref
do
 ## shorten branch name
 branch=$(git rev-parse --symbolic --abbrev-ref $ref)
 ##  Record the fact that the push has been received
 echo -e "Branch: \e[96m$branch\e[0m received at \e[1m$( date +%d-%m-%Y )\e[0m."
 echo -e "\e[31mOld: $oldrev\e[0m -- \e[32mNew: $newrev\e[0m"
 echo -e "Start deploying \e[96m$branch\e[0m branch to \e[96m$branch\e[0m @ SQLPerform..."
 GIT_WORK_TREE=/home/sqlperform/apps/staging git checkout -f staging
 echo -e "\e[32mFinished deploy....\e[0m"
done

Improvement over time

Meanwhile, I don't improve the script & process by myself anymore, our whole team is making effort to improve this deployment process, they've even given it a name:
MDP2 (abbreviation for: Mark's deployment process, part 2)

Features on deploy

• Check on what branch needs to be deployed, based on the deployment command from terminal (eg: git push staging staging or git push master master).
• If first deploy, we download & install WordPress (because we keep most of WordPress folder & file out of GIT)
• If code deploy is finished, we move over to composer to download and install or update all needed plugins.
• Remove all files not needed on the server, those files are in GIT, but only needed in development.
• Check if there is a .env file, if not we create one. This process is needed with GDPR nowadays, we moved all our Database logins & passwords out of the default wp-config.
• Visual feedback in terminal for each step (always nice to see whats happening)

*Don't let the title fool you, "semi-automated" is used, because you still need to manually upload an Database export to sync the Database to a staging or production environment.