Software Artefakte automatisch versionieren

Björn Schmitz

20/09/2019

Was ist das Problem?

Wenn wir Embedded Software entwickeln ist die Wunschvorstellung das wir nach V-Modell spezifizieren, implementieren, integrieren, testen und anschließend ausliefern. In realen Projekten sieht das aber natürlich etwas anders aus. In der Regel wird Software inkrementell entwickelt. Während der Entwicklung gibt es immer Zwischenstände mit unterschiedlichen Features, die unterschiedlich ausgereift sind. Wünschenswert wäre es natürlich, dass ausschließlich Hardware mit getesteten, stabilen Softwareversionen den Schreibtisch des Entwicklers verlässt. Leider ist dies bedingt durch den Projektplan und die anderen Projektteilnehmer oft nicht möglich. So kann es zum Beispiel passieren, dass der Hardwareentwickler schnell eine Software für den EMV Test benötigt oder der Projektleiter dem Kunden unbedingt morgen die neue GUI vorführen möchte. Oft werden die so entstandenen unreifen Versionen auf diese Weise im ganzen Haus verteilte oder gehen sogar an den Kunden raus. Nach einigen Wochen kommt dann auf einmal Hardware zurück auf den Tisch des Softwareentwicklers, mit dem Hinweis, dass bei der Benutzung ein Problem aufgetreten ist.

In der Regel wird der Projektleiter dem Entwickler die Aufgabe erteilen, dieses Problem zu untersuchen. Wenn der Entwickler nun nachvollziehen kann, um welchen Softwarestand es sich handelt, kann er eventuell darauf verweisen, dass es sich um einen Bug handelt, der bereits behoben wurde. Oft ist die Zuordnung von Embedded Softwareständen aber gar nicht so einfach.

Um das Problem zu lösen, gibt es in der Regel den Ansatz für jede Hardware, die im Umlauf ist, den aktuellen SW Stand zu verzeichnen. So kann man z. B. über ein Ticketsystem oder im Projektwiki Seiten anlegen, in dem jeder Hardware ein aktueller Standort und eine Software Versionsnummer zugeordnet wird. Solche Hardware Tracker klingen zunächst gut. Denkt man aber genauer darüber nach, schreit dieses Vorgehen geradezu danach, das auf diese Weise Fehler passieren. Es geschieht schneller, als man denkt, dass jemand außerhalb der SW, den Entwickler darum bittet, mal eben den neusten Stand auszuspielen. Oder vorher sogar noch eine Änderung durchzuführen.

So hat der SW Entwickler immer das Problem, wenn er die SW Version zuordnen will, dass er folgende Fragen nicht beantworten kann:

  • Ist die SW Version, die im Tracker steht wirklich korrekt?
  • Entspricht die Version wirklich 1:1 einem bestimmten Stand im Repository oder gibt es lokale Änderungen?
  • Mit welcher Build Konfiguration wurde die SW gebaut?

Wie kann man das Problem lösen?

Um dem Problem zu begegnen, liegt es nahe, die SW selber mit einem Versionsstempel zu versehen. Der erste Impuls, wenn man seine Software versionieren möchte, ist eine Konstante anzulegen. Das kann z. B. so aussehen:

#define REVISION     "1.01"

Das ist von der Idee her schon nicht schlecht. Man sollte sich aber im Klaren sein, dass wenn bei manueller Versionierung immer auf die oben beschriebenen Probleme stößt. Die Versionierung sollte also besser automatisch erfolgen. Ein einfaches Beispiel möchte ich hier, am Beispiel einer in Eclipse entwickelten Mikrocontroller Software kurz vorstellen:

Schritt 1: Die Version des Repositorys in die Software bekommen

Am besten lässt sich der Stand einer Software nachvollziehen, in dem man keine klassische Versionsnummer, sondern den Stand des Repositorys verwendet. Das kann z. B. die SVN Revision oder der GIT hash sein. In Eclipse lässt sich die Revision relativ leicht in einer Konstanten verwenden. Schauen wir uns das mal am Beispiel von SVN an:

Mit dem Markierten Makro, erzeugen wir einen konstanten String, der sich aus folgenden Punkten zusammensetzt

  • ${ConfigName}: Das ist der Name unserer Buildkonfiguration. In unserem Fall „Debug“
  • $(shell svnversion -n ‚ .\..‘): Das ist die aktuelle SVN Revision des Projektordners.
    • shell: ausführen eines Kommandozeilenbefehls
    • svnrevision: Gibt die SVN revision eines Ordners zurück. Dafür muss unser System natürlich diesen Befehl verstehen. Wer jetzt denkt, es reicht Tortoise SVN auf seinem PC installiert zu haben den muss ich leider enttäuschen. Tortoise mag entsprechende Kommandozeilenbefehle haben, allerdings unterstützt es nicht die klassischen SVN Kommandozeilenbefehle. Am einfachsten erhalte ich diese in dem ich den kostenlosen „SlikSVN Windows client“ installiere und in den Systemumgebungsvariablen unter „PATH“ den „bin“ Ordner von SlikSVN anlege.
    • „.\..“: Das ist der Pfad des Projektordners, relativ zum Output Ordner meiner Buildkonfiguration. Also in diesem Fall vom Ordner „Debug“ aus gesehen. Also der Ordner in dem die Artefakte der Debug-Konfiguration nach dem Bauen meiner Software landen.

Habe ich nun dieses Makro angelegt, erhalte ich beim Debuggen für das Makro SVN_REV folgenden Wert:

Aber was bedeutet „6427:6431M“? Hierbei handelt es sich um den Bereich der SVN Revisionen. Das heißt, ich habe in meinem Projektordner Dateien der SVN Revisionen 6427 bis 6431. Würde ich meinen lokal ausgecheckten SVN Ordner auf eine bestimmte Revision zurücksetzen, stünde hier einfach nur eine Zahl. Das „M“ bedeutet, dass es lokale Änderungen in meinem Projektordner gibt. Ich weiß also mit diesem String fast alles, was ich wissen muss, um die Herkunft der Software zuzuordnen. Das ist schon ziemlich cool, es geht aber noch besser.

Schritt 2: Eine feste Stelle im Speicher definieren

Mit Schritt 1 habe ich sichergestellt das die Revision in meiner Software immer bekannt ist. Ich kann diesen String also z. B. auf dem Display anzeigen lassen oder über eine Kommunikationsschnittstelle abfragen. Wenn mir das reicht, kann man hier aufhören. Ich kann das ganze aber noch verbessern, indem ich dem Versionsstring eine feste Nummer im Speicher zuweise. So kann diese z. B. auch durch den Bootloader ausgelesen werden.

Für die Versionsnummer lege ich zunächst im Linker-File einen Speicherbereich im Flash an:

/* Memories definition */
MEMORY
{
    RAM (xrw)   : ORIGIN = 0x20000000, LENGTH = 160K
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 262140
    VER (rx)    : ORIGIN = 0x0803FFE0, LENGTH = 28
}

Und weiter unten:

/* SVN revision goes here */
.app_ver_str :
{
    KEEP(*(.app_ver_str))
} > VER

Anschließend muss ich in meinem Code folgende Zeile einfügen.

const char __attribute__((section(".app_ver_str"))) VER[] = SVN_REV;

Mit dieser Zeile schreibe ich meine in Schritt 1 angelegte Konstante beim linken automatisch in die section „app_ver_str“. Diese habe ich im Speicherbereich „VER“ platziert. Sobald ich also meine Software neu baue, platziert der Linker automatisch meinen Versionsstring an Adresse 0x80FFE0. Wenn man das überprüfen möchte, reicht ein Blick in die .hex Datei:

Wenn wir das Ganze in einen Hex-zu-Ascii-Converter eingeben, von denen es im Internet jede Menge gibt, erhalten wir wieder unseren Revisionsstring „Debug_6427:6431M“. Das hat den angenehmen Nebeneffekt das ich auch .hex Dateien, welche eventuell im Umlauf sind, zuordnen kann, indem ich diese einfach mit einem Editor öffne.

Fazit

Es gibt viele Gründe seine Software automatisch zu versionieren. Wer ein neues Softwareprojekt aufsetzt, sollte möglichst schnell etwas Entsprechendes einrichten, bevor Software im Umlauf ist, deren Stand nicht mehr zugeordnet werden kann. Das hier gezeigte Vorgehen lässt sich natürlich auch auf nicht-Eclipse-basierte IDEs wie Keil oder IAR übertragen. Außerdem lässt sich das ganze ebenso gut (wenn nicht besser) mit GIT umsetzen.


Geschrieben von Björn Schmitz

Seit Juli 2017 gehöre ich zum MEDtech-Ingenieur Team und bin hier vor allem als Firmwareentwickler tätig. Schon in kürzester Zeit konnte ich an vielen spannenden Projekten aus dem Bereich Medizintechnik, aber auch aus anderen Bereichen mitwirken.


Weitere Beiträge

  • 12/11/2024
  • Allgemein, Software, Testen, Tools

In sicherheitskritischen Softwareprojekten steht die Qualität der Software an erster Stelle. Besonders bei Klasse-C-Software, die nach strengen Normen wie IEC 62304 (Medizintechnik) zertifiziert werden muss, ist es essenziell, dass ...

Weiterlesen
  • 08/08/2024
  • Allgemein, Elektrostimulation, Software, Testen

Heutzutage sind Apps im Gesundheitsbereich sehr wichtig. Besonders Apps, die Daten von medizinischen Sensoren lesen und verarbeiten können, sind nützlich. Flutter ist ein Open-Source-Framework von Google, das sich hervorragend ...

Weiterlesen
  • 30/06/2024
  • Allgemein, Hardware, Software, Technik, Tools, Usability

KI – Was ist das denn überhaupt? Künstliche Intelligenz ist zurzeit in aller Munde, doch die wenigsten Menschen beschäftigen sich mit der Funktionsweise von künstlicher Intelligenz oder damit, was ...

Weiterlesen
Cookie-Übersicht

Die Internetseiten der MEDtech Ingenieur GmbH verwenden Cookies. Cookies sind Textdateien, welche über einen Internetbrowser auf einem Computersystem abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies enthalten eine sogenannte Cookie-ID. Eine Cookie-ID ist eine eindeutige Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten Internetseiten und Servern, den individuellen Browser der betroffenen Person von anderen Internetbrowsern, die andere Cookies enthalten, zu unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige Cookie-ID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die MEDtech Ingenieur GmbH den Nutzern dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die Cookie-Setzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen uns, wie bereits erwähnt, die Benutzer unserer Internetseite wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie übernommen wird.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite jederzeit mittels einer entsprechenden Einstellung des genutzten Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

Weitere Informationen erhalten Sie in unserer Datenschutzerklärung.

Unbedingt notwendige Cookies

Dieses Cookie wird benötigt, um Ihre Cookie-Einstellungen zu merken und weitere Hauptfunktionen zur Verfügung zu stellen

Um Ihnen eine Auskunft über Ihre gespeicherten personenbezogenen Daten hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) geben zu können, benötigen wir einen Cookie, um Sie bei der Datenabfrage identifizieren zu können. Dieser Cookie muss aus Sicherheitsgründen deshalb aktiviert sein. Ein weiterer Cookie wird gesetzt, um diesen Banner nicht erneut anzeigen zu müssen.

Cookie-Name Beschreibung
PHPSESSID Name: PHP session
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wir benötigt, um Sie bei der Anfrage von personenbezogenen Daten identifizieren zu können. Das Cookie wird nur gesetzt, wenn Sie eine Anfrage hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) stellen.
Laufzeit: Sitzungsende
Kategorie: Unbedingt notwendige Cookies
moove_gdpr_popup Name: Cookie-Box Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wird benötigt, um Ihre Cookie-Einstellungen zu speichern, um den Cookie-Banner nicht erneut anzeigen zu müssen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
comment_author_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_email_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_url_9c90e388e3e1be4a6c594fa6ac8a3eec
Name: Kommentar Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Cookie wird angelegt, wenn Sie ein Kommentar auf MEDtech Ingenieur veröffentlichen wollen, um Sie als Autor identifizieren und den aktuellen Status Ihres Kommentars anzeigen zu können. Das Cookie enthält den angegebenen Namen. Das Cookie wird erst gesetzt, wenn Sie der Speicherung Ihrer personenbezogenen Daten zustimmen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
rmp-rate Name: RMP Rate
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie eine Bewertung eines Blogbeitrags mithilfe des Sternebewertungssystems abgeben. Ihnen wird eine anonymisierte ID zugewiesen, um zu erkennen, ob Sie einen Artikel bereits bewertet haben oder nicht. Das Cookie wird nur verwendet, um zu verhindern, dass mehrfache Bewertung abgegeben werden und erst gesetzt, wenn Sie auf einen Stern klicken.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
medtech-download-page Name: Download Page
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie den Landing-Page Prozess erfolgreich durchlaufen haben. Dies geschieht nur, wenn Sie einen Content-Download von unserer Website anstreben.
Laufzeit: 1/2 Jahr
Kategorie: Unbedingt notwendige Cookies