Development workflow for Leaf Node Monitoring

You might be wondering how I keep track of the development of Leaf Node Monitoring. This short post goes into detail regarding how I keep track of ideas, new features and bugs and how the code is automatically tested and built for the various platforms.


Since it is a project I can only work on in my spare time, it is not updated as rapidly as you might expect, an evening a week here and there.

It is also my pet project so I want new features to be useful, work great and look okay, which means I can nitpick on a layout for a month and then decide I don’t like it and start over.

The development is done in C++ with Qt, both Qt5 and Qt6 are supported but I target Qt5 with Windows 7 as minimum platform for compatibility with older but perfectly fine hardware. The Qt6 port is mostly there to make sure the code compiles if I ever wanted to switch.


Bug tracking & new features

Keeping track of all the ideas I have is done with Gitea. I have a self-hosted instance running locally and that hypervisor is limited in RAM so Gitlab was out of the question. Using the Issues and Projects features I keep track of my ideas and bugs. Here is a screenshot of the New Features board:

Automated builds and tests

For automatic builds I use Woodpecker, a self hosted CI system based on Docker containers. I could have put it all up on Github or Gitlab but I want to be in control of the source code, not put it on some third party that might have different profit-motives in a year and start charging a boatload of cash for it. Self-hosting means I am in control of when I update. Especially with the older compatibility in mind, I cannot be sure that Qt 5 will be available on the Github Actions free images in a few years from now. Gitlab is an option but that uses so much resources that I’d rather not. It has so many features I don’t need and cannot turn off. 


Here is a screenshot of my CI build running:

The CI automatically builds the Linux version, both Qt 5 and Qt 6 and runs the unit tests. I’m working on an automated Android build but that has low priority.

Unit tests are an important part of my workflow, almost all code is unit-tested one way or another. Not all classes have tests, some are tested by the parts of the application that utilize them. Code coverage is around 70% and I strive for 50% or up.

Windows builds

The Windows builds are done on a Windows 7 machine (not connected to the internet) with just Qt and InnoSetup installed. Mostly automated using a few batch scripts:

Most of the Windows testing is done on Windows 10 or 11 on actual machines but the final build is done on this Windows 7 box, 32 bit, Qt 5.15.

The source is always available in the app so if anyone wants they can compile a more optimized version themselves. The source code is also sent when you purchase the application on here.

If you have any specific questions regarding my development workflow, don’t hesitate to send me an email.