…is wrong. Thanks for joining my TED talk.

Continuous integration is such a beautiful tool. Making sure that whatever change you implement does not break the software you’re contributing to. For more complex systems it even ensures you don’t break the interactions of your system with other systems. Usually follows quite the simple principle, starting with pulling the development branch code. Generally, it would be the latest version of the software stable. You create your feature branch from it, implement your changes and run your tests locally and update your code until the tests pass.

Eventually, you check in your code onto your remote and trigger a build to make sure your changes integrate well with the overall software. Once you get your green build, you open a pull-request and eventually get to merge your code into the main branch.

What if for some reason that ignores reason, you may end up working with an unstable continuous integration. It could be that the build or tests are flaky which is not great but could happen. Not much you can do about that at a high level without diving deep within every application constituting the software you’re working on. I would accept that as the sort of pain you may find yourself dealing with in any software organisation.

Now imagine, a world where one merges code before testing it through CI CI builds. Right. Now picture, several teams able to merge against that same branch every few hours. Yeah, now we’re cooking with the sweet spice of pain. And not the way I like. There could be a very good reason things are working this way so let’s say there is nothing you can do about it. Chances are when you create your branch the build broke beforehand. I’m guessing an environment where anyone can break the main development branch, finger-pointing might be a national sport.

Nobody likes fingers pointed at their direction especially knowing their changes aren’t anywhere near the broken tests. How do you protect yourself against that? It’s simple yet tedious. There are two options I can think of.

The first one is to wait for the main development branch to have a clean build again and create your branch from there. Not my favourite as I am not a big fan of waiting in general. Waiting for fixes to coming by monitoring slack and observing build runs is about as fun as watching paint dry. Not a painting, bland wall paint. Nobody wants that.

The other, more proactive option, would be to create a branch from the last working commit of the main branch. Basically, go through your CI, look up the latest commit from the last green build, check it in and create your branch from there. Not so fast though, make sure you can run tests before you do any work on that branch. If no local tests are available then trigger a CI build off your new branch. If it’s green and only then, you can start developing your changes.

It’s not foolproof but it seems like the safest way to develop changes in such an environment. Also, it helps to figure out issues when you actually introduce them. I should stop this post before I start delving on unstable CI builds behaving like Targaryens.

Every time a Targaryen is born, the gods toss a coin in the air and the world holds its breath to see how it will land. Ser Baristan Selmy, ASOIF

Hope you enjoyed the read, here is an example of a simple yet effective CI setup you can do for free. Go and get jiggy with it!

Cover by Kevin Ku from Pexels