Continuous Delivery with GitLab CI

Question

I've been trying to wrap my head around how it would be possible to implement Continuous Delivery with GitLab CI?

Every solution I read for CD relies on multi-step pipelines (such as Jenkins), or a custom application that listens to webhooks and provides its own interface for deployment (For example, GitHub's HuBot + Heaven + Janky).

If we only care about performing CD on the Master branch, and our test suite/deployment steps are very fast, you can simply include it as part of the shell script that gets ran by GitLab CI.... However, what if your test suite isn't fast? Or your deployment can take a few minutes to download packages, etc.? Then your CI Runner is busy working on stuff.

The best solution I can come up with is:

1. Create a Web Application that accepts Web Hooks from GitLab and GitLab CI, and keeps track of each individual commit that was made and the build status.
2. Launch own custom runners that attempt to perform delivery to a staging site for each passed webhook received. Application can use, for example, fabistrano, for easy deployment/rollback.
3. Listen for Merge Requests for merging into master being accepted in GitLab that passed all tests.

Any thoughts? Has anyone implemented CD with GitLab CI?

Perceptual

Answer 1

I would develop a listener to the webhooks from gitlab CI and only process successful builds for the tracked branch that then needs to be checkout and delivered. In particular, I don't see a need for processing webhooks from gitlab and the corrdination, the information from gitlab CI seems sufficient (it contains the build status, the reference branch and the commit id).

Depending on your repositoy layout, you could then just download the archive via

gitlab.example.net/namespace/repository/archive.zip?ref=githash

or checkout the relevant commit and call your CD script.

If you want to integrate the feedback of your CD script (whether the deployment worked) , you can call all that from the runner. Keep in mind that you can have multiple runners, if your setup takes too long.

Embryo

How would you handle retrying successful builds? Currently GitLab will fire off an event to its webhooks every time a build is successful. This means if your commit abc0123 was built a year ago, and released into production, someone can manually rebuild it and trigger the webhook. You'd need to keep track of which commit hashes you already received success hooks from. Wouldn't you? – Perceptual

You could alternatively forbid deploying an "older" commit id. This would require a no-rollback but revert-broken-commits policy. Depending on your application and if you do automatic database updates, this might make sense or not. – Embryo