The first time I witnessed the cleverness of the deployment using git strategy was with GitHub Pages: simply
git push to the master branch of your repository and your static web page is updated. As simple as that.
I wanted to be able to deploy with the same elegance on my own servers and for more complex applications. I thought I understood how it worked but not how to automate it. So I would manually
ssh into the server,
cd my way into the project folder, then
git pull. Every. time. Not really convenient.
When I discovered Trellis I learned to use ansible to be able to deploy by using a oneliner:
./deploy.sh production domain.com)...
But then Ansible is a power tool, which does a lot of other things than just deploy. And I learned the hard way that I should not update my local Ansible version otherwise... All hell break loose.
Also, I would still have to
git push to the remote prior to launching the deployment.
Working at BeCode is cool because you get to meet dozen of fellow developers, craving to learn and explore. One of our learners pointed me in the direction of using a GitHub Post-Receive hook, thanks to which deployment is a simple :
git push production master. The hook launches a local script that
git checkout the master branch on the production server, then runs any other custom operations you want (such as
composer update for example).
Let's see how to set it up.
First, create a "bare" repository – one that does not contain the working copy files. It basically is the content of the .git repository folder in a normal working copy. Name it whatever you like (you could also omit the .git part from project.git but I find it best to keep it):
cd /path/to/project/folder/ mkdir project-name.git cd project-name.git git init --bare
Create a post-receive hook at
Fill it with your version of the following code (use your specific folder paths) :
#!/bin/sh NOW=$(date +'%d-%m-%Y_%T') # check out master branch GIT_WORK_TREE=/path/to/destination/folder/htdocs git checkout -f master # custom steps for deployment # For example, let's execute composer to refresh our dependencies : cd /path/to/destination/folder/htdocs composer update # backup current version, in case we need to do a rollback cp -R /path/to/destination/folder/htdocs/. /backups/project-name/$NOW/
Make sure it is executable:
chmod +x post-receive
Let's now add a reference to this bare repository to our local system, as a remote location. Let's call this remote "production". (It could also be called "staging" or "live" or "test"... should you want to deploy to a different system or to multiple systems.)
cd ~/path/to/working-copy/ $ git remote add production ssh://firstname.lastname@example.org:22/path/to/project/folder/project-name.git
Check that your new remote is now available, and all the existing ones:
git remote -v
You can now deploy using this beautiful one liner :
git push production master
With this, I have the raw basis of a deployment pipeline. The next step would be to add code testing to make sure code updates do not introduce bugs or break anything (regression testing). I assume I should look at how to use Ansible for that.
Since I don't know how to do that yet, I'll leave you to
Posted on by: