In common with most organisations active within professional software development, we, at Lemonbeat GmbH, work in accordance with the principle of “continuous integration”. By doing this, we can ensure that our customers always receive a carefully tested software release. What does continuous integration actually mean though?
Continuous integration within software development is an approach which combines various quality assurance measures. Its aim is to make sure that, when further developing software, all planned changes, as well as new features, function correctly and do not trigger unwanted effects within already existing modules. This quality ensuring approach supports the development process continually and means that, at the point of delivery, our developers can sleep at night.
A good analogy for the process would be that of a large kitchen: Various cooks are working on a menu, however, individually they cannot check that the composition of each dish is perfect. This role falls to the „Chef de Cuisine“, the kitchen’s continuous integration.
With Lemonbeat technology, the dish as it were is the complete IP-Stack, designed for communication between devices in the Internet of Things (IoT). These devices exchange information directly with each other using Lemonbeat smart Device Language (LsDL). Our software uses established IP-standards, offers full IPv6 integration, 128-Bit AES encryption, various handy services such as timer- and calender functions and, last but not least, can include patented and energy efficient Lemonbeat radio technology on the 868 MHz band.
During the development of all our software solutions we always adhere to coding conventions. These are definied programming rules within source code that help to maintain uniformity and allow fellow programmers to understand what has been implemented i.e. programmers “show their working”. As the souce code is then easier to read, fellow programmers find it easier to begin contributing and actively help develop software further. Furthermore this practice can also help achieve better quality and ease of serviceability.
Coding conventions, as an example, define how things such as functions, as well as data types, are labelled. They help when documenting implementations and can assist in maintaining a tidy structure within software.
Various cooks are working on a menu, however, individually they cannot check that the composition of each dish is perfect. This role falls to the „Chef de Cuisine“, the kitchen’s continuous integration.
When testing our software, we use our developer boards. These are hardware components, that bring together all of the Lemonbeat functionality on one board. Using these, our staff are able to run the entire firmware, and check that all functions have been succesfully tested in combination with hardware.
We have such a testing environment in our tech lab, and it’s here that current firmware fresh from development is used and automatically tested. This takes place continuously, and ensures that changes to the software are promptly tested. This software development is known as a „Nightly Build“.
During the tests, communication functions are carried out directly on the boards and validated. The computer automatically triggers each function one after the other, and tests whether the result of each test is correct. This way it can be ensured that previously implemented functions still work reliably after a software update.
Even though individual functions are tested manually by the developers, the automated process is also required simply because the increasingly complex software at some stage becomes almost impossible, and very costly, to manually check. In other words, this is an important tool that supports quality assurance.
In the event that all automatic, as well as manual, tests are passed, we have what is known as a “stable release“ i.e. a stable version of the current software. This stable version can then be passed on to customers.
A further advantage of continuous integration is the possibility to access the development history of the software at any time. Every change is recorded, and every previous version can be called up for checking and quality assurance. Through this, we can also resolve any errors should a bug appear in previous versions of the software already issued to customers.
Despite all of this, “stable releases” are not automatically issued to customers. The distribution of releases follows our project plan, which defines our release cycles. The flexibility of our workflows does however allow us occassionally by-pass our plan and deliver rapid adhoc corrections (hotfixes) if called upon.