Software-Entwicklung erfolgt üblicherweise mit semantischer Versionierung, doch größere Updates bekommen häufig Code-Namen. Android benennt seine jährlichen Releases zum Beispiel nach Süßigkeiten: aktuell sind sie bei O wie Oreo. Wir sind die Giant Monkey Software Engineering GmbH und haben uns daher entschieden, berühmte Affen als Code-Namen zu verwenden. Den Anfang hat nun Curious George gemacht, auch wenn er in der deutschen Übersetzung „Coco“ heißt. Wir haben vom Just-in-time-Deployment auf einen monatlichen Release-Zyklus umgestellt und haben mit dem ersten Release gleich zwei spannende Dinge eingeführt:
- den neuen monatlichen Release-Zyklus
- ein komplett neues Layout (V4)
Monatlicher Release Cycle
Im September haben wir ein neues, monatliches Release-Modell eingeführt. Jedes Release hat eine Interne Nummer (2017/08) und einen Code-Namen.
Für unser erstes Release haben wir uns für Curious George entschieden. Hauptsächlich wegen „Curious“ – denn wir wollen unsere Anwender neugierig machen.
neugierig
Curious George bringt ein komplett neu gestaltetes Layout mit sich. Das Layout V4. Um die Anwender jedoch nicht damit zu überfallen, gibt es in der Sidebar einen Schalter, mit dem jeder User selbst entscheiden kann, ob er V4 oder das aktuelle (V3) Layout nutzen möchte.
Jeder User kann jederzeit zwischen den beiden Layouts umschalten, um zu sehen, wie sich was verändert. Und wer ist nicht neugierig darauf, einen neuen Button zu drücken, der einen magischen Zauberstab als Icon hat und die verheißungsvollen Aufschrift „Layout V4“ trägt‽
Mehr zum neuen Layout erfahren
wissbegierig
Auch als „wissbegierig“ lässt sich „curious“ übersetzen. Daher starten wir mit dem neuen Release-Cycle auch eine neue Kommunikationsstrategie für die jeweiligen Releases. Zunächst bekommen die Projekt-Manager unserer Kunden einen Newsletter, wenn das neue Release in Staging zur Verfügung steht. Wir erklären im Changelog die neuen Features und ggf. Bugfixes. 2 Wochen später erfolgt das Production-Rollout und wir informieren alle User über die aktuellen Änderungen.
seltsam
In der Vergangenheit haben wir ein Continuous Delivery Modell mit Just-in-time-Deployments verfolgt. Dabei wurden stetig neue Features „ausgeliefert“. Auch wenn dieses Vorgehen für ein agiles Entwickler-Team besonders komfortabel ist, erhöht sich dadurch jedoch der Support-Aufwand, weil nicht alle Kunden den gleichen Feature-Stand haben. Durch das neue monatliche Deployment sind immer alle Kunden mit einem laufenden Wartungsvertrag auf dem gleichen Stand. Da wir jedoch über Jahre das Continuous Delivery verfolgt haben, „fühlt“ sich das monatliche Deployment irgendwie „seltsam“ an. Es ist natürlich immer noch Continuous Delivery – aber nicht mehr just-in-time – sondern monatlich konzertiert.
Innerhalb von vier Wochen wird das zunächst auf Staging installierte Release getestet und Fehlerbehebungen erhalten ein „Backport“. Das fehlerfreie Release wird dann einen Monat später in Production installiert. Parallel wird bereits an der nächsten Version gearbeitet. Durch diesen monatlichen Release-Zyklus ist die Entwicklungsarbeit geradliniger und der Kommunikationsaufwand mit unseren Kunden reduziert sich, da alle Kunden mit Wartungsvertrag nun auf einheitliche Releases fahren.
komisch
Im Sinne von: „ich finde das komisch, aber nicht lustig“ beschrieb ein Kunde einmal, dass der Screenshot in der Dokumentation sich von dem Bild auf seinem Bildschirm unterschied. Durch das monatliche Release haben wir jetzt auch die Möglichkeit, die Dokumentation zum Production-Release zu aktualisieren.
Release-Notes
Neben dem bereits beschriebenen neuen Layout haben wir aber auch in diesem Release eine Menge an neuen Funktionen für go~mus implementiert. Hier eine Übersicht der Änderungen im August Release:
Kassensynchronisation
Die Synchronisation zu Kassensystemen wurde in den nutzerseitig konfigurierbaren Bereich verschoben. So haben berechtigte Nutzer größeren Einfluss auf die Kategorisierung und Platzierung der Artikel im Kassensystem.
Neue Konstanten
Es wurden zwei neue Konstanten eingeführt, Anreden und Titel. Diese garantieren größere Datenintegrität und geringeren Aufwand in der Erstellung von Kundendatensätzen.
API – Ticketsichtbarkeit im Kontext von Kassen- und Resellerverkauf
Tickets sind über die API für Kasse und Wiederverkäufer nun auch sichtbar, ohne dass der Haken bei der Checkbox „über öffentliche API sichtbar“ gesetzt werden muss.
Bestellungen – Änderungen am Bestellexport, Änderungen am Ticketverkaufsexport
Die Exporte zu Bestellungen und Ticketverkäufen wurden um zusätzliche Spalten (Email-Adresse des Empfängers, Bezahlart, Kostenstellen, Ursprung) ergänzt.
Korrektur und Ergänzung einzelner Bezeichner, Übersetzungen und Fehlermeldungen
Für einzelne Attribute in go~mus fehlten in der Vergangenheit Bezeichnungen, Übersetzungen oder Fehlermeldungen oder diese waren inkonsistent. Die fehlenden Bezeichnungen, Übersetzungen oder Fehlermeldungen wurden ergänzt. Inkonsistente Bezeichner wurden aufgeräumt.
Angebotskalender – Suche mit Mindestteilnehmerzahl
Beim Buchen über den Monatskalender und Dispositionskalender für Angebote mit einer Mindestteilnehmerzahl ungleich eins traten in der Vergangenheit Fehler auf, da dieser immer mit der Teilnehmerzahl eins suchte und so für Angebote deren Mindestteilnehmerzahl größer als eins waren nie buchbare Termine gefunden wurden. Der Algorithmus verwendet nun die Mindestteilnehmerzahl des Angebots als Suchparameter.