Deploying and maintaining a website using git

I’ve kind of used git to deploy/ manage php/ static websites for a while now, but in a very luddite way – basically sshing into the webserver, cloning a repo into my site root directory, then hiding the .git folder in the Apache config.

After recently starting a new job and inheriting some web sites and web apps and starting to take the whole “devops” thing more seriously, I was pleased to see a better technique in place than the one i’ve been using.

The basic premise is this – a repo is set up on the web server as a remote outside of the web root, but configured so that the checkout working directory is another directory. The advantage of this is that there is no need to ssh into the webserver to update the code, as a post-update hook can be used to checkout the updated files.

In addition to this, we usually use tools such as gulp to process scss and minify and js, so the post-update hook can also be used to process these on the server after checkout.

Going into more detail, here is the config of the remote git repo on the webserver, this could be somewhere like /var/sites/mysite_git

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
worktree = /var/sites/mysite
[receive]
denycurrentbranch = ignore

and in hooks/post-update on the remote, something like:-

git checkout -f
cd /var/sites/mysite
gulp build

Using Vagrant for local LAMP development

I’ve always used a local version of Apache for php dev, either the version provided with OSX, or using something like XAMPP or MAMP. On a recent freelance contract I was introduced to using Vagrant to spin up a tailored virtual machine with specific versions of php, mysql and any other relevant dependencies.

Vagrant will download a base virtual machine, and then run a provisioning script to install dependencies. Vagrant also sets up file sharing from your host machine, and port forwarding so you edit locally in your normal editor, and view locally via a web browser as if you were running a local apache instance.

The advantage of this is that once you are up and running, the Vagrant configuration can be stored in the GIT repo, so that other developers can quickly start developing using exactly the same dev environment.

A typical Vagrantfile looks like this:-

Vagrant.configure(2) do |config|
config.vm.box = "hashicorp/precise32"
# Mentioning the SSH Username/Password:
config.ssh.username = "vagrant"
config.ssh.password = "vagrant"
# Begin Configuring
config.vm.define "lamp" do|lamp|
lamp.vm.hostname = "lamp" # Setting up hostname
lamp.vm.network "private_network", ip: "192.168.205.10" # Setting up machine's IP Address
lamp.vm.synced_folder "siteroot", "/var/www", owner: "root", group: "root"
#lamp.vm.provision :shell, path: "provision.sh" # Provisioning with script.sh
end
# End Configuring
config.vm.network "forwarded_port", guest: 80, host: 8080, auto_correct: true
end

Running “vagrant up” in a directory with this file would spin up an ubuntu VM, serving files from the “siteroot” directory. It would also attempt to run provision.sh on the VM, which can be used to install php/mysql etc.

The getting started guide on the Vagrant site is the best way to get up and running if your are interested.