Branching workflow: git-flow and github-flow

Choosing a branching model for macchiato

Lately, I’ve been working on Macchiato to bring web application development libraries for ClojureScript on Node.js. Get a few people of different backgrounds involved on a project, and pretty soon a discussion about methodology will emerge.

Since both Dmitri Sotnikov and myself are working on some libraries at the same time, we had to decide which approach to use.

There are two major alternatives: Git-flow and Github-flow (with Gitlab-flow being a slightly more elaborate version).

Let’s review them.

Deploying a Clojure application from Gitlab CI to Heroku

Now that we have our Clojure application tested every time we push it to Gitlab, let’s configure another stage to deploy it to Heroku.

This assumes that:

• Anything you merge to master is ready to deploy,
• You have your Heroku API key handy, and
• You already have a Heroku app configured, with all the necessary environment variables.

There’s two ways we can do this.

Using Gitlab CI with a Clojure project

Gitlab allows you not only to have free private repositories, but also to test them using free runners. These can run automatically, on push, for any branch or tag.

I keep a few private repositories with them, for personal projects and small experiments. I decided to give Gitlab CI a shot for a PostgreSQL-backed Clojure project.

There’s a basic example on the Gitlab CI repository. It gets and installs lein, which isn’t necessary. Instead, we’ll build use the clojure:lein Docker image.