(Quelle: https://about.gitlab.com/blog/2017/05/09/demo-service-desk/ )

‍

Installation und Best Pratices: GitLab Service Desk bei selbst gehostetem GitLab in der Community Edition

Das GitLab Service Desk Modul ist ein echter Gewinn für die Kommunikation und für den Support, da GitLab hier eine einfache und integrierte Lösung bietet um mit externen Partnern und Kunden schnell und einfach in Kontakt zu treten.

‍

Was ist der GitLab Service Desk?

Der Service Desk ist ein GitLab-Modul, mit dem Ihr Team innerhalb von GitLab eine direkte Verbindung zu einer externen Partei per E-Mail herstellen kann. Dabei sind keine externen Tools erforderlich. Ein fortlaufendes Gespräch genau dort, wo Ihre Software erstellt wird, stellt sicher, dass Benutzerfeedback bzw. Benutzeranfragen direkt dort landen, wo sie benötigt werden.

Mit Service Desk kann man seinen Kunden einen effizienten E-Mail-Support bieten. Der Kunde kann Fehlerberichte, Funktionsanfragen oder allgemeines Feedback per E-Mail zusenden und all diese Anliegen landen als Tickets im definierten GitLab-Service-Desk-Bereich. Das Entwicklerteam kann wiederum direkt aus dem Projekt heraus reagieren.

Da Service Desk direkt in GitLab integriert ist, werden die Komplexität und Ineffizienz bei gleichzeitiger Verwendung mehrerer Tools und von externen Integrationen beseitigt, wodurch die Zykluszeit vom Feedback des Kunden bis zur Bearbeitung des Anliegens erheblich verkürzt wird.

Eine Demonstration des Service Desk Moduls können Sie sich im Video weiter oben ansehen.

Wie aktiviert man den Service Desk?

Als "Project owner" eines Projektes können Sie den Service Desk einrichten.

Befolgen Sie dazu die folgenden Schritte:

• Richten Sie eine E-Mail-Adresse für eingehende E-Mail-Anfragen für die GitLab-Instanz ein. Die Verwendung einer E-Mail-Unteradressierung ist dafür empfehlenswert. In GitLab v11.7 und höher können Sie jedoch auch alle Postfächer verwenden.
• Navigieren Sie zu "Settings"> "General" Ihres Projektes und suchen Sie den Abschnitt "Service Desk".
• Aktivieren Sie die Option "Service Desk aktivieren". Dadurch wird eine eindeutige E-Mail-Adresse für Anliegen an das Projekt angezeigt. Diese Anliegen werden vertraulich behandelt, sodass sie nur für Projektmitglieder sichtbar sind. Beachten Sie, dass in GitLab 11.7 das Format der generierten E-Mail-Adresse aktualisiert wurde. Das ältere Format wird jedoch weiterhin unterstützt, sodass vorhandene Aliase oder Kontakte weiter benutzt werden können.
• Achtung! Die hinterlegte E-Mail-Adresse kann von jedem verwendet werden um mit einem Anliegen an das Entwicklerteam heranzutreten, unabhängig davon, ob man Zugriff auf die GitLab-Instanz hat oder nicht.
• Wenn Ihr Repository "Templates" enthält, können Sie optional eines aus dem Auswahlmenü auswählen, um dieses an alle Service Desk-Probleme anzuhängen.

‍

‍

Wie legt man eine E-Mail-Adresse richtig an, um diese sicher für Service Desk zu nutzen?

‍

Sicherheitshinweise

Seien Sie vorsichtig, wenn Sie die Domain auswählen, die für den Empfang eingehender E-Mails verwendet werden soll. Angenommen, Ihre Unternehmensdomain auf oberster Ebene lautet muensmedia.de, dann haben alle Mitarbeiter in Ihrem Unternehmen über Google Apps eine E-Mail-Adresse in dieser Domain. Für die private Slack-Instanz Ihres Unternehmens ist eine gültige @muensmedia.de-E-Mail-Adresse erforderlich, um sich anzumelden.

Wenn Sie auch eine öffentlich zugängliche GitLab-Instanz auf z.B. muensmedia.de hosten und Ihre Domain für eingehende E-Mails auf muensmedia.de einstellen, kann ein Angreifer die Funktionen "Neues Problem per E-Mail erstellen" oder "Neuen "Merge request" per E-Mail erstellen" durch die Nutzung einer eigenen Projektadresse missbrauchen. Dadurch wird eine Bestätigungs-E-Mail gesendet, die ein neues Problem oder ein "merge request" für das Projekt des Angreifers erstellt und es ihm ermöglicht, auf den Bestätigungslink zu klicken und sein Konto in der privaten Slack-Instanz Ihres Unternehmens zu validieren.

Daher gibt es die klare Empfehlung, eingehende E-Mails in einer Subdomain, wie incoming.muensmedia.de zu empfangen und sicherzustellen, dass Sie keine Dienste verwenden, die sich ausschließlich aufgrund des Zugriffs auf eine E-Mail-Domain wie * .muensmedia.de authentifizieren. Alternativ können Sie eine dedizierte Domain für die GitLab-E-Mail-Kommunikation verwenden, z. B. muensmedia-gitlab.com.

Tipp:
Verwenden Sie einen Mailserver, der zur Reduzierung von Spam konfiguriert wurde. Ein Postfix-Mailserver, der beispielsweise in einer Standardkonfiguration ausgeführt wird, kann zu Missbrauchshandlungen führen. Alle in der konfigurierten Mailbox empfangenen Nachrichten werden verarbeitet, und Nachrichten, die nicht für die GitLab-Instanz bestimmt sind, erhalten eine Ablehnungsbenachrichtigung. Wenn die Absenderadresse gefälscht ist, wird die Ablehnungsbenachrichtigung an die gefälschte FROM-Adresse gesendet, was dazu führen kann, dass die IP-Adresse oder Domain des Mailservers zukünftig in einer Sperrliste gelistet wird.

‍

Die Einrichtung

‍
Für die Bearbeitung eingehender E-Mails ist ein IMAP-fähiges E-Mail-Konto erforderlich. GitLab erfordert eine der folgenden drei Möglichkeiten:

• E-Mail-Unteradressierung (empfohlen)
• Catch-all Postfach
• Dedizierte E-Mail-Adresse (unterstützt nur Antworten per E-Mail)

‍

E-Mail-Unteradressierung

Die Unteradressierung ist eine Mail-Server-Funktion, bei der jede E-Mail an nutzer+willkürlicher_tag@example.com in der Mailbox für nutzer@example.com landet. Es wird von Anbietern wie Google Mail, Google Apps, Yahoo! Mail, Outlook.com und iCloud sowie von Postfix-Mailservern, welche Sie lokal ausführen können, unterstützt. Microsoft Exchange Server unterstützt grundlegend keine Unteradressierung und Microsoft Office 365 unterstützt standardmäßig keine Unteradressierung

Wenn Ihr Anbieter oder Server die E-Mail-Unteradressierung unterstützt, dann ist die Verwendung dieser empfehlenswert. Eine dedizierte E-Mail-Adresse unterstützt nur die Funktion "Per E-Mail antworten". Ein Catch-All-Postfach unterstützt dieselben Funktionen wie die Unteradressierung (ab GitLab 11.7). Die Unteradressierung wird jedoch weiterhin bevorzugt, da nur eine E-Mail-Adresse verwendet wird und ein Catch-All für andere Zwecke als GitLab verfügbar bleibt.

‍

Catch-all Postfach

Ein Sammelpostfach für eine Domain empfängt alle an die Domain adressierten E-Mails, die nicht mit den auf dem Mailserver vorhandenen Adressen übereinstimmen.

Ab GitLab 11.7 unterstützen Catch-All-Postfächer dieselben Funktionen wie die E-Mail-Unteradressierung. Die E-Mail-Unteradressierung bleibt jedoch unsere Empfehlung, damit Sie Ihr Catch-All-Postfach für andere Zwecke reservieren können.

‍

Dedizierte E-Mail-Adresse

Diese Lösung ist relativ einfach einzurichten: Sie müssen lediglich eine E-Mail-Adresse erstellen, um die Antworten Ihrer Benutzer auf GitLab-Benachrichtigungen zu erhalten. Diese Methode unterstützt jedoch nur Antworten und nicht die anderen Funktionen eingehender E-Mails.

Wenn Sie Google Mail / Google Apps für eingehende E-Mails verwenden möchten, stellen Sie sicher, dass der IMAP-Zugriff aktiviert ist und das weniger-sichere Apps auch auf das Konto zugreifen können oder verwenden sie eine 2-Schritt-Validierung und ein Anwendungskennwort.

Wenn Sie Office 365 verwenden möchten und die Zwei-Faktor-Authentifizierung aktiviert ist, stellen Sie sicher, dass Sie anstelle des regulären Kennworts für das Postfach ein App-Kennwort verwenden.Befolgen Sie die Postfix-Setup-Dokumentation von GitLab, um einen einfachen Postfix-Mailserver mit IMAP-Zugriff unter Ubuntu einzurichten.

‍

Omnibus-Package Installation

- Suchen Sie den Abschnitt für eingehende E-Mails in /etc/gitlab/gitlab.rb, aktivieren Sie die Funktion und geben Sie die Informationen Ihres spezifischen IMAP-Servers und Ihr E-Mail-Kontos ein (siehe Beispiele unten).

- Konfigurieren Sie GitLab neu, damit die Änderungen wirksam werden:

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart‍

- Stellen Sie sicher, dass alles richtig konfiguriert ist:

sudo gitlab-rake gitlab:incoming_email:check

Antwort per E-Mail installieren

- Wechseln Sie in das GitLab-Installationsverzeichnis:

cd /home/git/gitlab

- Suchen Sie den Abschnitt incoming_email in config / gitlab.yml, aktivieren Sie die Funktion und geben Sie die Informationen Ihres spezifischen IMAP-Servers und Ihres E-Mail-Kontos ein (siehe Beispiele unten).

- Aktivieren Sie mail_room im Init-Skript unter /etc/default/gitlab:

sudo mkdir -p /etc/default
echo 'mail_room_enabled=true' | sudo tee -a /etc/default/gitlab

- Starten Sie GitLab neu:

sudo service gitlab restart‍

- Stellen Sie sicher, dass alles richtig konfiguriert ist:

sudo -u git -H bundle exec rake gitlab:incoming_email:check RAILS_ENV=production

‍

Die Antwort per E-Mail sollte jetzt funktionieren.

‍

‍

Konfigurationsbeispiele

Die Konfigurationsbeispiele sind ausführlich in der GitLab-Dokumentation zu finden.

‍

Wie und wo werden Antwort-Templates hinterlegt?

Wenn ein Kunde sein Anliegen über den Service Desk einreicht oder wenn eine neue Notiz zu einem Service Desk-Ticket erstellt wird, wird eine Antwort via E-Mail an den Kunden gesendet.

Der Text dieser E-Mail-Nachrichten kann mithilfe von Vorlagen angepasst werden. Um eine neue benutzerdefinierte Vorlage zu erstellen, erstellen Sie eine neue Markdown-Datei (.md) im Verzeichnis .gitlab/service_desk_templates/ in Ihrem Repository. Commit und Push zu Ihrem Standard-Branch.

‍

Bestätigungsmail

Die Bestätigungsmail ist die E-Mail, die an einen Benutzer gesendet wird, nachdem dieser sein Anliegen gesendet hat. Der Dateiname der Vorlage muss Thank_you.md sein. Sie können den Platzhalter %{ISSUE_ID} verwenden, der in der E-Mail durch eine Problem IID ersetzt wird, und den Platzhalter %{ISSUE_PATH}, der durch den Projektpfad und die Problem IID ersetzt wird. Da die Service Desk-Anliegen vertraulich erstellt werden (nur Projektmitglieder können sie sehen), enthält die Antwort-E-Mail keine Verlinkung zum generierten GitLab-Ticket.

‍

Statusmail

Die Statusmail ist die E-Mail, die an einen Benutzer gesendet wird, wenn das von ihm eingereichte Anliegen im generierten GitLab-Ticket einen neuen Kommentar enthält. Der Dateiname der Vorlage muss new_note.md sein. Sie können den Platzhalter %{ISSUE_ID} verwenden, der durch eine Issue-IID in der E-Mail ersetzt wird, den Platzhalter %{ISSUE_PATH}, der durch den Projektpfad ersetzt wird, und die Platzhalter Issue IID und %{NOTE_TEXT}, der durch den Notiztext ersetzt wird.

‍

Verwendung eines benutzerdefinierten E-Mail-Anzeigenamens

Wenn das Feature-Flag service_desk_email in Ihrer Konfiguration aktiviert ist, können Sie Service Desk-Tickets erstellen, indem Sie E-Mails an die benutzerdefinierte Service Desk-E-Mail-Adresse senden, die das folgende Format haben sollte: project_contact+%{key}@example.com.

Der Teil %{key} wird verwendet, um das Projekt zu finden, in dem das Problem erstellt werden soll. Der %{key} -Teil kombiniert den Pfad zum Projekt und das konfigurierbare Projektnamensuffix: <Projekt_vollständiger_Pfad> - <Projektname_Suffix>.

Sie können das Projektnamensuffix in den Service Desk-Einstellungen Ihres Projekts festlegen. Es kann nur Kleinbuchstaben (a-z), Zahlen (0-9) oder Unterstriche (_) enthalten.

‍

‍

Diese Codesnippets können Sie für Ihre Konfiguration verwenden.

Example for installations from source:

service_desk_email:
 enabled: true
 address: "project_contact+%{key}@example.com"
 user: "project_support@example.com"
 password: "[REDACTED]"
 host: "imap.gmail.com"
 port: 993
 ssl: true
 start_tls: false
 log_path: "log/mailroom.log"
 mailbox: "inbox"
 idle_timeout: 60
 expunge_deleted: true

Example for Omnibus GitLab installations:

gitlab_rails['service_desk_email_enabled'] = true

gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@gmail.com"

gitlab_rails['service_desk_email_email'] = "project_support@gmail.com"

gitlab_rails['service_desk_email_password'] = "[REDACTED]"

gitlab_rails['service_desk_email_mailbox_name'] = "inbox"

gitlab_rails['service_desk_email_idle_timeout'] = 60

gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"

gitlab_rails['service_desk_email_host'] = "imap.gmail.com"

gitlab_rails['service_desk_email_port'] = 993

gitlab_rails['service_desk_email_ssl'] = true

gitlab_rails['service_desk_email_start_tls'] = false

Angenommen, in den Service Desk-Einstellungen des mygroup / myproject-Projekts ist das Projektnamensuffix auf "support" gesetzt, und ein Benutzer sendet eine E-Mail an project_contact+mygroup-myproject-support@example.com, dann wird Infolgedessen aus dieser E-Mail im Projekt mygroup / myproject ein neues Service Desk-Ticket erstellt.

‍
Aktivieren der benutzerdefinierten E-Mail-Adresse

Für diese Funktion ist das Feature-Flag service_desk_custom_address standardmäßig deaktiviert. Sollten Sie nicht selbst der GitLab-Administrator sein, dann bitten Sie einen GitLab-Administrator mit Rails-Konsolenzugriff, den folgenden Befehl auszuführen, um die Funktion zu aktivieren:

Feature.enable(:service_desk_custom_address)

Die Konfigurationsoptionen sind dieselben, wie für die Konfiguration eingehender E-Mails( siehe: "Wie legt man eine E-Mail-Adresse richtig an, um diese sicher für Service Desk zu nutzen?" oder GitLab-Dokumentation)

Den Service Desk richtig nutzen

Als Kunde / Endnutzer

Um ein Service Desk-Ticket zu erstellen, muss ein Endbenutzer nichts über die GitLab-Instanz wissen. Er sendet einfach eine E-Mail an die angegebene Adresse und erhält eine E-Mail zur Bestätigung des Empfangs zurück:

‍

Dies gibt dem Endbenutzer auch die Möglichkeit, sich von weiteren Benachrichtigungen bezüglich seines gemeldeten Anliegens abzumelden.

Wenn ein Kunde sich nicht von der Benachrichtigung abmeldet, werden alle neuen Kommentare, die dem in GitLab generierten Ticket hinzugefügt werden, als E-Mails gesendet:

‍

Alle von ihnen gesendeten Antworten werden im generierten GitLab-Ticket angezeigt.

‍

Als Bearbeiter des Anliegens

Für die Bearbeiter des Problem funktioniert eigentlich alles wie gewohnt. Sie sehen den vertrauten Issue-Tracker, in dem sie Tickets sehen können, die über Kundensupportanfragen erstellt wurden. Dementsprechend können Sie diese Tickets auch filtern und mit ihnen interagieren, wie mit allen anderen Tickets auch:

‍

‍

Nachrichten von Kunden werden als vom Support-Bot-User stammend angezeigt. Abgesehen davon können Sie Kommentare wie gewohnt lesen und schreiben:

‍

Beachten Sie dabei, dass:

• die Projekteinstellungen, bezüglich der Sichtbarkeit des Projektes(privat, intern, öffentlich) keinen Einfluss auf den Service Desk haben.
• der Pfad zum Projekt, einschließlich seiner Gruppe oder seines Namespace, in E-Mails angezeigt wird.

‍

Die Integration des GitLab Service Desk in Agentur-Prozesse

Mit der Integration und der Nutzung des GitLab Service Desks haben sich für uns "best practice"-Methoden für die Nutzung dieses gewinnbringenden GitLab-Moduls ergeben.

Was ist bei der Kommunikation mit Kunden über den Service Desk zu beachten?

Die Kommunikation mit den Kunden, die mit einem Anliegen über den Service Desk an Sie herantreten, muss anders gehandhabt werden, als die Kommunikation mit den Kunden, welche über GitLab-Zugangsdaten verfügen und so direkt aus dem Projekt heraus mit Ihnen kommunizieren können.

Es ist daher zu beachten, dass

• bei Kommentaren innerhalb eines Service Desk Tickets keine Bilder und Anhänge in der Statusmail an den Kunden gesendet werden und er somit nur den Text aus dem Service Desk Ticket erhält
• bei Kommentaren innerhalb eines Service Desk Tickets nicht der gesamte Kontext/Dialog aus vorherigen Kommentaren oder der Problembeschreibung mitgesendet wird, sondern nur der aktuell verfasste Kommentar.
• der Kunde innerhalb der Statusmail, welche aus dem Kommentar innerhalb des Service Desk Tickets generiert und ihm zugesendet wird, nicht erkennt welcher Mitarbeiter ihm gerade Antwortet. Daher ist es wichtig in Kommentaren innerhalb des Tickets eine gängige Verabschiedungsfloskel und den Namen des Bearbeiters einfließen zu lassen
• Kommentare innerhalb des Service Desk Tickets auch nach dem Schließen des Tickets weiterhin in Form von Statusmails an den Kunden gesendet werden
• der Kunde keine Meldung darüber bekommt, dass sein Ticket geschlossen wurde und daher eine abschließende Meldung über die fertige Bearbeitung seines Anliegens erfolgen muss
• die generierten Antwort-Templates nicht mehr greifen, sobald ein Ticket aus dem Service Desk in ein anderes Projekt verschoben wurde
• gesetzte "estimates" und "slash"-Kommentare nicht per Statusmail an den Kunden gesendet werden
• eine regelmäßige Kontrolle des Service Desk erfolgen muss, da das generierte Service Desk Ticket nicht automatisch einem Mitarbeiter zugewiesen wird