Using Git Feature Branches in MoPyX

Using Git Feature Branches in MoPyX

In GermaniumHQ we use git branches and tags for everything. From research, to development, to test, to the actual release. Why? Let me show you how this worked in case of MoPyX - the Python Reactive UI API.

Our Jenkins based build system is configured in such a way that every feature branch, will be built and tested. This includes linting - these are code style checks, to ensure that the code looks the across the whole code base, static checks, unit, and integration tests.

This happens for every push.

In case of problems, Felix delivers the notifications on the desktop in case something goes wrong.

When building MoPyX, due to its complex nature caused by the hard problem to solve - what UI parts should be changed, when some model parts change, some branches were created for research only, because the outcome was uncertain.

Even now there are 2 fully functional branches that were not merged into master:

feature/raise-in-render-does-not-affect-other-renderers

This one answered a simple question. What should happen if a renderer - that is a function that updates a part of the UI when the model changes fails with an exception.

Should the other renderers continue?

At the time it seemed a good idea. Turns out it’s not.

Why? Because we need to do something with the error. One option would be to log it. But since most graphical UIs don’t come with a console enabled, logging it to the terminal is not really an option. We would need to have a logging feature, that adds an unnecessary dependency.

Furthermore, what happens with the renderer? Should we unregister it? It’s still bound to some actual part of the UI. What happens if it still fails?, etc.

Only after seeing the implementation details it became clear that the best way to deal with that is to simply let the errors propagate, or try/except them directly the renderer.

Now imagine we would have developed this on master only. Deciding we don’t actually need it would only mean we would have to do a bunch of reverts to remove this.

This is just nonsensical pollution of the git history.

feature/reentrant-locks

Same with the reentrant locks. When running it, due to some threading issues, it seemed a good idea to have MoPyX enforce that only one renderer can render at a time.

Guess what? Bad idea.

The problem is we still can’t enforce on what thread the rendering will happen. And since UIs require a specific thread to do the UI updates, that also meant that the whole locking was in the end bogus. Yes it guarantees that only one renderer does rendering, but it’s still on the wrong thread.

With git branches we got the ability to shelve it, and also understand why the threading problem happened.

Conclusions

Branches help us isolate a problem, a feature, or some research, and work it out independently from the rest of the project. Combined with a CI system (git server + Jenkins + Felix) can yield much faster development times.

Finally here’s a screenshot from Felix, as I’m writing this:

Yes, Felix displays now its own version in the title bar.

Yes, that was build on a feature branch.

Yet, that is the feature branch actual name. :D

Happy branching!

Article Photo taken from Pexels: https://www.pexels.com/photo/selective-focus-photography-of-green-leaves-1122158/