Automate your deploys with git
Most developers have nowaday migrated to Git from arcane, older legacy systems, and this is for good. There are many different ways to use it, you might follow a Github pull/request workflow, or you might have some different code-review strategy, including using Gerrit.
We use it because we know that there our code is (mostly) safe.
But we are just scratching the surface, here, because Git can be used to keep track of deployments as well, and be a consistent part of a deployment pipeline. That is true whether you want to deploy to a test server, or to production.
A tool that many of us has been using for this purpose i Jenkins, and I understand that in complex enterprise scenario it is needed to give structure and gather components from many actors. But there are scenarios where we could do without, and just use Git.
I will try to define such a solution, it’s up to you if you have good contexts for that, I definitely have a couple.
What we want
We are developing a project that contains a long running process, a ‘server’. A server can be started and stopped. Normally, we will need to implement a script for that, let’s say we have:
myproject/service.sh start # Starts the service myproject/service.sh stop # Stops the service
and let’s venture out saying it is also some bulky Java project built with Maven, but it does not make any difference if it’s something else, as long as you have a single command that is able to build it. You get the point: you want to add a stupid extra line to your code, but the resulting build is huge, and you don’t want to wait on the line for a huge binary to be transfered, unpacked and deployed.
You don’t have to. You just need to define a remote branch on the destination machine that you will use to tag and deploy what you want to.
To add such a remote, you can use this script: setup-deploy If you just go in the root of your project and somehow run the script before:
The first time you run it, will create a sample config:
that we will likely edit to be like that:
GIT_HOST=dev.kevwe.se GIT_USER=jim GIT_BACKUP_PATH=/home/jim/projects/myproject/repo
That means that, whenever we do:
(or any alias you prefer to set for that) it will try to push the changes via ssh
in the remote directory:
The path is tought in a way so that you can have muplitple projects deployed in the same user account, if you want.
That’s it for the client side, the developer machine.
What the script itself does is setting up a post-receive hook that, every time you push to deploy (alias: git pub) will tag the commit, run a build command that you define in: post-receive.m4
and then just try to run your project with:
You might need some adjustment, but I think having:
- A build command
- A start shell function
- A stop shell function
should be general enough for a couple of projects. And in fact, I’ve been using this pattern with some success, and I ended up saving a lot of time with this.
My deploy scripts
Blacklist check (beta)
If you own a mailserver or have been following the indications to setup one If you care about your mail server not hitting any blacklist, you might value this new service that I set up:
Any feedback is welcome.