It’s the middle of 2015, and we have tools to automate and alleviate manual labour in almost every conceiveable avenue of our industry. So why do we still use FTP to manually upload our content?
Today we are taking a look at setting up a pretty solid deployment strategy that should work effectively for just about any type of hosted project. As far as deployment solution, it’s as basic as it get’s, but sometimes basic is all you need right?
The strategy below is fairly simple, but it does assume a few things:
- You are fairly used to working with git.
- You have SSH access to your server, and can switch to your www-data user.
- I talk about Github here, but this works with any git type repository host. I have used this with with Bitbucket and self-hosted Gitlab instances.
- This isn’t a tutorial, but rather a description of what I’m doing.
The idea is that we want to automatically deploy our site to our server when we commit some code into our repository. Basically, we commit something to Github, Github tells my server that there is something new for the website available, and the server does a
git pull and that’s the end of that - you have a lovely new feature on your site.
In terms of the theory this is as simple as it get’s. In practise it’s as simple, with a just one or two tricky hurdles standing in the way. Below is a quick breakdown of what our git based deployment will work off:
- Making a production branch for git - I normally just use the master branch.
- Writing a small PHP script that does a
git pullon the chosen branch.
- Setting up the correct user permissions for your server.
- Telling Github to run the PHP script when code is pushed to the master branch.
1: Branching off
Let’s get our foundations built first. In an ideal world we only want our server to pull from the repository when the feature we are building is complete, and ready to go live. On top of that, we might also want to check out our new feature on a staging server first.
To get this going we will be using git branches (something all of us should learn to love). By default any git repo runs on the
master branch. This is awesome, and we will make that our production branch - the branch that will hold our code that is signed off and ready to go live.
I like to have a few official branches in any given repo that I work on. Generally my branch structures look like this:
master- The production version of code.
develop- Stable development version of my code. Should always be ready to merge into master and have no major blockages.
featue/NAME- Small / Single features of something.
We will set up our deployment script to ONLY look at the master branch of our repo. This means that you will develop in a different branch, and only merge into master when you are confident that your work is ready to go live.
The approach I have here is the easy as peas PHP version. We simply tell our PHP script to execute a command - in our case
git pull origin master. That is really all there is to it.
You can also upload a small bash script - that you can call up with the above PHP script. This method is really only usefull if you need to run a few commands on your server when you deploy. An example is my own site: I run a
git pull &
jekyll build, so I use bash script rather. The plain PHP version serves me well for 90% of my other projects however!
3: Set up SSH Keys
Most of the servers I have worked on in the past had
www-data as the web user. This is the user that performs all of the actions passed through your http calls.
Think of it this way: On your own computer you are logged in with your own user account. When you connect to Github, it’s done through that user. When you set up SSH keys with Github you authenticate with this user.
On the server it’s an identical process, except you need to follow the steps as
www-data (or your own server’s equivalent).
4: Link it all up
The last bit is simply editing your github repo, and adding a POST hook with the url of your php script. That’s it. Done.
You can find the settings here: https://github.com/USERNAME/REPO-NAME/settings/hooks/new
The strategy I described above is a very basic one, but it should give a fairly good outline of how it would be possible to go on beyond just the basics.
For my own site I have a slightly extended strategy that also builds my Jekyll site on the server, and I am already planning to add some more beef & security to it all.