Automate your deploys with Git

Automate your deploys with Git
vpn openvpn security iot iiot tech

Automate your deploys with git

Some context

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/ start # Starts the service
myproject/ 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:

That means that, whenever we do:

git pub

(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.

On the server side, you clearly need either a kind admin to setup a receiver for you or… the following script: setup-deploy-server and the related configuration

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:

yourproject/script/ start

You might need some adjustment, but I think having:

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:

Email Blacklist Check

Any feedback is welcome.

comments powered by Disqus