Scrollrichtung für die Magic Mouse einstellen

Vor ein paar Tagen schrieb ich wie sich die Scrollrichtung unter macOS unabhängig einstellen lässt. Während dies mit klassischen Mäusen problemlos funktioniert, sieht es bei der Magic Mouse von Apple leider anders aus. Dort ist die Scrollrichtung identisch mit der für das Trackpad.

Die Einstellungen von Scroll Reverser

In den Augen des Autors von UnnaturalScrollWheels ist dies allerdings kein Fehler, mit einer durchaus nachvollziehbaren Argumentation. Allerdings gibt es mit Scroll Reverser eine Alternative, welche ebenfalls über Homebrew installiert werden kann:

brew install scroll-reverser

Auch mit Scroll Reverser kann die Scrollrichtung von Maus und Trackpad angepasst werden. Im Gegensatz zu UnnaturalScrollWheels, funktioniert dies auch in Verbindung mit der Magic Mouse.

Der Quelltext der App ist auf GitHub zu finden und unter der Apache License lizenziert. Damit ist das Tool freie Software.

Commodore 64 Emulator für macOS

Immer wenn ich einen Emulator für den Commodore 64 unter macOS nutzen wollte, habe ich in den letzten Jahren VICE genutzt. Allerdings wirkte VICE mittlerweile etwas angestaubt, sodass ich mich ein wenig umgeschaut habe und auf Virtual64 gestoßen bin. Neben dem Download über die Projektseite kann VirtualC64 über Homebrew installiert werden:

brew install virtualc64

Nach der Installation kann der Emulator gestartet werden und verlangt einige initiale Konfigurationsschritte.

Die ROMs müssen konfiguriert werden

Konfiguriert werden müssen die ROMs für das BASIC, den KERNAL und den Zeichensatz. Optional kann auch ein ROM für das 1541-Diskettenlaufwerk konfiguriert werden. Da die urheberrechtliche Situation dieser ROMs unklar ist, werden sie nicht mit dem Emulator mitgeliefert. VirtualC64 bietet die Möglichkeit freie Nachbauten dieser ROMs zu nutzen.

Ansonsten kann ein Original-ROM-Set genutzt werden:

basic.901226-01.bin
characters.901225-01.bin
kernal.901227-03.bin
1541-II.251968-03.bin

Nachdem die ROMs konfiguriert sind, kann der Emulator in Betrieb genommen werden. Neben den Grundfunktionalitäten, wie der Konfiguration der Joysticks bietet der Emulator eine Reihe von Funktionen, um in die Tiefe zu gehen, wie z.B. unterschiedlichste Inspektoren für die internen Zustände des Computers.

Ein Programm wird geladen

Der Quelltext des Emulators ist auf GitHub zu finden. Er ist unter der GPL in Version 2 lizenziert und damit freie Software.

Matter im Überblick

Im Laufe der letzten Jahre und Jahrzehnte sind einige Smart Home-Standards auf den Markt gekommen. Mit Matter ist nun ein neuer Standard angetreten, welcher den Smart Home-Markt aufrollen möchte.

Doch abseits der für den Endnutzer gedachten Versprechen, welche Vorteile er bringen soll, wird erstaunlich wenig über die technischen Hintergründe gesprochen.

Allerdings helfen diese Hintergründe Matter und seine Möglichkeiten zu verstehen. In diesem Artikel sollen die Hintergründe von Matter beleuchtet und gezeigt werden, wie Matter abseits der Marketingversprechen funktioniert.

Bestehende Standards

Matter ist beileibe nicht der erste Standard, welcher sich mit dem Thema Smart Home beschäftigt. Vor ihm gab und gibt es Standards wie Z-Wave, EnOcean und Zigbee. Letzterer spielt bei Matter organisatorisch eine besondere Rolle.

Je nach Standard werden unterschiedlichste Technologien und Funksysteme genutzt, wie das vermaschte Netzwerk, welches Z-Wave-Geräte untereinander aufbauen.

Das Problem an diesen Systemen ist, dass sie meist zueinander inkompatibel sind. Über Lösungen wie Home Assistant oder Homee können diese unterschiedlichen Systeme zur Zusammenarbeit gebracht werden.

Allerdings wird auch hier in vielen Fällen nur eine begrenzte Anzahl an Hardware unterstützt. Eine allumfassende Lösung stellt dies meist nicht dar.

Auch ins heimische Funknetz eingebundene Geräte werden gerne für die Smart Home-Anwendungen genutzt, welche auch durch ihren günstigen Preis bestechen können.

Aus Sicht von Entwickler sind unterschiedlichste Standards ein Problem. Je nach Firmengröße kann sich nur für einen Standard entschieden werden, da zusätzlich zu unterstützende Standards mehr Entwicklungsaufwand und damit am Ende mehr Kosten bedeuten.

Daneben sind die unterschiedlichen Standards zwar mehr oder weniger gleichwertig, allerdings gibt es eine gewisse Fragmentierung bei den Geräteklassen, so sind Leuchtmittel vorwiegend mit dem Zigbee-Standard verheiratet oder werden über teils obskure Wi-Fi-Lösungen angebunden.

Zwar existieren auch Beleuchtungslösungen für Z-Wave, allerdings sind diese in ihrer Auswahl beschränkt und der Preis ist in vielen Fällen höher als bei den Zigbee-Varianten.

Es gibt es Hersteller, welche mehrere Systeme unterstützen und die gleichen Produkte wie schaltbare Steckdosen in unterschiedlichen Varianten, je nach Smart Home-System, anbieten.

Für den Kunden bedeutet diese Auswahl und die damit verbundenen Probleme wie die Berücksichtigung der Kompatibilität, dass er meist zögerlich zu Smart Home-Produkten greift. Aus Sicht der Hersteller und der Kunden ist dies eine suboptimale Situation: voneinander abgeschirmte Ökosysteme und Geräte, die nur unter Umständen miteinander genutzt werden können.

Smart Home-Markt

Für das Jahr 2022 wird von einem Umsatz im Smart Home-Markt von über einhundert Milliarden Euro ausgegangen.

Allerdings bedingt durch die Fragmentierung des Marktes, entspricht dieser Umsatz nicht dem, der vor einigen Jahren erwartet wurde. So wurde unter anderem von einer höheren Durchdringung des Marktes ausgegangen.

Aktuell nutzen knapp 15 % aller Haushalte, weltweit gesehen, Smart Home-Technik in ihrem Haus oder ihrer Wohnung. Bedingt durch die Vorteile, welche Matter bieten soll und die damit einhergehende Vereinheitlichung, soll dem Smart Home-Markt neues Leben eingehaucht werden.

Das Matter-Versprechen

Matter will die bestehenden Probleme anderer Standards lösen. Der Standard sieht sich als Smart Home-Interoperabilitätsprotokoll und definiert sich als Anwendungsschicht, welche existierende Protokolle wie Thread und Wi-Fi nutzt, um seine Aufgabe, eine Smart Home-Umgebung darzustellen und zu verwalten, zu erfüllen.

Im Grundsatz geht es darum, dass der neue Standard unabhängig von den einzelnen Herstellern sein soll. Auch soll es jedem Hersteller von Hardware möglich sein, den neuen Standard zu implementieren.

Dem Endnutzer wird die Kompatibilität, aller Matter-Geräte untereinander, versprochen. Daneben soll in Zukunft auf proprietäre Bridges und Hubs, welche zur Anbindung bestimmter Systeme genutzt werden, verzichtet werden können.

Eine weitere wichtige Eigenschaft von Matter ist, dass die Steuerung zwar in der Theorie an Cloud-Systeme angebunden werden kann, aber immer lokal funktionieren muss.

Aus Sicht des Datenschutzes und der Betriebssicherheit ist dies eine erfreuliche Entwicklung, da Steuersignale nun nicht mehr die halbe Welt umrunden müssen, bevor sie wieder im eigenen Zuhause ankommen. Auch die Zuverlässigkeit stärkt dies in der Theorie, da auch beim Wegfall der Internetverbindung das eigene Smart Home noch funktioniert.

Für die Einrichtung von Matter-Geräten werden nicht mehr unbedingt die Third-Party-Apps der jeweiligen Hersteller benötigt, sondern diese können zentral über Apps z. B. der Home-App unter iOS hinzugefügt werden.

Connectivity Standards Alliance

Organisatorisch wird der Matter-Standard von der Connectivity Standards Alliance (CSA) betreut. Diese ging aus der Zigbee Alliance, welche 2002 gegründet wurde, hervor, welche sich für den gleichnamigen Zigbee-Standard verantwortlich zeichnet.

Mittlerweile sind über 500 Firmen unter dem Dach der Connectivity Standards Alliance vereint. Dazu gehören Unternehmen wie Amazon, Apple, Comcast, Google, IKEA, Infineon, LG, Nordic Semiconductor und Samsung.

Von der Idee zum Standard

Erste Lebenszeichen des Matter-Standards gab es im Dezember 2019. Damals kündigten unter anderem Amazon, Apple und Samsung sowie die Zigbee Aliance an, dass eine Zusammenarbeit für das Projekt Connected Home over IP beschlossen wurde.

Knapp anderthalb Jahre nach der ersten Ankündigung wurde aus Connected Home over IP schließlich Matter. Im gleichen Zuge wurde durch eine Umbenennung aus der Zigbee Alliance die Connectivity Standards Alliance.

Nach etwa drei Jahren Zeit der Planung und Entwicklung erschien im Oktober 2022 mit der Version 1.0 die erste Iteration des Standards. Hier wurden neben der eigentlichen Standardbeschreibung unterschiedliche Produktkategorien wie Beleuchtungslösungen, Sicherheitssensorik, Thermostate, Türschlösser und einige andere spezifiziert.

Während der Entwicklung gab es bedingt durch Faktoren wie die Coronapandemie und Verzögerungen bei den Gerätetests einige Verschiebungen, welche dann schlussendlich zum Veröffentlichungstermin im Oktober 2022 führten. Im November 2022 wurde Matter offiziell auf einem Launch-Event in Amsterdam vorgestellt.

In der nächsten Iteration des Standards, der Version 2.0, welche im März bzw. April 2024 erscheinen soll, sollen unter anderem die unterstützten Geräte um Klassen wie Staubsauger-Roboter, Rauchmelder, Kameras und einige andere erweitert werden.

Architektur

Aus architektonischer Sicht betrachtet ist Matter ein Applikationsprotokoll, welches auf bestehenden Technologien aufsetzt. Grundlage für das Matter-Protokoll bildet IPv6.

Matter setzt als Applikationsprotokoll auf vorhandenen Technologien auf

Der Matter-Protokollstack selbst besteht aus unterschiedlichsten Schichten, welche jeweils bestimmte fachliche Anforderungen erfüllen.

Die Schichten des Matter-Protokollstack

Die Anwendungsschicht (Application Layer) innerhalb des Matter-Protokollstacks implementiert die dem Gerät eigene Businesslogik. Im Falle einer schaltbaren Steckdose wäre dies die Logik, um das Gerät ein- und auszuschalten. Aktionen in der Anwendungsschicht führen zur Änderung im Datenmodell (Data Model).

Im Datenmodell werden die Daten für das entsprechende Gerät gehalten, z. B. ob das Gerät aktuell angeschaltet ist oder bei einem Leuchtmittel, die aktuell ausgewählte Leuchtfarbe.

Für die Interaktion von Außen werden im Interaction Model bestimmte Interaktionen definiert, welche von Außen geschrieben oder gelesen werden können. Eine solche Interaktion löst dann eine Logik in der Anwendungsschicht des Gerätes aus, um die entsprechenden Aktionen auszulösen.

Über das Interaction Modell kann eine Aktion definiert werden und über die Action Framing-Schicht wird sie schließlich in ein binäres Format serialisiert und dieses an die Security-Schicht übergeben.

In dieser wird die Nachricht verschlüsselt und ein Message Authentication Code angehangen. Damit soll sichergestellt werden, dass die Daten sicher und verschlüsselt zwischen den Instanzen bzw. Geräten übertragen werden.

Damit sind die Daten für die Nachricht serialisiert, verschlüsselt und kryptografisch signiert und werden an die Message Framing-Schicht übergeben, in welcher die endgültige Payload, welche schlussendlich über das Netzwerk verschickt wird, erzeugt wird. In Rahmen dieses Prozesses werden Headerfelder ergänzt, welche unter anderem Routing-Informationen enthalten können.

Anschließend wird das Ganze an die Transportschicht übergeben und findet so seinen Weg durch das Netzwerk, bis es beim definierten Empfänger ankommt. Dort angekommen wird der Matter-Protokollstack in umgekehrter Reihenfolge durchlaufen, bis schlussendlich wieder die eigentliche Nachricht in der Anwendungsschicht verarbeitet werden kann.

Fabric, Nodes und Controller

Im Matter-Standard werden einige Begriffe definiert, deren Wissen um die Bedeutung ein Verständnis des Standards erleichtert.

Ein zentraler Begriff im Matter-Standard ist die Fabric. Bei einer Fabric handelt es sich um einen logischen Verbund von Knoten (Nodes), welche eine gemeinsame Vertrauensbasis (Common Root of Trust) und einen gemeinsamen verteilten Konfigurationsstatus besitzen.

Ein Knoten (Node) ist im Matter-Standard definiert als eine Entität, welche den Matter Protokollstack unterstützt und nach der Kommissionierung über eine Operational Node ID und Node Operational Credentials verfügt.

Eine schaltbare Steckdose

Dabei ist ein Node nicht unbedingt gleichzusetzen mit einem Gerät. Ein Gerät, wie eine schaltbare Steckdose kann in der Theorie mehrere Knoten beinhalten, welche wiederum zu mehreren Fabrics gehören können.

Daneben gibt es im Matter-Standard den Begriff des Controllers. Dieser ist definiert als ein Matter-Knoten, welcher die Berechtigung hat einen oder mehrere Knoten zu kontrollieren. Dies kann z. B. das Smart Home-System sein oder ein iPhone mit der entsprechenden Home-App. Matter unterstützt per Design unterschiedlichste Controller in einem Matter-Netzwerk. Dieses Feature wird als Multi-Admin bezeichnet.

Kerntechnologien

Für Matter-Netzwerke, sind einige Kerntechnologien definiert, welche im Rahmen des Standards genutzt werden.

Für die Kommunikation der Geräte untereinander wird Wi-Fi, Ethernet oder Thread benutzt, für die Kommissionierung Bluetooth LE.

Bluetooth LE

Bluetooth LE wird im Matter-Standard genutzt, allerdings nicht für die Kommunikation der Geräte untereinander. Stattdessen wird Bluetooth LE für Kommissionierung (commission, im Matter-Standard) der Geräte genutzt.

Nach der Definition des Matter-Standards wird bei der Kommissionierung ein Node in die Fabric eingebracht, also das Gerät dem Matter-Netzwerk hinzugefügt.

Im Rahmen dessen werden die Zugangsdaten des Netzwerkes und andere für die Kommissionierung benötigten Informationen auf das Gerät übertragen.

Im Anwendungsfall würde dies so aussehen, dass der Nutzer einen QR-Code scannt, welcher die Informationen über das Gerät enthält und anschließend die Kommissionierung mittels Bluetooth LE durchgeführt wird.

Diese Informationen müssen nicht unbedingt als QR-Code geliefert werden. In der Theorie kann auch NFC als Technologie benutzt werden oder die enthaltenen Informationen einfach als kodierte Zeichenkette auf dem Gerät aufgedruckt sein oder dem Handbuch beiliegen.

Dies ermöglicht eine einfache Konfiguration und Einbindung der Geräte aus Sicht des Endbenutzers. Ist die Kommissionierung abgeschlossen und das Gerät damit in das Matter-Netzwerk eingebunden, nutzt das Gerät Bluetooth LE nicht mehr.

Anbindung der Smart Home-Geräte

In den meisten praxisnahen Fällen wird die Anbindung von Geräten meist auf die Anbindung per Thread und Wi-Fi hinauslaufen. Bei Wi-Fi im Heimbereich sind alle Geräte mehrheitlich mit einem Access Point verbunden. Bei Thread hingegen handelt es sich um ein vermaschtes Netz, welche über Border-Router mit dem Rest des Netzwerkes verbunden ist.

Thread

In einem Smart Home sind eine Reihe von Aktoren, wie schaltbare Steckdosen und Ähnliches verbaut. Daneben gibt es dann noch Sensorik, z. B. in Form von Temperatur- und Bewegungssensoren.

Sensoren, wie Temperatur oder Bewegungssensoren, laufen mehrheitlich mit Batteriestrom und eignen sich damit nicht für energieintensive Techniken wie Wi-Fi, um ihre Daten von A nach B zu transportieren.

Ein batteriebetriebener Sensor

Hier kommt das Protokoll Thread ins Spiel. Dieses ist darauf ausgelegt, Geräte miteinander zu verbinden, welche eine geringe Datenrate benötigen und möglichst wenig Energie verbrauchen sollen. Das Protokoll besticht durch sein simples Design und ermöglicht geringe Latenzen.

Das Netzwerkprotokoll Thread versteht sich als selbstheilendes Mesh-Netzwerk. Ein Designziel war es unter anderem, dass es keinen Single Point of Failure in einem solchen Netzwerk geben soll, die Übertragung zuverlässig und die Reichweite durch das Routing innerhalb des Thread-Netzwerkes gegeben ist.

Im Rahmen von Matter sollen hunderte bis tausende Produkte über Thread in einem Netzwerk unterstützt werden.

Entwickelt wird das Protokoll seit 2014 von der Thread Group welcher unter anderem ARM Limited, Nest Labs, Samsung und Qualcomm angehören. Die Entwicklung ist seit dem nicht stehen geblieben und so wurden mit Thread 1.3 Funktionalitäten wie vollumfängliches IP-Routing und Service-Discovery hinzugefügt. Diese Funktionalitäten werden für die Nutzung von Thread im Zusammenhang mit Matter benötigt.

Thread setzt auf IEEE 802.15.4 auf, bei welchem es sich um ein Standard für kabellose Netzwerke mit geringen Datenraten handelt. In IEEE 802.15.4 ist die Bitübertragungsschicht (Physical Layer) und die Data-Link-Schicht definiert.

Neben Thread setzt unter anderem auch Zigbee auf IEEE 802.15.4 auf, was ein Update solcher Geräte, hin zu Thread, perspektivisch möglich macht.

Das OSI-Modell

Darüberliegende Schichten, welche z. B. das Routing übernehmen können, müssen dann von anderen Protokollen übernommen werden. An dieser Stelle setzt Thread ein.

Per Thread angebundene Geräte können per IPv6 adressiert werden. Wichtig ist es festzuhalten, dass es sich bei Thread nicht um Matter handelt, sondern Thread ein eigenständiges Funkprotokoll ist, welches wie Wi-Fi der Anwendungsschicht agnostisch gegenübersteht.

Rollenspiele

Bei Thread kann jedes Gerät unterschiedliche Rollen annehmen. So gibt es in einem Thread-Netzwerk, einen Leader, einen oder mehrere Router und die Rolle des Endgerätes.

Jedem Gerät wird mindestens die Rolle des Endgeräts zugewiesen. Das sind solche Geräte, welche einen Befehl in Form eines Datenpaketes erhalten, um diesen auszuführen.

Ein Leader ist eine Rolle, welche nur einmal vergeben wird. Dieser koordiniert das Thread-Netzwerk. Fällt ein Leader aus, so wird automatisch ein neuer Leader bestimmt. Dazu ist es notwendig, dass jederzeit andere Geräte für den bestehenden Leader einspringen können. Die Zustandsinformationen müssen also im Netzwerk aktuell gehalten werden.

Router, leiten Datenpakete im Thread-Netzwerk weiter. Diese Rolle wird dynamisch von den jeweiligen Geräten aktiviert bzw. wieder deaktiviert, wenn z. B. zu viele Router in der Umgebung unterwegs sind. Daneben bieten die Router Funktionalität, wie Security Services, für andere Geräte, die dem Netzwerk beitreten wollen.

Normalerweise nehmen Thread-Geräte nur die Rolle als Endgerät wahr. Wird mehr Reichweite im Netzwerk benötigt, werden einige dieser Geräte automatisch Router in diesem. Das passiert z. B. dann, wenn ein Endgerät keinen Router findet, aber ein Endgerät in der Theorie eine solche Rolle einnehmen kann.

Auf der anderen Seite funktioniert dies auch, wenn sich zu viele Router in einem Bereich befinden und damit zu viel Redundanz vorhanden ist. In diesem Fall stufen sich Geräte in wieder zurück und geben die Router-Rolle auf. Dies ist z. B. dann der Fall, wenn ein Gerät nur noch mit anderen Geräten verbunden ist, welche ebenfalls die Router-Rolle wahrnehmen.

Damit ist das Routerkonzept, im Gegensatz zu Technologien wie Bluetooth Mesh oder Zigbee dynamisch.

FTDs und MTDs

Thread kennt unterschiedliche Typen von Geräten. Einerseits gibt es sogenannte Full Thread Devices (FTD) und sogenannte Minimal Thread Devices (MTD).

Bei den FTDs handelt es sich um autonome Geräte im Thread-Netzwerk, welche Rollen, jenseits der Endgeräte-Rolle, wahrnehmen. Im Normalfall haben diese Geräte entsprechende Hardwareressourcen, wie genügend Speicher et cetera. Im Gegensatz zu den MTDs sind FTDs immer mit dem Thread-Netzwerk verbunden. Infolgedessen sind FTDs meist solche Geräte, welche direkt am Stromnetz angeschlossen sind.

Ein einfaches Thread-Netzwerk

MTDs hingegen sind für solche Geräte gedacht, welche größtenteils über eine Batterie betrieben werden. In diese Kategorien fallen Geräte wie Sensoren und Ähnliche. Diese müssen mit ihren Ressourcen entsprechend haushalten. Sie treten deswegen nur sporadisch mit dem Thread-Netzwerk in Kontakt und befinden sich den Großteil ihrer Betriebszeit im Schlafmodus.

MTDs senden alle ihre Nachrichten zu einem sogenannten Parent-Device und nehmen nur die Rolle als Endgerät im Thread-Netzwerk wahr.

Border-Router

Da im Rahmen von Matter Informationen aus dem Thread-Netzwerk heraus in den Rest des Netzwerkes gelangen müssen, werden hier wieder Router, sogenannte Border-Router benötigt. Diese routen die Informationen aus und in das Thread-Netzwerk.

Im Gegensatz zu anderen Systemen unterstützt Thread mehrere Border-Router, um auch hier wieder einen Single Point of Failure zu vermeiden. Die Funktionalität solcher Border-Router wird und kann von unterschiedlichsten Geräten wahrgenommen werden. Beispiele für solche Geräte sind z. B. Alexa-Geräte oder der HomePod mini von Apple.

Während bei Bridges eine Übersetzung der jeweiligen Daten vorgenommen wird, damit sie vom anderen System verstanden werden, werden bei den Border-Routern nur die entsprechenden Daten vom Thread-Netzwerk in das andere Netzwerk geroutet. Eine Übersetzung derselben findet nicht statt.

Wi-Fi

Neben Thread können Geräte im Matter-Standard auch über Wi-Fi eingebunden werden. Als Übertragungstechnik bietet sich Wi-Fi für Smart Home-Geräte an, welche eine höhere Bandbreite benötigen und meist auch über ein entsprechendes Energiebudget verfügen und zumeist direkt an das Stromnetz angeschlossen sind.

In diese Kategorie fallen unter anderem Videokameras und Türklingeln mit Videoverbindung. Allerdings ist Wi-Fi bzw. ein einzelner Access Point nicht unbedingt dafür gedacht, eine große Menge an Geräten gleichzeitig zu bedienen.

Mit Wi-Fi 6 sind Verbesserungen eingeflossen, um mehr Geräten in einem Netzwerk entsprechende Daten simultan senden zu können, sodass die Nutzung für Smart Home-Geräte auch hier in Zukunft sinnvoller ist.

Distributed Compliance Ledger

Ein interessantes Detail an Matter ist der Distributed Compliance Ledger. In dieser verteilten Datenbank bzw. Blockchain befinden sich kryptografisch abgesicherte Daten über die Geräteherkunft, den Status der Zertifizierung sowie wichtige Einrichtungs- und Betriebsparameter.

Eingesehen werden kann die Datenbank unter anderem über eine entsprechende Weboberfläche. Die verwendete Software dafür kann auf GitHub ebenfalls eingesehen werden.

Gelesen werden kann die Datenbank von jedermann während Schreibzugriffe nur Herstellern im Rahmen ihrer Produkte gestattet sind.

In dieser Datenbank, können Hersteller von Produkten Informationen über diese hinterlegen, damit sie von jedermann gelesen werden können. Auch die Ergebnisse von Compliance Tests werden in diese Datenbank geschrieben. Dasselbe gilt für die Compliance Confirmation der CSA.

Für den Nutzer wird der Distributed Compliance Ledger interessant, um zu erfahren, ob ein Gerät als mit dem Standard konform zertifiziert wurde oder um Modellinformationen wie Firmware- und Hardware-Versionen auszulesen. Auch Zertifikate können über die Datenbank bezogen werden, um lokale Zertifikate zu überprüfen.

Die Netzwerktopologie des Distributed Compliance Ledger

Im Kontext des Ledgers existieren unterschiedliche Knoten. Einer dieser Knoten sind Validator-Knoten welche eine komplette Kopie der Datenbank vorhalten. Nicht jeder Knoten kann ein Validator-Knoten sein, er benötigt hierfür eine Erlaubnis. Auch die Anzahl der Validator-Knoten sollte beschränkt sein.

Ein weiterer Knoten ist der Observer-Knoten. Auch dieser enthält eine komplette Kopie der Datenbank und jeder darf einen solchen Observer-Knoten aufsetzen. Daneben existieren noch andere Knoten wie Sentry-Knoten, welche vor Validator-Knoten stehen können und ein Weg des DDoS-Schutzes sind.

Der Client kann sich nun mit einem dieser Knoten verbinden und die benötigten Informationen erfragen. Die Responses sind kryptografisch abgesichert, sodass es keine Rolle spielt, ob sie von einem Observer– oder einem Validator-Knoten kommen.

Technisch setzt das System auf Tendermint bzw. dem Cosmos SDK auf, welches ein Framework für Blockchains zur Verfügung stellt.

Unterstützung

Matter an sich ist noch ein relativ junger Standard und im Moment ist es noch schwierig kompatible Geräte zu finden, auch wenn teilweise schon Updates und Geräte ausgeliefert worden sind. Dies betrifft z. B. einige Geräte von Eve Systems oder Produkte von Nanoleaf mit Matter-Unterstützung.

Interessant ist die Unterstützung auch vonseiten der Betriebssystemanbieter für mobile Systeme, wie iOS und Android. Mit iOS 16.1 lieferte Apple die Unterstützung für Matter aus. Bei Android lieferte Android 13 die ersten Integrationen für Matter.

Auch Smart Speaker wie die Alexa-Serie von Amazon unterstützen mittlerweile Matter, so wurden bereits Updates für einige Modelle ausgerollt, weitere Modelle sollen Anfang 2023 folgen. Einige Geräte fungieren dann auch als Thread-Border-Router und ermöglichen so die Integration von Smart Home-Geräten. Das Gleiche gilt für HomePod minis und den Apple TV 4K, welche ebenfalls Thread unterstützten.

Auch auf Produktseite fangen immer mehr Hersteller an Support für Matter in ihre Produkte einzubauen, so können Entwickler z. B. mit den Philips Hue-Hubs und Geräten in Verbindung mit Matter erste Tests durchführen.

Lizenz

Wer sich Matter anschauen möchte, kann sich die Spezifikation herunterladen, nachdem einige Daten bei CSA hinterlegt worden sind. Ein frei verfügbarer Download existiert nicht.

Ähnlich sieht es auch beim Thread-Standard aus. Hier werden auch entsprechende Hinweise in der E-Mail gegeben:

Please also note, as per the Thread 1.1 Specification EULA, you are prohibited from sharing the document.

Grundsätzlich handelt es sich bei Matter um einen proprietären Standard, der genutzt werden kann, nachdem eine Zertifizierung durchgeführt und die Mitgliedsgebühren für die Connectivity Standards Alliance gezahlt wurden. Offizieller Quellcode rund um Matter ist auf GitHub zu finden und unter der Apache-Lizenz lizenziert.

Problematisch wird das Lizenzierungsmodell des Matter-Standards für GPL-Software, bedingt durch die jährlich zu leistenden Zahlungen an die Connectivity Standards Alliance, welche mit der GPL nicht vereinbar sind.

Migration auf Matter

Interessant wird es auch, wenn ein bestehendes Smart Home auf Matter umgerüstet werden soll. In einem solchen Fall sind bereits Systeme wie Zigbee oder Z-Wave installiert und die Frage stellt sich, wie diese Systeme umgestellt werden können.

Der einfachste Weg wäre es natürlich alle bestehenden Altgeräte auszubauen und anschließend neue kompatible Matter-Geräte einzubauen. Dies wird, ist den meisten Fällen aus Kostengründen und mangels fehlender Praktikabilität kein Weg sein, der gegangen werden kann.

Im Matter-Standard selbst sind für diesen Fall Bridges vorgesehen, mit welchen diese „Altsysteme“ angebunden werden können. Ein Bridge definiert sich im Matter-Standard dadurch, dass sie ein Matter-Knoten darstellen, welcher eines oder mehrere Nicht-Matter-Geräte darstellt.

Ein komplexes Matter-Netzwerk

Über solche Bridges können schlussendlich bestehende Netzwerke eingebunden werden. Daneben lassen sich einige Produkte, welche z. B. Hardware nach dem 802.15.4-Standard verbaut haben oder aber bereits Thread unterstützen per Softwareupdate so upgraden, dass sie mit dem Matter-Netzwerk kompatibel werden.

Problematisch an solchen Bridge-Lösungen ist, dass die Geräte nicht direkt integriert sind und somit unter Umständen parallele Mesh-Systeme im Smart Home existieren. Aber über solche Bridge-Lösungen ist möglich, Stück für Stück in die neue Matter-Welt zu migrieren und so den Migrations-Big-Bang zu vermeiden.

Ausblick und Fazit

Matter hat sich als neuer Standard aufgestellt, um den Smart Home-Markt aufzurollen. Dass mit neuen Standards die alten Standards nicht unbedingt obsolet werden, hatte schon XKCD in einem seiner bekannteren Comics gezeigt.

Doch wie könnte die Zukunft von Matter aussehen? Da sich praktisch jeder größere Smart Home-Anbieter und andere Firmen wie Apple, Amazon, Google und Samsung an Matter beteiligen, könnte Matter das Potenzial haben, den Markt aufzurollen.

Schlussendlich stellt sich hier die Frage nach den Produkten, die mit Matter-Unterstützung auf den Markt gebracht werden und ob diese die Kundenwünsche erfüllen können.

Auch muss der Standard, der in der Theorie übergreifend unterstützt wird und dessen Geräte unabhängig vom Hersteller genutzt werden können, dies noch in der Praxis beweisen. Im schlimmsten Fall ist der Kunde hier wieder der Leidtragende, weil er kleine und größere Inkompatibilitäten ertragen muss.

Im besten Fall führt der neue Standard zu einer Migration alter Lösungen in Richtung Matter. Der Zigbee-Standard ist praktisch ein Legacy-Standard geworden und Z-Wave wird im schlimmsten Fall einen langsamen Tod sterben, da viele Nutzer zu Matter abwandern werden und Z-Wave es schwer haben wird, gegen diesen Standard zu bestehen.

Auch wenn Z-Wave aufgrund der genutzten Funkfrequenzen kleinere technische Vorteile hat, sind dies wahrscheinlich keine Faktoren, welche sich auf Kundenseite auswirken werden. Auch wenn dies in der Z-Wave Alliance anders gesehen wird:

Matter is bringing a lot of attention to the smart home. This makes it easy to overlook Z-Wave as the most established, trusted, and secure smart home protocol, that also happens to have the largest certified interoperable ecosystem in the market. We firmly expect that Z-Wave will play a key role in connecting devices and delivering the experience users really want.

Im Rahmen des Artikels wurde einige Hintergründe von Matter erläutert, trotzdem wurde Matter nur angerissen, da der Standard auf über achthundert Seiten, viele Details definiert und unterschiedlichste Verfahren im Detail erläutert.

Wenn Matter seine Versprechen halten kann und die Nutzung für den Kunden einfacher ist, könnte es ein Standard sein, der ein Großteil der Nutzer und Hersteller in Zukunft hinter sich vereinen könnte.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Workflows im Entwicklungsalltag

Einen Entwicklungszweig anlegen oder doch lieber nicht? Wann geht es zum Test? Workflows im Entwicklungsumfeld sind vielschichtig und sollten zum jeweiligen Projekt passen.

Wer Software entwickelt, der kann dies klassisch bewerkstelligen und seine Software einfach in einem Ordner auf der Festplatte entwickeln und gelegentlich eine Kopie des Ordners erstellen. So finden sich am Ende unzählige Versionen der Software verteilt über verschiedene Verzeichnisse auf der Festplatte.

Auch wenn nicht ausgeschlossen werden kann, dass so in der einen oder anderen Firma entwickelt wird, so werden heutzutage meist Versionskontrollsysteme genutzt und mithilfe dieser ein Arbeitsablauf abgebildet. Kombiniert werden die Versionskontrollsysteme dabei größtenteils mit einem Ticketsystem und entsprechenden Wikis.

Im Rahmen des Artikels wird hierbei besonders auf das Versionskontrollsystem Git Bezug genommen. Git legt den Nutzer nicht auf einen Arbeitsablauf fest, sondern gibt dem Nutzer die Möglichkeit einen gewünschten Arbeitsablauf zu implementieren, ohne dass Git dem Nutzer eine bestimmte Arbeitsweise aufzwingt.

Anforderungen

In den meisten Fällen wird Software anhand von Anforderungen entwickelt. Eine Anforderung entsteht, entweder beim Kunden oder innerhalb der Firma. Diese Anforderung wird definiert und nachdem sie (hoffentlich) ausdefiniert wurde, dem Entwickler vorgelegt.

Während Tickets die Anforderungen festhalten und die Kommunikation zur Anforderung über diese läuft und festgehalten wird, dienen Wikis vorwiegend als Wissensbasis.

Im Entwicklungsalltag ermöglicht die Kombination dieser Systeme unterschiedlichste Arbeitsabläufe, welche dann auch über entsprechende Tickets abgebildet werden können. Auch die Arbeit mit Boards und ähnlichen Hilfsmitteln hilft es den Arbeitsablauf sinnvoll zu visualisieren.

Ein entsprechendes Board

Dabei kann mit unterschiedlichen Spalten wie Geplant, In Arbeit, Review, Test und Fertiggestellt gearbeitet werden. Eine Vertiefung würde an dieser Stelle den Rahmen des Artikels sprengen, da sie auf den Zusammenhang der Arbeitsabläufe mit dem Versionskontrollsystem konzentriert werden soll.

Versionskontrollsysteme

Versionskontrollsysteme bieten für die Entwicklung von Software unterschiedlichste Vorteile. Wie in der Einleitung kurz angerissen, kann die Entwicklung ohne solche Systeme in einer Mischung aus Chaos und Redundanz ausarten. Änderungen können verloren gehen und die Frage, was wurde von Stand A zu Stand B geändert kann nur schwer beantwortet werden.

Im Grunde definieren sich Versionskontrollsysteme über einige Eigenschaften: Protokollierung, Wiederherstellung, Archivierung, Koordinierung sowie die Bereitstellung von Entwicklungszweigen.

Aus Sicht der Arbeitsabläufe in einem Unternehmen ist die Eigenschaft der Koordinierung wichtig. Softwareentwicklung ist in den meisten Fällen Teamwork. Und so muss der Zugriff unterschiedlicher Personen auf den gleichen Quelltext gemanagt werden und entsprechende Methodiken zur Zusammenführung unterschiedlicher Arbeitsstände müssen bereitgestellt werden.

Natürlich kann auch in einem solchen Fall mit Ordnern und einem Netzlaufwerk gearbeitet werden, allerdings wird dies früher oder später zu Problemen führen. So könnten Mitglieder des Teams versuchen, die gleiche Datei des Projektes zu bearbeiten und somit eine Änderung eines Kollegen die Arbeit eines Anderen überschreiben.

Neben der Koordinierung ist die Bereitstellung von Entwicklungszweigen eine der wesentlichen Funktionalitäten von modernen Versionskontrollsystemen. Das bedeutet, dass es nicht nur eine Variante des Quellcodes existiert, sondern ein Repository, mit seinen Entwicklungszweigen, Branches genannt, eine Baumstruktur darstellt.

Unterschiedliche Branches in einem Repository bilden eine Baumstruktur

Mithilfe solcher Entwicklungszweige können z. B. Features entwickelt werden, ohne den aktuellen Hauptentwicklungszweig zu stören oder entsprechende Release- und Bugfix-Zweige verwaltet werden.

Branchen und Mergen

Heutige Versionskontrollsysteme kommen ohne einen zentralen Server aus und verfügen meist über einfachen Mechanismus zur Erstellung und der Zusammenführung von Entwicklungszweigen.

Dies sollte nicht als Kleinigkeit abgetan werden. Während dies bei althergebrachten Systemen wie Subversion und CVS zwar technisch möglich war, wurde dieses Feature dort praktisch nicht genutzt.

Bei Systemen wie Git gehören diese Features zu den Grundlagen, während es bei CVS, Subversion und Co. eher als Expertentätigkeit verstanden wurde. Damit wurde die Erstellung und Zusammenführung von Entwicklungszweigen etwas Natürliches. Niemand musste mehr, vor unauflösbaren Konflikten bei der Zusammenführung von Entwicklungszweigen, Angst haben.

Erst dadurch konnten bestimmte Arbeitsabläufe, welche intensiv von Entwicklungszweigen Gebrauch machten, in unsere heutige Entwicklungslandschaft einziehen.

Branches, Branches, Branches

Während der Entwicklung existiert meist ein main– bzw. master-Branch, welcher eine stabile Version enthält und der develop-Branch in welchem sich die Entwicklungsversion befindet.

Mithilfe von Entwicklungszweigen können unterschiedlichste Entwicklungsmodelle realisiert und Features relativ unabhängig voneinander entwickelt werden. Auch die Pflege unterschiedlicher Releases, welche mit Support bedacht werden müssen, ist mithilfe von Entwicklungszweigen möglich.

Neben Entwicklungszweigen existieren in Versionskontrollsystemen sogenannte Tags. Mit diesen können unter anderem Release-Versionen markiert werden und im späteren Verlauf schnell gefunden oder aber Entwicklungszweige vom entsprechenden Tag abgeleitet werden. Dies ist z. B. dann der Fall, wenn ein Bugfix auf einer älteren Release-Version entwickelt werden soll, für welche kein Release-Branch existiert.

Aus Sicht des Entwicklers ermöglichen Entwicklungszweige daneben das, was unter dem Begriff Commit early and often bekannt ist. In einem separaten Feature-Branch können Änderungen schnell festgeschrieben werden, ohne Rücksicht darauf nehmen zu müssen, ob die Änderung das Release in dieser Phase stören würden.

Namensgebung

Bei der Benennung von Entwicklungszweigen sollte nach einem festgelegten Schema gearbeitet werden, welches für den entsprechenden Arbeitsablauf definiert werden sollte.

Wird mit Ticketsystemen gearbeitet, so sollte die Ticketnummer im Branch enthalten sein. Bei Commits gilt das Gleiche für die entsprechende Nachricht, welche dem Commit beigefügt wird. Ticketsysteme nutzen diese Informationen, um zugehörige Entwicklungszweige und Commits direkt am Ticket anzuzeigen.

Je nach gewähltem Arbeitsablauf kann die Benennung aber auch einfach nur der Fachlichkeit geschuldet sein und muss auf keinerlei Ticket verweisen.

Bei der Benennung von Release-Entwicklungszweigen kann mit Zeitangaben oder Versionsangaben, je nach Erfordernis und Struktur der Releases gewählt werden. Ein solcher Entwicklungszweig könnte z. B. den Namen release/2022.04 tragen.

Feature- und Bugfix-Entwicklungszweige können entsprechend benannt werden. Ein Feature könnte dann z. B. so aussehen: feature/tiff-support oder wenn ein Ticket mit im Namen des Entwicklungszweiges kodiert werden soll: feature/id-1234-tiff-support. Bei Bugfixes kann genauso vorgegangen werden, z. B. bugfix/id-1235-header-corruption.

Pull Requests

Wünschenswert bei der Arbeit mit Ticketsystemen in Verbindung mit Versionskontrollsystemen ist die Verknüpfung miteinander. So können am entsprechenden Ticket bereits der zugeordnete Entwicklungszweig, die entsprechenden Commits sowie offene Pull Requests angezeigt werden.

Daneben bieten die Systeme die Möglichkeit, Entwicklungszweige über das Ticket anzulegen und Pull Requests zu erstellen und somit das Entwicklungsergebnis etwas effizienter zu gestalten.

Ein solcher Pull Request (auch als Merge Request bekannt) war ursprünglich eine Mail mit einem angehängten Patch und der Bitte um Integration. Der Entwickler mit einem Zugriff auf das Repository konnten diesen Pull Request dann akzeptieren und den entsprechenden Code zu integrieren.

Teilweise wird dies auch heutzutage noch so gehandhabt, wie bei der Entwicklung der Linux-Kernels.

Ein Pull Request unter GitHub

Im Rahmen der Arbeitsabläufe sind Pull Request, wie sie von den unterschiedlichen Systemen wie GitHub oder Bitbucket angeboten werden, ein probates Mittel Änderungen zu reviewen, Feedback zu geben und die Änderungen schlussendlich zusammenzuführen.

Daneben existieren Systeme wie Gerrit, welche komplexere Prozesse für die Integration des Quellcodes in das Repository ermöglichen. Hier können Änderungen kommentiert, diskutiert und abgestimmt werden.

Review und Test?

Einige Entwickler halten Review und Tests für optional. Das sollten sie allerdings niemals sein und dementsprechend auch in keinem Arbeitsablauf fehlen.

Es gibt unterschiedliche Gründe für die jeweiligen Verfahren. Beim Review geht es einmal darum, den Quellcode auf offensichtliche Schwachstellen und Fehler abzuklopfen. Macht der Quellcode das, was die fachliche Anforderung definiert? Werden Coding Guidelines eingehalten und gibt es entsprechende Unit-Test?

Neben den offensichtlichen Vorteilen durch das Review hat der Prozess noch anderen entscheidenden Vorteil. Er trägt zum Knowledge Sharing bei. Nach einem Review wurde eine Stelle im Quellcode bzw. eine Funktionalität nicht nur von einem, sondern von mindestens zwei Entwicklern gesehen und verstanden.

Innerhalb des Arbeitsablaufs lässt sich das Review beliebig gestalten. So kann es z. B. erforderlich sein, bei komplexen Änderungen mehrere Entwickler mit dem Review zu betrauen. In manchen Firmen wird eine Entwicklung im Pair Programming automatisch als gereviewter Code gesehen.

Auch der Test ist wichtig, um die Funktionalität abzusichern und eventuelle Fehler vor der Auslieferung abstellen zu können. Hier stellt sich natürlich die Frage, an welcher Stelle der entsprechende Test eingebaut werden kann und sollte.

Workflows

Nach diesen Vorbetrachtungen der meist technischen und organisatorischen Gegebenheiten können sich nun einzelne Arbeitsabläufe im Detail angeschaut werden.

Dabei wird im Grunde mehr oder weniger zwischen zwei Arten der Softwareentwicklung unterschieden. Einmal zwischen releasebasierten Arbeitsabläufen, bei denen auf ein Release hinaus entwickelt wird und einmal die kontinuierliche Entwicklung, bei der an einer Applikation entwickelt wird, welche keine klassischen Releases mehr kennt. Ein Beispiel für letzteres wäre eine Webapplikation, welche praktisch immer in der aktuellen Version ausgeliefert wird.

Diese Fragen entscheiden am Ende darüber, wie der jeweilige Workflow für das Team respektive das Produkt am Ende aussieht.

One branch to rule them all

Der einfachste Arbeitsablauf besteht sicherlich darin, einfach die entsprechenden Commits im main-Branch seines Projektes zu erstellen.

Alle Commits landen direkt im main-Branch

Bei diesem Arbeitsablauf mischen sich die Implementierungen unterschiedlicher Features und andere Dinge im schlimmsten Fall zu einem instabilen Gemisch. Features landen Stück für Stück im main-Branch und experimentelle Entwicklungen sind ebenfalls schwierig in diesem Model unterzubringen.

Auch ein Review und ein Test sind nur nachträglich möglich, wenn das Kind bereits in den Brunnen gefallen ist. Daneben stellt sich die Frage, wie definiert wird, dass der main-Branch stabil ist und ein entsprechendes Release erstellt werden kann.

Eine Aufgabe: ein Branch

Ein simpler Arbeitsablauf könnte nun so aussehen, dass für jede Änderung, sei es ein Feature, ein Bugfix oder etwas anderes ein Entwicklungszweig angelegt wird und dieser, wenn die Entwicklung abgeschlossen wurde, wieder mit dem Hauptzweig zusammengeführt wird.

Ein solcher Entwicklungszweig wird meist Ticket-Branch, Feature-Branch oder auch Topic-Branch genannt.

Jede Entwicklung findet in einem separaten Branch statt

Im Detail sind bei dieser Variante allerdings einige Fragen ungeklärt. Wann findet das Review statt, wann der Test? Wer gibt den Merge in den Hauptentwicklungszweig frei? Wann ist der main-Branch als stabil anzusehen?

Aus diesem simpleren Arbeitsablauf, bzw. der Idee des Branchings für einzelne Anforderungen ergeben sich in der Realität unterschiedlichste Arbeitsabläufe, von deinen einige im Detail vorgestellt werden sollen.

Entwicklungs- und stabile Linien

Bei diesem Arbeitsablauf wird mit zwei Entwicklungszweigen gearbeitet, einmal dem main-Branch und einmal dem develop-Branch. Soll eine neue Entwicklung stattfinden, so wird ein Entwicklungszweig basierend auf dem develop-Branch erstellt und auf diesem das entsprechende Feature entwickelt.

Der main-Branch enthält die stabile Variante der Software dar

Ist die Entwicklung abgeschlossen, kann ein Pull Request erstellt werden, welcher als Ziel den develop-Branch trägt. Im Rahmen des Pull Requests kann der Reviewer den Quellcode reviewen und entsprechende Anmerkungen antragen. Der Entwickler kann entsprechende Änderungen, welche sich aus dem Review ergeben, im Feature-Branch vornehmen.

Ist das Review erfolgreich abgeschlossen, so könnte die Änderung vor der Zusammenführung der Entwicklungszweige oder danach getestet werden. Wird im Feature-Branch getestet, so sollte anschließend auch im develop-Branch getestet werden, um die erfolgreiche Integration des Features sicherzustellen. Hier bietet sich ein Modell an, nur besonders kritische Änderungen vor und nach dem Merge zu testen, während gewöhnliche Änderungen nur nach der Zusammenführung der Entwicklungszweige getestet werden.

Im Falle von Fehlern, welche im Test gefunden werden, sollten diese im Feature-Branch behoben werden und anschließend wieder ein Pull Request erstellt werden.

Der develop-Branch wird regelmäßig, immer dann, wenn er für stabil befunden wird, in den main-Branch gemergt, sodass dieser in der Theorie eine stabile Version der Software enthält.

Natürlich kann nicht wirklich sichergestellt werden, dass die entsprechende Version stabil ist und auch das Arbeiten mit mehreren Releases ist mit einem solchen Workflow nicht praktikabel möglich.

Der Vorteil, der sich aus dieser Vorgehensweise ergibt, ist, dass der main-Branch immer relativ stabil bleibt, da nur getestete Änderungen in ihn wandern. Außerdem können mehrere Features parallel entwickelt werden.

Auch können Tags hier wieder genutzt werden, um Releases zu definieren und für spätere Änderungen verfügbar zu halten.

Releases aus dem main-Branch

Eine andere Variante ist es, direkt auf dem main-Branch zu arbeiten. Hier kann optional mit Feature-Branches gearbeitet werden.

Für ein nahendes Release wird nun vom main-Branch ein Release-Branch angelegt und dieser entsprechend stabilisiert; bis das Release schlussendlich ausgeliefert werden kann.

Nachteilig ist hier, dass nicht wirklich mit parallel mit Releases gearbeitet werden kann. Auch die Sicherstellung, dass ein bestimmtes Feature in einem bestimmten Release landet, ist nur mit größerem Aufwand zu realisieren.

Neue Releases werden aus dem main-Branch abgeleitet

Während der Stabilisierungsphase im Release besteht, daneben das Problem, dass entsprechende Bugfixes auch in den main-Branch übernommen werden müssen und dies einen zusätzlichen Aufwand bedeutet. Daneben nehmen die Stabilisierungsphasen größere Zeiträume ein und verhindern somit die eigentliche Weiterentwicklung der Software.

Von Release zu Release

Soll mit mehreren Releases gearbeitet werden, so kann ein Arbeitsablauf gewählt werden, welcher unabhängig vom main-Branch ist und stattdessen nur noch aus Release-Branches besteht.

Release-Branches werden nach oben gemergt

In diesem Modell wird für jedes Release ein Entwicklungszweig angelegt. Wenn die Software z. B. monatlich deployt wird, könnten die entsprechenden Branches wie folgt aussehen: release/2022.04, release/2022.05, release/2022.06 usw.

Jede Anforderung wird nun einem Release zugeordnet. Wird ein Feature entwickelt, so wird ein Feature-Branch vom entsprechenden Release-Branch gezogen und auf diesem Feature-Branch die Entwicklung durchgeführt.

Wird das Feature rechtzeitig zum Release fertig entwickelt, wird es im Rahmen des Prozesses (Review, Test) mit dem Release-Branch zusammengeführt.

Kann ein Feature nicht zum zugeordneten Release fertiggestellt werden, wird das zugeordnete Release im Ticket geändert und der Feature-Branch auf Basis der neuen Release-Version fertiggestellt.

Hierzu wird der neu zugeordnete Release-Branch in den Feature-Branch gemergt und anschließend mit der Entwicklung fortgefahren.

Der Feature-Branch kann auch zwischenzeitlich mit dem zugeordneten Release-Branch aktualisiert werden, sodass die eventuellen Änderungen des Release-Branches sich auch im Feature-Branch niederschlagen.

Die Release-Branches selber werden regelmäßig bzw. automatisch von den älteren zu den neueren Branches gemergt. Damit sind Änderungen, welche einem älteren Release zugeordnet waren, automatisch in den neueren Releases enthalten.

Vorteilig an diesem Entwicklungsmodell ist, dass parallel an mehreren Releases gearbeitet werden kann und Verschiebungen von Features im Rahmen der Entwicklung aus technischer Sicht kein Problem darstellen.

Auch können alte Releases bei diesem Arbeitsablauf problemlos über einen längeren Zeitraum betreut werden und mit Bugfixes versehen werden. Diese Bugfixes landen durch den Merge-Prozess der Release-Branches untereinander immer wieder in den neueren Releases.

Bei der Arbeit mit den einzelnen Releases kann die Arbeit noch in Entwicklungs- und Stabilisierungsphasen unterteilt werden, um möglichst stabile und getestete Releases abzuliefern.

Dabei werden neue Features nur innerhalb der Entwicklungsphase in den entsprechenden Release-Branch gemergt. Ist diese Phase ausgelaufen, wird das zugeordnete Release in der Anforderung respektive dem Ticket auf das nächste Release verschoben.

In der Stabilisierungsphase werden nur noch Bugfixes durchgeführt, welche zur Stabilisierung des Releases beitragen.

Git Flow

Ein weiteres relativ beliebtes Modell ist der Arbeitsablauf Git Flow, welcher von Vincent Driessen erdacht wurde und sich neben der guten Skalierbarkeit auch durch seine Vorteile in der Zusammenarbeit auszeichnet.

Git Flow zielt hauptsächlich auf Software ab, bei welcher mehrere Versionen parallel unterstützt werden müssen und sollte nicht als Allheilmittel betrachtet werden, wie der Entwickler selbst schreibt:

This model was conceived in 2010 […] In those 10 years, git-flow […] has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

Das Regelwerk, welches hinter diesem Arbeitsablauf steht, wirkt auf den ersten Blick wesentlich komplizierter als das anderer Arbeitsabläufe. Das beginnt damit, dass mit unterschiedlichsten Entwicklungszweigen gearbeitet wird. So existieren in diesem Flow die Branches main, develop und separate Branches für Features, Hotfixes und Releases.

Bei Git Flow existieren eine Reihe von Branchtypen

Im Rahmen des Arbeitsablaufs ist geregelt, aus welchen Entwicklungszweigen weitere Entwicklungszweige erstellt werden sollen und wie und in welche Richtung die jeweiligen Zweige zusammengeführt werden dürfen.

Auch wird in diesem Modell gewünscht, dass Feature-Branches nur lokal beim Entwickler liegen und nicht zum zentralen Server hochgeladen werden.

Grundsätzlich wird bei Git Flow mit Feature-Branches gearbeitet, welche auf dem develop-Branch basieren. Aus diesem Branch wiederum werden entsprechende Release-Branches gezogen.

Ist ein Release veröffentlicht, werden eventuelle Bugfixes, über entsprechende Bugfix-Branches basierend auf dem Release-Branch erstellt und dort der Bugfix entwickelt.

Release-Branches werden in den main-Branch gemergt und im Falle von Änderungen des Release-Branches auch in den develop-Branch.

Sollte ein Hotfix notwendig sein, so wird dieses auf Basis des main-Branches in einem Hotfix-Branch entwickelt und anschließend wieder in den main-Branch und in den develop-Branch eingepflegt.

GitHub Flow

Ein weiterer bekannter Arbeitsablauf ist der GitHub Flow. Bei diesem wird davon ausgegangen, dass der main-Branch grundsätzlich immer deploybar ist.

Bei einer neuen Entwicklung wird ein Entwicklungszweig basierend auf dem main-Branch erstellt und ein entsprechender beschreibender Name benutzt, z. B. tiff-support und auf diesem Entwicklungszweig entwickelt.

Ist die Entwicklung so weit abgeschlossen, dass der Entwicklungszweig in den main-Branch eingepflegt werden kann, wird ein Pull Request erstellt und der Reviewer kann sich diesen anschauen und anschließend den Merge durchführen.

Daneben dienen Pull Requests in diesem Arbeitsablauf der allgemeinen Klärung, so können Pull Requests auch erstellt werden, wenn Feedback oder andere Hilfe benötigt wird.

Damit ist das Verfahren ähnlich dem Arbeitsablauf, bei welchem für jede Entwicklung ein eigener Entwicklungszweig erstellt und dieser wieder eingepflegt wird. Im Gegensatz zum obigen Arbeitsablauf definiert der GitHub Flow einige Rahmenbedingungen genauer und sieht weitere Schritte nach dem einpflegen des Zweiges vor.

Hier fordert der Arbeitsablauf ein, dass nach der Zusammenführung der Entwicklungszweige der aktuelle Stand des main-Branches sogleich deployt wird. Hintergrund ist hier, dass damit das Verständnis geschaffen wird, dass wenn die eigenen Code-Änderungen nicht stabil sind, das System bricht. Und aus diesem Grund die Entwickler besondere Sorgfalt darauf legen (sollten) wirklich stabile Änderungen einzubringen.

Trunk Flows

Neben diesen branchbasierten Workflows werden in letzter Zeit vermehrt sogenannte trunk-basierte Flows genutzt.

Bei diesem Arbeitsablauf soll möglichst darauf verzichtet werden, langlebige Entwicklungszweige zu halten. Damit sollen unter anderem mögliche Merge-Konflikte verhindert werden. Stattdessen sollen Commits hier direkt im trunk; im Fall von Git also im main-Branch, erstellt werden.

Die Commits sind bei diesem Verfahren erfahrungsgemäß eher klein. Außerdem hat der Entwickler sicherzustellen, dass der Build ordnungsgemäß funktioniert, bevor er den Commit zum Server hochlädt.

Für Reviews können kurzlebige Entwicklungszweige angelegt werden und entsprechend für Pull Requests und das anschließende einpflegen in den main-Branch genutzt werden.

Schleicht sich dennoch ein Fehler ein, so wird der Commit auf dem main-Branch zurückgerollt.

Continuous Integration-Systeme spielen in diesem Prozess eine wichtige Rolle, indem sie bei Änderungen sofort entsprechende Tests durchführen und den Entwickler informieren, wenn der Build nicht den Anforderungen an die geforderte Qualität entspricht.

Je nach Konfiguration rollen die Continuous Integration-Systeme die problematischen Commits automatisch zurück.

Diese durchgeführten automatisierten Tests, sowie Code-Reviews sollen sicherstellen, dass der main-Branch immer deploybar ist; vergleichbar zu dem GitHub Flow.

Wenn der Test fehlschlägt

Egal in welchem Arbeitsablauf, stellt sich immer die Frage, wie mit Features umgegangen wird, die sich bereits im main-, develop– oder release-Branch befinden und Fehler festgestellt wurden.

Grundsätzlich sollte hier die Entwicklung wieder aufgenommen und der Fehler beseitigt werden. Je nach Arbeitsablauf kann diese Entwicklung im Feature-Branch erfolgen oder z. B. direkt im main-Branch gearbeitet werden.

Problematisch wird es an der Stelle, wenn das Feature bereits gemergt ist, es zeitlich aber nicht mehr realistisch ist, etwaige Fehler bis zum Release zu beseitigen.

In einem solchen Fall existieren unterschiedliche Möglichkeiten. So kann unter anderem mit Feature-Flags gearbeitet werden, welche es ermöglichen das entsprechende Feature abzuschalten.

Je nach verwendeter Programmiersprache können hier Möglichkeiten der jeweiligen Sprache bzw. des jeweiligen Toolings benutzt werden. Unter Rust könnte z. B. über Cargo ein entsprechendes Feature definiert sein und dieses im Fehlerfall wieder abgeschaltet werden.

Feature-Flags werden auch bei trunk-basierenden Workflows als Ergänzung gesehen, um das Feature langsam zu entwickeln. Allerdings stellt sich hierbei die Frage nach der Testbarkeit solange das Feature-Flag noch nicht aktiv ist.

In der Praxis ist es nicht immer möglich, mit solchen Feature-Flags zu arbeiten. In einem solchen Fall können die entsprechenden Commits rückgängig gemacht werden und somit aus dem entsprechenden Branch, welcher zum Release führt, entfernt werden.

Einfacher ist ein solcher Revert, wenn die Änderungen aus einem Feature-Branch per Squash zu einem einzelnen Commit zusammengeführt werden und erst dann gemergt werden.

Damit tauchen die kompletten Änderungen eines solches Feature-Branches nur noch als ein einzelner Commit, im Branch in den die Änderung eingepflegt wird, auf. Positiv wirkt sich dies auch auf die Übersichtlichkeit in diesem Branch aus. Allerdings bedeutet es je nach Automatisierungsgrad des Arbeitsablaufs zusätzlichen Aufwand.

Merge-Hölle?

Bei vielen der oben beschriebenen Arbeitsabläufe wird mit Entwicklungszweigen gearbeitet. Damit mit diesen gearbeitet werden kann, müssen sie schlussendlich in ihre Zielzweige eingepflegt werden.

Bei der Zusammenführung zweier Entwicklungszweige können entsprechende Probleme auftreten, dass zwei Änderungen nicht mehr zusammenpassen. Ein solcher Merge-Konflikt muss behoben werden, um die entsprechende Zusammenführung der Entwicklungszweige erfolgreich abzuschließen.

Meist ist die Behebung solcher Konflikte trivial. Um die Gefahr für solche Konflikte zu verhindert, hilft es Anforderungen und damit verbundene Code-Änderungen klein zuhalten.

Auch Coding Guidelines helfen solche Probleme zu minimieren, da sie dafür sorgen, dass die Formatierungen über das Projekt und die beteiligten Entwickler identisch sind. Damit können entsprechende Probleme wegen unterschiedlichen Einzugsbreiten und Ähnlichem gar nicht erst auftreten.

Merges sind nichts, wovor Entwickler Angst haben sollten. Sie gehören zum Tagesgeschäft dazu und verlaufen in einem Großteil der Fälle problemlos ab und Konflikte können auch dank des Toolings schnell gelöst werden.

Fazit

Arbeitsabläufe gibt es viele und im Grunde hängt der genutzte Arbeitsablauf vom Team, dem Projekt und den damit verbundenen Anforderungen ab. Den einen richtigen Arbeitsablauf gibt es nicht.

Vor allem im agilen Kontext, sollte jedes Team für sich entscheiden, mit welchem Arbeitsablauf es arbeitet und diesen an die eigenen Gegebenheiten und Besonderheiten anpassen.

Wichtig ist, dass die Arbeitsabläufe die Entwicklung nicht behindern oder erschweren, sondern ein Gerüst bieten, damit die Anforderungen der Entwickler, Produktmanager und Kunden schnell abgebildet und sinnvoll umgesetzt werden können und ein stabiles Produkt ausgeliefert werden kann.

Aus Sicht des Autors bietet sich der Release zu Release-Workflow in den meisten Fällen eines releasebasierten Produktes an, da er viele Vorteile bietet; bei relativ geringem Aufwand.

Zudem hängt viel davon ab, was für ein Produkt entwickelt wird und wie die Release-Zyklen aussehen. So ist es auch nicht ungewöhnlich Services regelmäßig z. B. täglich oder sogar mehrmals täglich zu deployen. In solchen Fällen sind Arbeitsabläufe wie der Github Flow sinnvoller zu nutzen.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Diese Person existiert nicht

Neuronale Netze und Deep Learning sind aus unserer heutigen Welt nicht mehr wegzudenken. Auf der Webseite This Person Does Not Exist welche auf Generative Adversarial Networks basiert, kann sich angeschaut werden, was diese Netzwerke unter anderem leisten können. Die Webseite generiert Fotos von Menschen, die in der Realität nicht gelebt haben.

Auch wenn es aussieht wie eine Fotografie, ist es keine

Zu finden ist die Seite unter thispersondoesnotexist.com. Dort sind auch entsprechende Verlinkungen zu finden zu anderen Generatoren von Katzenbildern bis hin zu Chemikalien. Der entsprechende Quellcode für das Netzwerk bzw. der Trainingsumgebung ist auf GitHub zu finden. Lizenziert ist das Ganze unter der Nvidia Source Code License und damit leider keine Freie Software.