Seite wählen

NETWAYS Blog

Unser Weg von Confluence zu BookStack

Wenn ich auf meine bald 15 Jahre bei NETWAYS zurückblicke, haben wir schon das ein oder andere Tool für Dokumentation verschlissen und verwendet. Die Reise ging von TWiki zu Foswiki, nahm eine kleinen Nebenausflug zu Mediawiki und brachte uns vor vielen Jahren letztendlich zu Confluence.

Die Entscheidung für Confluence fußte damals vor allem auf zwei Argumenten. Zum einen waren wir gerade mal 18 Leute und die Lizenzkosten für eine On-Prem-Installation überschaubar, zum anderen hatte Confluence einen sehr stabilen Eindruck gemacht und wir wollten damals von der „Selbstbeschäftigung“ und Plugin-Hölle der anderen Systeme weg, da wir dafür zu viel Zeit verbraten hatten. Kurzum, eigentlich die klassische „Dann kauf ich halt was“-Geschichte. Es wäre auch unfair zu sagen, dass die Entscheidung für Confluence eine schlechte Entscheidung war. Das Tool hat uns viele Jahre treue Dienste geleistet und obwohl schon einige Zeit nicht mehr aktualisiert, lief es bis zum gestrigen Tag ohne größere Zwischenfälle

Warum etwas Neues?

Die Motivation für ein neues Tool hatte sowohl technische als auch fachliche Gründe. Technisch entsprach die zunehmende Cloud-Only-Strategie von Atlassian, deren Systeme sich in Vergangenheit auch nicht besonders mit Ruhm bekleckert haben, nicht unseren Vorstellungen, da wir das als elementar angesehene System im On-Prem haben wollten. Hinzu sind die Lizenzkosten mit knapp 90 Leuten durchaus ein Argument sich mal etwas anderes anzusehen und ggf. damit einhergehende Aufwände die Berechtigung zu verschaffen.

Auf der anderen Seite hatten wir auch fachliche Argumente, welche für einen Neuaufbau des Systems gesprochen haben. Unser in die Jahre gekommenes Confluence hatte dringend mal einen Frühjahrsputz nötig und gleichzeitig wollten wir mit einem Handbuch gleich alle Unternehmensprozesse und Regelungen fit für ein späteres Audit machen. Persönlich favorisierte ich die Idee alles in ein System zu packen, was mir unsere Heads jedoch in der Diskussion ausredeten. Im Nachhinein klar die richtige Entscheidung, da ein Handbuch schlichtweg andere Anforderungen hat als ein Dokumentationssystem. Somit haben wir jetzt zwei Systeme (Handbook & Docs) mit unterschiedlichen Anforderungen. Das Handbook ist die „Gesetzgebung“ unserer Firma und das für alle verbindliche Regelwerk. Die Docs spiegeln die Arbeitsdokumente der einzelnen Abteilungen wieder und unterscheiden sich somit signifikant von unserem Handbook.

Wieso nun BookStack?

Von Confluence kommend waren die Anforderungen gar nicht so klein. LDAP sollte gehen, individualisierter PDF-Export, Berechtigungen für Extern und Intern, Zeichnungen sollen direkt im Wiki möglich sein, eine API um technische Informationen (bspw. Kunden im NWS-Umfeld) automatisch zu erstellen und natürlich eine gute Suche und Top-Performance. Nach etwas Recherche bin ich immer wieder über zwei Systeme gestolpert, Wiki.js und BookStack. Beide Systeme sind Open Source und machten in ersten Tests mit Docker einen guten Eindruck. Wiki.js war das auf den ersten Blick modernere System und in vielen Punkten sehr ähnlich zu Confluence. Wenn ich ehrlich bin, weiß ich nicht mehr genau, welches Hauptargument gegen den Einsatz von Wiki.js gesprochen hat. Gründe dagegen waren jedoch, dass das ein oder andere Feature für Version 3.0 angekündigt war, deren Milestone immer verschoben wurde und bis heute nicht verfügbar ist. Auch die Tatsache, dass es Confluence sehr ähnlich war, schreckte mich final davor zurück.

Das Hauptargument Wiki.js nicht zu nehmen, war jedoch nicht Wiki.js sondern BookStack. Auf BookStack bin ich bei der Recherche immer wieder gestoßen, hatte es jedoch nie ernsthaft in Betracht gezogen. Mir schienen die Features nicht ausreichend für unsere Bedürfnisse und darüber hinaus hielt ich die feste Struktur von BookStack, welches die Idee hat ein virtuelles Bücherregal darzustellen, für unzureichend. Im Nachhinein hat sich gerade diese Struktur als einer der größten Pluspunkte herausgestellt und daher bin ich bis heute froh, dass wir uns für BookStack entschieden haben. Darüber hinaus hat uns der pragmatische und sehr aufgeräumte Ansatz von BookStack und die permanente Weiterentwicklung überzeugt.

Was macht BookStack aus?

Ziel es Blogposts soll es nicht sein, verschiedene Wiki- und Dokumentationslösungen miteinander zu vergleichen (vielleicht kommt das mal zu einem späteren Zeitpunkt, aber derartige Artikel gibt es sowieso wie Sand am Meer), sondern eher was uns dazu motiviert hat, den Weg mit BookStack zu gehen und wie wir es umgesetzt haben.

Wie bereits oben angesprochen, stellt BookStack ein virtuelles Bücherregal zur Verfügung und ordnet seine eigentlichen Dokumente, bei BookStack Pages genannt, in eine feste Struktur. Es gibt Shelves, Books und Pages, das wars. Bei Bedarf können Pages noch in so genannte Chapter gruppiert werden, was jedoch optional ist. Genau da steckt aus meiner Sicht ein großer Vorteil von BookStack. Das System verbietet einfach endlose Seitenhierarchien aufzubauen, in welchen sich nach kurzer Zeit keiner mehr zurechtfindet. Die flache und vorgegebene Struktur zwingt einen bei Erstellung der Dokumente über den richtigen Ort nachzudenken und gibt dem ganzen System eine solide Grundordnung. Wir repräsentieren heute jeden Unternehmensbereich in einem eigenen Shelf und abstrahieren die fachlichen Strukturen dann in darunter liegenden Books. Darüber hinaus liefert die Suche auch sehr gute Ergebnisse und Dokumente sind im Vergleich zu unserem vorherigen System schnell zu finden. Auch alle anderen genannten Anforderungen hat BookStack erfüllt und neben LDAP, Zeichnungen, PDF-Export und API geht eigentlich alles, was wir so brauchen. Der Editor kann sowohl im WYSIWYG- als auch im Markdown-Modus verwendet werden, was den Bedürfnissen unserer Mitarbeiter:innen entsprechend entgegenkommt.

Wie haben wir den Umzug gemacht?

Den Teil des Handbooks haben wir zu 95% neu geschrieben. Zum einen waren viele Regelungen und Informationen nicht einheitlich bzw. überhaupt nicht vorhanden. Zum anderen war uns wichtig, dass die Dokumente gleich die entsprechenden Vermerke für eine spätere ISO-Zertifizierung beinhalten. Hinzu war entscheidend, dass wir Dinge wie Stellenbeschreibungen, Unternehmensstruktur und Übersicht aller Mitarbeiter:innen automatisch erstellen. Auch die jeweiligen Assets, welche wir in Snipe-IT verwalten, sollten entsprechend ausgelesen und in den Seiten dargestellt werden. Den Teil der dynamischen Generierung haben wir dann mit Python und Verwendung der API realisiert. Das Ganze läuft nun seit gut 6 Monaten ohne größere Schwierigkeiten.

Die API bietet für nahezu alle Bedürfnisse geeignete Endpunkte und ist sehr gut dokumentiert. Unter Verwendung von entsprechenden Tokens werden die Benutzerberechtigungen so an den API-Consumer weitergereicht.

Bei der Dokumentation der einzelnen Bereiche sah das ganze schon anders aus. Auch hier haben wir viele Dokumente neu geschrieben bzw. manuell übernommen. Gerade die ein oder andere Dokumentation, welche bereits vor 10 Jahren erstellt wurde, schien uns als PDF-Export vollkommen ausreichend archiviert und die manuelle Übernahme wäre eher einer Beschäftigungstherapie gleichgekommen.

In Summe haben wir gemeinsam tausende an Dokumenten gesichtet, migriert, gelöscht und neu geschrieben, aber der Aufwand hat sich gelohnt. Der alte Schrott ist weg und wir finden uns in BookStack nun gut zu recht. Die letzten Abteilungen haben ihre Daten noch unter Verwendung von Confluence Exports umgezogen und gestern haben wir das Altsystem in den wohlverdienten Ruhestand geschickt.

Was noch kommt?

Falls Interesse besteht, kann ich zu einem späteren Zeitpunkt gerne noch etwas über unsere Generatoren schreiben. Diese erzeugen nämlich nicht nur die Seiten für Mitarbeiter:innen und Assets, sondern legen auch Übersichtsseiten mit Sozialleistungen und Regelungen an, welche wir auf Basis der Page-Tags generieren. Auch Consulting könnt ihr jederzeit bei uns kaufen. So richtig etabliert haben wir das im Professional Services noch nicht, aber dann komme eben ich vorbei. Noch kenne ich mich aus 🙂

Darüber hinaus werden wir BookStack aller Wahrscheinlichkeit nach in unser NWS-Portfolio übernehmen, da es eine sehr gute Ergänzung zu unseren bestehenden Produkten darstellt. An dieser Stelle auch ein herzlicher Dank an Dan Brown, welcher in Vollzeit an BookStack arbeitet und es als Open Source Software zur Verfügung stellt. Zur Unterstützung des Projekts haben wir einen Supportvertrag abgeschlossen, den wir bisher jedoch noch nie benötigt haben. Auch ein weitergehendes Engagement wird vermutlich bald kommen, aber dazu später mehr.

Fazit

Confluence hat uns einen guten Dienst erwiesen, aber auf Basis von BookStack und dank der Mitarbeit aller haben wir nun eine neue und modulare Basis für unser Handbook und Dokumentation. Jeder manuelle Schritt und die Überarbeitung waren der Qualität zuträglich und haben uns besser gemacht. BookStack hat sich darüber hinaus als unglaublich stabiles und innovatives Produkt erwiesen, welches ich Euch nur ans Herz legen kann. Für mich die Alternative zu Confluence schlechthin.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

Request Tracker: Highlight tickets based on due dates

A while ago we’ve announced a new extension for Request Tracker which allows to highlight tickets in search results even better.

Next to „last updated by“ and custom field conditions, we’ve now added a requirement from production:

  • light red coloring for tickets with a due date in 3 days
  • dark red coloring for everything where the due date already passed

When there’s a ticket which matches one of the other conditions, due date wins over „last updated by“ which itself wins over custom field conditions.

v2.0.0 is available on GitHub. Consider asking our sales engineers when building a new RT instance in NWS 🙂

New Request Tracker Extensions: Search Result Highlights, Quick Assign & User Overview

We use Request Tracker on a daily basis, and have written many extensions for our own workflows and visualizations. Lately we’ve been helping a customer to migrate from OTRS to RT running in NWS, and learned about new ways to improve our workflows.

Highlight Search Results on Conditions

When you own a ticket, but someone else updated the ticket with a comment/reply, you want to immediately see this. Our extension makes this possible with either a background color or an additional icon (or both).
You can also limit this to replies/comments from customers, where the last update wasn’t performed by users in a specific group. This allows to immediately see support or sales tickets which need to be worked on in the dashboards.
Another use case is to highlight search result rows when a custom field matches a specified value. If you’re setting tickets for example, you can visually see the difference between a „bought ticket“ and „paid ticket“ state.
While developing the extension, I’ve also fixed an upstream RT bug which has been merged for future releases. There’s even more possibilities, as we’ve recognised that one of the BestPractical/RT developers forked our extension already 🙂

Quick Assign People to Tickets

By default, one needs to edit the „People“ tab to assign a ticket to a privileged user, or modify adminCC and the requestor. This takes far too long and as such, our own NETWAYS extension improved this with drop-downs and action buttons. We have now open-sourced this feature set into a new extension on GitHub: rt-extension-quickassign.

 

Show Ticket Count per User and Status

This extension was released a while ago, and we’ve fixed a bug with empty sets in there. In addition to that, we’ve added a new configuration option which allows to list specific groups and their members, and not only privileged users. This comes in handy to only show the NETWAYS members but not any root or meta accounts. Read more on GitHub.

Do you need more customizations for Request Tracker, or want to run RT in a managed cloud environment? Just get in touch 🙂

RT Extensions Made Easy

Heute geht es darum, wie man auf einfache Art und Weise Erweiterungen für Request Tracker vorbereitet. Einen kleinen Ausblick darauf wie man sie dann auch schreibt, gibt es am Ende auch, aber mehr würde den Rahmen dieses Posts sprengen.
Bevor wir beginnen, müssen jedoch erst einige Vorbereitungen erledigt werden:
# cpanm Module::Install::RTx Dist::Zilla::MintingProfile::RTx
Dies installiert einige Werkzeuge die wir für die folgenden Beispiele benötigen.
Außerdem bietet es sich an, ein paar grundlegende Informationen über die eigene Person zu konfigurieren. Das erspart uns später einige Angaben:
$ dzil setup

Wer sich fragt was man alles mögliche an Lizenzen angeben kann, darf hier einen Blick riskieren.
Schon kann es losgehen. Zuerst erstellen wir mit dem sogenannten „profile provider“ RTx ein blankes Skelett.
Dies erstellt dort wo wir uns gerade befinden ein neues Verzeichnis mit dem Namen „RT-Extension-Netways“:
$ dzil new -P RTx RT-Extension-Netways

Die darin enthaltene Datei „Netways.pm“ nun öffnen und entsprechend anpassen bzw. erweitern. Darunter fallen i.d.R. der Name, die Beschreibung, die RT Versions-Voraussetzungen und die Autoren Angabe. Der Rest sollte bereits größtenteils vorausgefüllt sein, wie schon zuvor erwähnt.
Außerdem ist es ratsam sich die Datei „Makefile.PL“ einmal genauer anzusehen. Denn dort sind ebenfalls einige wichtige Angaben zu finden über deren Korrektheit man sich vergewissern sollte.
Hat man dies getan, kann man bereits mit der eigentlichen Entwicklung der Erweiterung beginnen.
Hierzu sei jedem die offizielle Dokumentation von Best Practical und HTML::Mason ans Herz gelegt.
Ist man letztendlich fertig mit der Entwicklung oder möchte schon einmal testen was man da tolles fabriziert hat, ist es an der Zeit die Verteilung seiner neuen Erweiterung vorzubereiten:
$ perl Makefile.PL

Da dies die erste Ausführung von „Makefile.PL“ war, wurden einige für die Installation notwendige Bibliotheken in die Struktur integriert. Diese sind notwendig, damit Nutzer die Erweiterung zumindest installieren können, ohne zusätzlich notwendige Abhängigkeiten.
Außerdem wurden einige zusätzliche Dateien und Verzeichnisse angelegt. Diese jedoch sind nur ein Nebenprodukt und nicht notwendig für die Verteilung. (Darunter das „Makefile“ und die „MYMETA.*“ Dateien.) Was alles genau nicht notwendig ist, kann in der Datei „gitignore“ nachgelesen werden. (Wer sowieso mit Git arbeitet, kann diese Datei auch zu „.gitignore“ umbenennen.)
Nun folgt man nur noch den üblichen Schritten und schon kann die Erweiterung konfiguriert und genutzt/getestet werden:
$ make
# make install

Johannes Meyer
Johannes Meyer
Lead Developer

Johannes ist seit 2011 bei uns und inzwischen, seit er 2014 die Ausbildung abgeschlossen hat, als Lead Developer für Icinga Web 2, Icinga DB Web sowie alle möglichen anderen Module und Bibliotheken im Web Bereich zuständig. Arbeitet er gerade mal nicht, macht er es sich bei schlechtem Wetter am liebsten zum zocken oder Filme/Serien schauen auf dem Sofa gemütlich. Passt das Wetter, geht's auch mal auf eines seiner Zweiräder. Motorisiert oder nicht.

NETWAYS Web Services: Connect to your own Domain!

Our team has continued to improve the NETWAYS Web Services products for providing more comfort to our customers. Now any app can be run under its own Domain Name in combination with its own SSL certificate. This option is available for the following products:

The implementation within the product is quite simple. After your app has been created successfully, you will find a new webform in your app’s Access tab. Here is an example of a Request Tracker app:

As the webform shows, customers simply have to enter a registered Domain Name and their SSL Certificate as well as their SSL Key. The implementation in the app will be done by our NWS platform fully automated. Customers only need to take care about the quality and correctness of the certificate and to make sure they enter the DNS record correctly on their Domain Name Server. The IP address needed will be indicated underneath the webform in the information section. Furthermore, it is still possible to set an additional CName for your app. This means that your customized Domain Name and the CName can be used in parallel. Furthermore, the platform generated standard URL will stay valid and customers can always go back to the initial settings by removing their entries from the webform.
After clicking the save button, the app will be restarted and all changes will be taken into production immediately.
The bonus of this option is clear: Anybody working with your apps will be glad to use easy to read and memorize URLs. Furthermore, company identity and culture is even more important today than ever. So why not also provide your SuiteCRM, Rocket.Chat or Nextcloud with a well branded URL?
More information can be found on our NWS homepage, in any of our product sections or by contacting us via the NWS livechat.
Important note: All NWS products are up for a 30 day free trial!