Jedes Atlassian-Dienstleistungsprojekt, das wir gestartet haben, als ich damals bei Clearvision und dann bei Adaptavist gewesen bin, wurde gleich zu Beginn unnötiger- und lästigerweise ausgebremst, weil wir erstmal erklären mussten, wie man komplizierte Berechtigungsschemata aufsetzt, bevor der Kunde uns Zugriff auf sein Jira-System geben konnte.
Zusammenarbeit ist natürlich wichtig, speziell angesichts der nie endenden Dynamik an Partnerschaften, Akquisen und Verschmelzungen und der steigenden Zahl von Auftragnehmern und Beratern, mit denen erfolgreiche Teams zusammenarbeiten wollen.
Wenn man sich mal dazu entschieden hat, im Rahmen des Entwicklungsprozesses Informationen mit externen Partnern zu teilen, sollten sich diese im Idealfall problemlos mit unseren Teams, Prozessen und Tools integrieren können.
Um die Zusammenarbeit effektiv auszubauen, brauchen die Teams auf beiden Seiten Echtzeit-Sichtbarkeit auf die Dinge, an denen gearbeitet wird, und die Fähigkeit, Tickets einzusehen, zu kommentieren und mit Anhängen zu versehen.
Wenn wir externen Partnern begrenzten und sicheren Zugang zu unserem Jira (oder Confluence) geben wollen, haben wir drei Optionen – in Abhängigkeit von der Dauer der Zusammenarbeit, der Größe der Instanzen und des Umfangs an Zugriff, den wir gestatten wollen:
- Option A: Das Aufsetzen von Berechtigungsschemata und die Vergabe einer vollen Jira-Lizenz an alle betreffenden Leute.
- Option B: Die Verwendung von Exalate, um einen Teil unserer Jira-Instanz im externen Jira-System zu klonen.
- Option C: Die Nutzung von External Share for Jira für Vorgänge und ihre Unteraufgaben.
Option | Wofür geeignet? |
---|---|
Jira mit passend konfigurierten Rollen, Berechtigungsschemata und Vorgangs-Sicherheitsschemata | Komplette Jira-Epics und -Projekte für ein Jahr oder längere Zeit teilen |
Exalate for Jira | Synchronisation von Jira-Projekten für kleinere Instanzen über ein Jahr oder Integration mit anderen Tools (z.B. ServiceNow, Zendesk, Github) |
External Share for Jira | Teilen einiger Vorgänge und Unteraufgaben für ein paar Tage, Wochen oder Monate. |
Option A: Berechtigungsschemata in Jira konfigurieren
1. Wissen, was wir teilen wollen und was nicht
Wenn wir einen Vollzeit-Jira-Admin haben, der sich mit Berechtigungsschemata (sowie LDAP, Crowd oder Active Directory) auskennt, können wir einfach ein geeignetes Berechtigungsschema für die Projekte erstellen, die wir mit externen Usern teilen wollen, und gleichzeitig sicherstellen, dass die anderen Projekte und Epics vor ihrem Zugriff geschützt sind. Viele Unternehmen mit großen Jira-Instanzen tun das bereits für ihre internen Mitarbeiter.
Falls wir eine große Zahl von externen Nutzern ins System bringen müssen, ist es vielleicht an der Zeit, über eine separate Verzeichnisstruktur mithilfe von Crowd als Single-sign-on-Server nachzudenken, wie es Dan Radigan im Atlassian-Blog beschrieben hat. Das ist ziemlich umfangreich, deshalb sind hier die wichtigsten Aspekte in aller Kürze.
"Wenn wir uns von oben durcharbeiten, indiziert die erste Ebene die Verzeichnisse, die Sie mit Jira verknüpfen müssen. Die rote Gruppe kommt aus Ihrer internen Verzeichnisstruktur (Active Directory, LDAP etc.). Die blaue Gruppe repräsentiert die externen User und kann mit demselben oder einem anderen Verzeichnisanbieter abgebildet werden.
Die zweite Ebene sind die Gruppen, die dieses Verzeichnis bereitstellt. In jedem Verzeichnis wollen Sie eine Gruppe haben, die all die User definiert, die Zugriff auf Jira haben. Jeder, der auf Jira zugreift, muss ein Mitglied von Jira_users sein. Sie wollen außerdem Nutzer identifizieren, die intern oder extern sind, um Berechtigungen zu delegieren. [...] Beispielsweise ist user@externalcompany1.com Mitglied der Gruppe ext-company1. Ich empfehle, eine E-Mail-Adresse als Nutzernamen zu verwenden, da diese universell identifizierbar ist. [...] Ist die Infrastruktur aufgesetzt, können wir dann Berechtigungen hinzufügen, damit für die externen User alles funktioniert."
Wenn wir das geregelt haben, geht es zum nächsten Schritt.
2. Rollen in Jira definieren (und uns darüber im Klaren sein, wie sie sich von Jira-Gruppen unterscheiden)
Dieser Prozess funktioniert für uns, wenn wir regelmäßig eine spezifische, gut definierte Rolle an dieselbe ausgelagerten Gruppe ausgliedern.
"Denken Sie an all die Job-Funktionen in Ihrem Projekt (z.B. interner Entwickler, Projektleiter oder externer Partner) [...] (Wenn wir beispielsweise einen Vorgang aus dem internen Review-Prozess herausschieben, weist der Workflow den Vorgang einem externen Partner zu.) Wenn wir den Namen oder die Gruppe des externen Partners in den Workflow einbinden, wird dieser Workflow nur für dieses eine Unternehmen funktionieren. Die Nutzung von Rollen versetzt uns in die Lage, den Workflow flexibel über mehrere Projekte hinweg zu verwenden, für die wir die involvierten Leute jeweils parametrisieren."
Falls sich die Leute oder Gruppen zwischen Jira-Projekten ändern, nutzen wir eine Rolle. Sofern dieselben Leute über alle Interaktionen in Jira konsistent bleiben, verwenden wir eine Gruppe.
3. Berechtigungsschemata aufsetzen
Berechtigungsschemata regeln, wer die Kernfunktionen in einem Projekt sehen und manipulieren kann. Wenn wir uns in die Projektberechtigungen klicken, finden wir die Einstellungsmöglichkeiten, wer dieses Projekt sehen darf. Nun starten wir, indem wir der Gruppe mars_users (interne Mitarbeiter) und der Rolle Partner (Partner in diesem Projekt) Zugriff zu gewähren.
Externe User können nur Jira-Projekte sehen, in denen ihre Unternehmensgruppe zur Partnerrolle hinzugefügt wurde. Dennoch sollten wir den Zugriff via Berechtigungsschema konservativ handhaben und die Sache möglichst simpel gestalten, indem wir das Standard-Berechtigungsschema anpassen, statt ein neues zu erstellen.
4. Vorgangs-Sicherheitsschemata konfigurieren
Teams, die die Sichtbarkeit von Vorgängen in einem Projekt beschränken müssen, können dafür das Vorgangs-Sicherheitsschema nutzen. So lässt sich kontrollieren, wer einen bestimmten Vorgang oder seine Kommentare sehen kann. Das erlaubt es internen Usern, Tickets anzulegen oder Konversationen in Kommentaren zu führen, die vor externen Partnern verborgen bleiben.
5. Wenn das kompliziert klingt, dann deshalb, weil es kompliziert ist
Aus diesem Grund empfiehlt Atlassian, Experimente mit Berechtigungs- und Vorgangs-Sicherheitsschemata in einer Testinstanz und nicht im Produktivsystem durchzuführen. Wir experimentieren mit Workflow-Bedingungen und Post-Function-Triggern, dann erstellen wir Dokumentationen und führen vielleicht Schulungen durch, um sicherzustellen, dass alle User in geteilten Objekten, Agile-Boards und Filtern den Naming-Konventionen entsprechen. Ohne diese Absicherungen riskieren wir, dass geschützte Informationen nach außen dringen.
Deshalb gibt es einen Marktplatz für einfachere Optionen.
Option B: Mit Exalate einen Teil der Instanz in eine andere kopieren
Es gibt eine detaillierte Schritt-für-Schritt-Anleitung zur Synchronisation zweier Jira-Instanzen mithilfe von Exalate. Die kurze Version geht folgendermaßen:
1. Wir installieren Exalate von iDalko aus dem Atlassian Marketplace.
2. Wir erstellen einen Workflow, der für beide Teams funktioniert. Der Workflow muss nicht identisch sein, aber wir müssen abbilden, wie er funktioniert und was sich für das jeweilige Team ändert.
3. Wir wählen aus den am besten geeigneten Vorlagen, was geteilt werden soll.
4. Wir installieren Exalate auch in der Zielinstanz.
5. Wir wählen mit Exalate alle zu kopierenden Vorgänge.
6. Wir passen die Regeln für die Jira-Synchronisation durch Scripting an.
7. Falls erforderlich, holen wir uns Unterstützung beim Exalate-Team.
Option C: Jira-Vorgänge mit External Share for Jira teilen
Wenn wir einfach ein paar Vorgänge und Unteraufgaben mit ein paar Leuten und das nur für einige Tage, Wochen oder Monate brauchen, ist External Share for Jira unsere beste Wahl. Das Tool bietet eine einfache, aber granulare Kontrolle nicht nur dahingehend, welche konkreten Vorgänge für wen zugänglich sein sollen, sondern auch im Hinblick darauf, wie lange dieser Zugriff besteht und was genau Externe sehen, kommentieren und mit Anhängen versehen können.
Alle Links lassen sich mit Passwörtern schützen und alle Berechtigungen können jederzeit auf Knopfdruck widerrufen werden. Für den Seelenfrieden haben Admins einen klaren Blick darauf, was geteilt wird, wie viel Zugriff welche Externen haben und wie lang das Standard-Zeitlimit für das Teilen ist. Wer also keine kompletten Projekte teilen möchte, für den ist External Share for Jira eine sichere und schnell aufzusetzende Lösung.
Es gibt auf dem Atlassian Marketplace auch eine kostenfreie Version, um den Zugang zu Jira oder Confluence sicher zu teilen.