|
Bei unserer Firmware-Entwicklung wird ein hoher Anspruch an einen stabilen Betrieb gestellt. Wir pflegen zwei verschiedene stabile Versionen, eine ältere, sie wird selten aktualisiert und eine neue, die üblicherweise im Netzwerk verwendet wird. Die ältere bezeichnen wir als "Rock Solid".
Versionen
Stabile Versionen
Stable
Diese Version ist der Auslieferungszustand und die Version die wir in unserem Download-Bereich zur Verfügung stellen.
Stabile Versionen, sowie Stage1 und Stage2-Versionen haben keine führenden Buchstaben (Beispiel 0.1.2).
Rock Solid
Diese ältere und bewährte Stabile Version wird vorzugsweise auf Geräten installiert die nur die absolut notwendigen Updates bekommen sollen, um mögliche Fehler die durch eine Aktualisierung ausgelöst werden können, zu vermeiden. Diese Version eignet sich besonders für Out-Door-Router und Router die an schwer zugänglichen Stellen positioniert sind, oder wo der Zugang nur selten möglich ist.
Rock Solid Versionen beginnen immer mit einem "rs" vor der Versionsnummer (Beispiel rs0.1.18).
Entwicklungs-Versionen
Die Entwicklung von neuen Versionen findet in Zyklen statt. Wie bei dem Linux-Kernel verwenden wir ein Merge-Window. Neue Features werden als Pull-Request eines Lokal- oder Remote-Branches auf den Master eingereicht. Ist das Merge-Window abgelaufen werden die offenen Pull-Requests die bis zu diesem Zeitpunkt eingetroffen sind noch abgearbeitet, alle folgenden verschieben sich bis zum nächsten Merge-Window. Der Wechsel auf die neue Versionsnummer ist immer Nightly 0 (Beispiel n0.1.0).
Um zu verhindern das mehrere neue Funktionen auf einmal getestet werden, erstellt der Entwickler, der neuen Code für den Projekt-Master zur Verfügung stellt, einen Pull-Request von seinen Änderungen zum Master.
Daraufhin kann er an einem weiteren Feature die Arbeit beginnen und ein zweiter Entwickler kann zeitgleich eine Überprüfung seiner Arbeit abschließen.
Der zweite Entwickler, der den Code in das Projekt übernehmen möchte, überprüft den Quellcode auf Funktionalität, Form und Konsistenz - hat er seine Arbeit beendet nimmt er selbst den Pull-Request an. Anderenfalls verwirft er diesen mit einem entsprechenden Kommentar.
Nightly
Zwischen jedem Merge der Pull-Requests wird eine Nightly erstellt um Fehler besser einkreisen zu können. Der Versionsnummer einer Nightly wird ein "n" vorgestellt und sie werden einfach nach dem zweiten Punkt durchnummeriert (Beispiel n0.1.34, n0.1.35). Bei einem Feature-Sprung wird meist auf eine neue OpenWRT-Version gesprungen. Hier wird vornehmlich der letzte Trunk verwendet, diese Änderung ist immer Nightly 1 (Beispiel n0.1.1).
Alpha
Mit einem Sprung auf eine neue OpenWRT-Version muss sichergestellt werden, dass jede im Umlauf befindliche Hardware einen stabilen Betrieb gewährleistet. Daher wird diese Version erst als ausreichend getestet angesehen sobald alle unterstützten Geräte und deren Versionen funktionale Tests erfolgreich absolviert haben.
Für jedes Gerät und deren Version haben wir einen zuständigen Tester in unserem Datenbank-System hinterlegt. Bei der Erstellung der ersten Alpha-Version wird dieser Tester automatisch benachrichtigt, dass sein Gerät nun eine neue Alpha-Version ausgeliefert bekommt. Sobald sich der Nutzer zurückmeldet, dass seine Hardware funktional einwandfrei ist, wird diese Hardware als stabil angesehen.
Alle bei der Hardware auftretenden Fehler werden erst im Upstream behoben und der Patch bei uns importiert. Danach wird eine neue Alpha-Version erstellt und diese durchläuft erneut die Test-Geräte.
Mit der Alpha-Version beginnt eine durchgängige, stabile Nummerierung von Versionen. Ist die Alpha-Version als fehlerfrei durch den Test-Prozess des Teams gegangen, wird mit der selben Versionsnummer und vorgestelltem "b" an externe Tester verteilt (Beispiel a0.1.5 wird zu b0.1.5).
Beta
Nachdem die Hardware und die Software grundlegend getestet wurde, verteilen wir die neue Firmware an einige Geräte von Personen die angegeben haben, das dieses Gerät für den Beta-Einsatz verfügbar ist. Wir benachrichtigen diese Personen und warten auf einen größeren Anteil von positiven Rückmeldungen, dass keine funktionalen Probleme mit unserer Software aufgetreten sind.
Haben die Tester die Beta über den Testzeitraum auf Fehler überprüft wird aus der b0.1.5 nun die stabile Version 0.1.5.
Stage1
Die lokalen Ansprechpartner der Community legen fest welche Geräte Stage1-Versionen erhalten. Kriterien sind hier das die Betreiber technisch versiert sind und die Nodes keine kritischen Punkte in der Infrastruktur des Netzes darstellen (beispielsweise einzelner Uplink für großes Mesh).
Der Webserver der unsere Aktualisierungen verteilt sendet nun bei der Anfrage dieser Geräte ein Update an sie aus.
Hier warten wir auf negative Rückmeldungen 7 Tage lang. Trifft keine ein, gehen wir über zu Phase Stage2.
Stage2
Wenn die Phase Stage1 abgeschlossen ist, wählt unser Aktualisierungsserver automatisch einen Teil der Nodes aus und sendet ihnen nun die neue stabile Version. Wir wollen hiermit ausschließen das mit einem bisher unerkannten Fehler ganze Teile eines Netzwerks ausfallen. Wir beobachten die aktualisierten Geräte. Wenn hier weitere 2 Tage keine Probleme auftreten ist diese Phase abgeschlossen und der Rest des Netzwerks wird aktualisiert.
Entwicklungsdetails
Git
|
