Using Gitlab CI for deployments

gitlab

Hi there folks!

This time we are going to talk about something different: using Gitlab and its CI system for deployments.

Gitlab CE (community edition) is an Open Source git platform that can be used to host your git repositories on a server. It offers most of the features offered by Github, with the advantage that you can host it on your own server.

In my previous organization we were using Github for hosting our git repos and using git along with git hooks for deployment on the server (tutorial). Now with a bigger team we needed a pull request and merge based approach and deployment for the same. After evaluating the options available, my thoughts are as follows:

1. Custom Hooks

These are basically git’s server side hooks and only run when someone pushes to the repo.

Pros
  • Easy to setup, supported by git, and documented.
Cons
  • Not executed run on merges.
  • Difficult to redeploy.
2. Webhooks

These allow hitting a URL for certain actions / events like push, merge, etc.

Pros
  • Easy to understand.
  • Triggered on both pushes and merges.
Cons
  • Need to setup a custom webhook handler for it on the deployment server.
  • Since Gitlab’s webhook system does allow to store any state (like whether the deployment succeeded, or is in progress), this information needs to be stored by the webhook handler as well (by comparison I find Github’s webhook system much better in this regard).
3. Gitlab CI

This is Gitlab’s CI (Continuous Integration) and CD (Continuous Deployment) system.

Pros
  • Quite featureful and customizable.
  • Runs on both pushes and merges.
  • Can be used to track deployment status and redeploy if needed.
Cons
  • Higher learning curve.

As can be seen, the CI system seems like the more appropriate choice as per the requirements. Only thing now is to set it up.

 

Setting up the Gitlab Runner

Gitlab Runner is what we will be installing on the deployment server. Installation looks simple but there is a question: which executor to use? Since we are deploying on the same server as the runner (and not doing anything else that needs a clean environment), we will be choosing theĀ shell executor.

Whenever there is a commit in the Gitlab repo, the runner gets notified, places us in a checkout of the commit, and runs through what is specified in .gitlab-ci.yml (for example I wrote a bash script to transfer the changed files using rsync to a location in the docroot of the webserver).

And that’s it! Let me know in the comments if there are any questions.

Leave a Reply

Your email address will not be published. Required fields are marked *