Check_MK-Versionen

Letzte Aktualisierung: 15. Februar 2017


1. Der Entwicklungszyklus

Ein Zyklus von einer stabilen Check_MK-Version bis zur nächsten umfasst circa eineinhalb Jahre. Es beginnt damit, dass nach dem Release der Vorgängerversion (z. B. 1.2.8) mit dem Entwickeln der neuen Features für die kommende Version (z. B. 1.4.0) begonnen wird. Die Entwicklung findet auf dem Hauptentwicklungszweig (master) statt.

Nach etwa 6-9 Monaten wird die erste Innovation-Version erstellt, welche in einem einem eigenen Zweig für eine kurze Zeit gepflegt wird.

Nach zwei bis vier Innovation-Versionen beginnt die Betaphase. Auch für diese wird ein Zweig abgespaltet, auf welchem die stabile Version finalisiert und später gepflegt wird. Auf dem Hauptzweig beginnt dann schon wieder die Vorbereitung für den nächsten Zyklus.

Sowohl auf dem Hauptentwicklungszweig als auch auf dem stabilen Zweig gibt es tägliche Zwischen­versionen (GIT-Snapshots), welche Ihnen einen schnellen Zugriff auf neue Features oder Bugfixes bieten. Grafisch dargestellt sieht das Ganze etwa so aus:

2. Verschiedene Versionen im Detail

2.1. Tagesversionen vom Master (Daily builds)

Auf dem Entwicklungszweig (in der Versionskontrolle GIT heißt dieser „master“) wird die Zukunft von Check_MK entwickelt. Damit Entwickler, Anwender und andere Interessierte sich jederzeit ein Bild vom aktuellen Stand der Software machen können, wird jeden Tag zwischen 0:00 und 6:00 Uhr mitteleuropäischer Zeit ein Installationspaket für alle unterstützten Linux-Distributionen gebaut. Diese Pakete werden auch Daily builds, GIT-Snapshots oder Entwicklerversionen genannt und stellen den exakten Stand der Softwareentwicklung zu Beginn eines jeden Tages dar.

Die Tagesversionen sind natürlich oft fehlerbehaftet, da sie quasi einen mehr oder weniger „zufälligen“ Stand der Software enthalten. Im Gegensatz zu stabilen und Innovation-Versionen eröffenen Tagesversionen auch keinen neuen Entwicklungszweig und können daher auch nicht von uns gepatcht werden. Die einzige Möglichkeit einen Fehler in einer Tagesversion zu beheben, ist das Einspielen einer neueren Tagesversion, bei der dieser Fehler behoben ist. Leider kann dabei natürlich wieder ein neuer, anderer Fehler hineingeraten. Daher sollten Sie Tagesversionen niemals produkiv einsetzen.

Trotzdem sind die Daily Builds sehr nützlich, wenn Sie neue Features zeitnah ausprobieren möchten. Dies gilt insbesondere dann, wenn Sie diese Features selbst bei uns in Auftrag gegeben haben!

Unser Support hilft Ihnen auch gerne bei Schwierigkeiten mit Tagesversionen, allerdings mit folgenden Einschränkungen:

  • Wir können Ihnen nur helfen, wenn Ihre Tagesversion nicht älter als eine Woche ist.
  • Wir können keine Patches erstellen.
  • Tagesversionen sind nicht vom Break/Fix-Support abgedeckt.

2.2. Die Betaphase

Das Release einer neuen stabilen Version (z. B. 1.4.0) beginnt mit einer Betaphase. Um alle Fehler zu beheben und die Software tauglich für die Produktion zu machen, wird dazu ein stabiler Zweig abgespalten, welcher nur noch Fehlerbehebungen enthält. Auf dem Hauptzweig geht parallel die Entwicklung der Features für die Zukunft weiter.

Auf dem stabilen Zweig wird nun eine Serie von Betaversionen mit einem kleinen b im Namen veröffentlicht - (z. B. 1.4.0b1, 1.4.0b2, usw.). Das geschieht etwa alle zwei Wochen – solange bis keine gravierenden Fehler mehr bekannt sind.

2.3. Aktive Pflege der stabilen Version

Nach der Betaphase gibt es den feierlichen Augenblick, an dem die neue stabile Version erscheint (z. B. 1.4.0). Da die Software nun von einer viel breiteren Schicht von Benutzern eingesetzt wird, werden jetzt in der Regel noch Probleme bekannt, die während der Betaphase nicht aufgefallen sind. Diese werden in einer Reihe von Patchreleases behoben (1.4.0p1, 1.4.0p2, usw.). Die Abstände dieser Releases sind anfangs recht kurz (etwa eine Woche) und später viel länger (einige Monate). Der stabile Zweig wird etwa 1,5 Jahre von uns aktiv in Form von Patchreleases gepflegt.

Auch auf dem stabilen Zweig werden Tagesversionen veröffentlicht, welche Ihnen Bugfixes zeitnah bereitstellen. Diese tragen den Namen des Zweigs plus das Datum, z. B. 1.4.0-2017.04.08.

Sie können diese Versionen produktiv einsetzen, solange Sie folgendes beachten:

  • Setzen Sie eine stabile Tagesversionen nur dann ein, wenn sie ein für Sie gravierendes Problem behebt.
  • Aktualisieren Sie auf die nächste Patchversion, sobald diese erscheint.

2.4. Passive Pflege

Nach Ablauf der aktiven Pflege geht der stabile Zweig in eine passive Pflege über, welche in der Regel weitere 1,5 Jahre dauert. Während dieser Zeit beheben wir Fehler nur noch im Auftrag von Kunden, die uns diese im Rahmen eines Supportvertrags in Form von Supporttickets melden. Falls Sie einen Vertrag mit Break/Fix-Option haben, sind solche Fehlerbehebungen darin enthalten.

Bugfixes während der passiven Pflege lösen weitere Patchreleases aus, von denen dann natürlich auch diejenigen Anwender profitieren, welche keinen Supportvertrag haben.

2.5. Support danach

Nach Ablauf der passiven Pflege werden keine Releases mehr erstellt. Kunden, die auf das Verwenden einer so alten Version angewiesen sind und einen Supportvertrag haben, können auch dann noch Hilfe von uns bekommen. Eventuelle Fehler können dann allerdings nur noch durch das Modifizieren von Dateien auf dem Kundensystem behoben werden. Dies ist natürlich sehr aufwendig und dementsprechend teurer. Auch sind diese Aktionen nicht vom Break/Fix-Support abgedeckt.

2.6. Innovation-Versionen

Innovation-Versionen sind ein besonderes Feature der  Check_MK Enterprise Edition und geben Ihnen die Möglichkeit, neue interessante Features der Software bereits lange vor der nächsten stabilen Version zu nutzen. Sie stellen einen Kompromiss zwischen Stabilität und Innovation dar.

Die erste Innovation-Version gibt es in der Regel ein halbes Jahr nach dem letzten stabilen Release. In einer Abfolge von 1-2 Monaten erscheinen 3-4 Releases, welche jeweils mit dem Kürzel i numeriert sind (z. B. 1.4.0i2). Ähnlich wie stabile Versionen werden auch diese aktiv gepflegt – allerdings nur eine begrenzte Zeit von 1-2 Monaten, an die sich eine ebensolange passive Pflege anschließt. Patches von i-Versionen erkennen Sie an einem p-Suffix, z. B. 1.4.0i2p1.

Innovation-Versionen sind nicht vom Break/Fix-Support abgedeckt.

2.7. Die Editionen und ihre Suffixe

Wenn Sie die Version einer Check_MK-Instanz mit dem Befehl omd version anzeigen, sehen Sie noch ein Suffix, welches aus Sicht von OMD Teil der Versionsnummer ist:

OMD[mysite]:~$ omd version
OMD - Open Monitoring Distribution Version 1.4.0p2.cre

Dieses Suffix dient dazu, gleiche Versionen von verschiedenen Check_MK-Editionen zu unterscheiden. Auf diese Art ist es kein Problem, z. B. gleichzeitig die Version 1.4.0p2 von der  Check_MK Raw Edition und der  Check_MK Enterprise Edition installiert zu haben. Dies ist manchmal sogar sehr sinnvoll – nämlich wenn Sie von der CRE auf die CEE umsteigen möchten. Folgende Suffixe sind möglich:

.cre  Check_MK Raw Edition
.cee  Check_MK Enterprise Edition
.demo Demo-Version der  Check_MK Enterprise Edition
.cme Check_MK Managed Services Edition (ab Mitte 2017)