1. Architekturstrategie

Häufig verfügen Administratorenteams über etablierte Architekturen für Enterprise-Anwendungen, inklusive Staging-Umgebungen und Failover-Konzepte. Die Informationen auf dieser Seite sollen keine Anregung dazu sein, diese unternehmensweiten Strategien zu ersetzen oder zu ändern. Vielmehr helfen sie, einige Erwägungen zu illustrieren, die den Betrieb von Atlassian-Produkten in Staging-Umgebungen betreffen.

Zunächst sollen drei zentrale Begriffe definiert werden:

• Produktion/Produktivinstanz: Die Live-Instanz mit bestens getesteten Änderungen und minimaler Downtime-Erwartung
• Staging: Eine Pre-Production-Umgebung, in der die Systemadministratoren im Vorfeld des Rollouts exakte Abläufe etablieren können
• Entwicklung: Eine für alle zugängliche Umgebung, in der Nutzer mit innovativen oder auch riskanten Änderungen experimentieren können

Wenn Ihre Atlassian-Anwendungen kritische Systeme sind, empfehlen wir die dreistufige Strategie Development, Staging und Produktion:

• Die Staging-Umgebung ist vorrangig für die Systemadministratoren vorgesehen, die dort Änderungen und Upgrades testen, befor diese in die Produktion gehen
• Die Entwicklungsumgebung steht verschiedenen Abteilungen zur Verfügung, um selbst Änderungen zu testen, bevor sie einen Rollout in die Produktivinstanz anfragen

2. Governance-Strategie

Zusätzlich zur Architektur ist die Etablierung einer Governance-Strategie für Änderungen sinnvoll. Diese könnte folgende Aspekte umfassen:

• Entwickeln Sie eine Strategie für das Umsetzen und Testen von Plugin-Installationsanfragen. Beachten Sie, dass einige extrem hilfreiche Plugins in einigen Umgebungen nicht für sog "High-volume critical Systems" geeignet sind.
• Veröffentlichen Sie eine Timeline für den Refresh der Entwicklungsumgebung, damit die Nutzer wissen, wann ihre Änderungen rückgängig zu machen sind.
• Setzen Sie eine Quellcode-Control-Repository auf, das alle Änderungen am Dateisystem enthält. So können Sie nachverfolgen, wann wo wer welche Änderungen vorgenommen hat. Halten Sie zusätzlich die Abläufe für Upgrades, Staging-Refreshs, und andere gescriptete Changesets im Code-Control-System fest. Tipp: Jira bringt ein Tool mit, um alle Änderungen in der Installation zu managen. Prüfen Sie die System-Information-Seite nach "modified files". So können Sie einsehen, welche Dateien im Installationsverzeichnis angepasst wurden.
• Für Änderungen wie die Erstellung neuer Workflows, die administrativen Zugriff erfordern, gibt es zwei Optionen:
  • Legen Sie einen administrativen Nutzer mit temporärem Zugriff auf Admin-Funktionen auf Pro-Anfrage-Basis an. Fügen sie diesen Nutzer den entsprechenden Gruppen hinzu, sodass diese die nötigen administrativen Arbeiten durchführen können. Anschließend entfernen Sie den Nutzer wieder aus diesen Gruppen.
  • Oder halten Sie den Entwicklungsserver frei von Produktionsdaten und geben Sie diesem Server mehr administrative Privilegien. Fordern Sie Endnutzer auf, spezifische Workflows und Scheme-Setups zu dokumentieren, dann wiederholen Sie diese Schritte in der Produktion.

3. Refresh eines Staging-Servers

Falls Sie noch keine bestehende Staging-Installation haben, helfen Ihnen diese Hinweise beim Aufsetzen einer solchen.

3.1. Erstellen Sie ein komplettes Backup der Produktionssystems

1. Erstellen Sie ein Backup des Home-Verzeichnisses der Produktivinstanz. Erstellen Sie auch ein Backup der Anhänge und Indexverzeichnisse im Produktivsystem, wenn sie außerhalb des Home-Verzeichnisses liegen.
2. Erstellen Sie ein Backup des Installationsverzeichnisses. Das ist das Verzeichnis, in den die Jira-Anwendungsdateien und -bibliotheken bei der Installation extrahiert wurden.
3. Erstellen Sie ein Backup der Datenbank des Produktivsystems.

3.2 Kopieren Sie das komplette Produktiv-Backup in die Staging-Umgebung

1. Fahren Sie den Staging-Server herunter.
2. Stellen Sie Ihre Installation und Home-Verzeichnisse auf dem Staging-Server wieder her.
3. Verweisen Sie das wiederhergestellte Installationsverzeichnis auf das wiederhergestellte Jira-Home-Verzeichnis.
   1. Editieren Sie die Datei Jira-application.properties im Unterverzeichnis <Jira-application-dir>/WEB-INF/classes in Ihrem neuen Installationsverzeichnis.
   2. Updaten Sie in dieser Datei das Objekt Jira.home und tragen Sie den Pfad des kopierten Jira-Home-Verzeichnisses ein.
   3. Speichern Sie die Datei Jira-application.properties.
   4. Tipp: Sie können den Ort des Jira-Home-Verzeichnisses auch adressieren, indem Sie eine Betriebssystemumgebungsvariable Jira_HOME definieren. Der Wert dieser Variable erhält Vorrang vor dem Wert des Objekts Jira.home in der Datei Jira-application.properties im Jira-Installationsverzeichnis.

4. Stellen Sie die Datenbank in einer Staging-Datenbank wieder her.

   Wenn Sie für die bestehende Jira-Installation eine Datenbank (z.B. namens Jiradb) nutzen und die Datenbank der neuen Jira-Installation auf derselben Maschine oder demselben Datenbank-Server läuft, erstellen Sie Ihre neue Datenbank unter einem anderen Namen, etwa Jiradb_440 für Jira 4.4.0. Stellen Sie sicher, dass die Zugriffsberechtigungen mit denen der alten Jira-Datenbank identisch sind.

3.3 Modifizieren Sie Ihre Staging-Umgebung für eigene Konfigurationen

1. Konfigurieren Sie Ihre Datenbankverbindung, damit sie auf die Staging-Datenbank verweist. Editieren Sie die Datei dbconfig.xml im Jira-Home-Verzeichnis oder die Datenquelle <Jira-install>/conf/server.xml für ältere Versionen. Das ist extrem wichtig. Stellen Sie sicher, dass Ihre Staging-Umgebung nicht auf die Produktivdatenbank verweist.
2. Deaktivieren Sie E-Mails auf Ihrem Staging-Server. Wenn Sie einige initiale Tests an der neuen Jira-Installation durchführen müssen, können Sie für diese den E-Mail-Access deaktivieren, um unerwünschte E-Mail-Benachrichtigungen zu vermeiden. Wenn Sie auch die E-Mail-Funktion testen wollen, können Sie natürlich auf die Deaktivierung verzichten. Dann sollten Sie jedoch folgende Aspekte beachten:
   1. Handler, die E-Mails aus Ihren produktiven Mail-Servern holen können: Diese können Sie unter Administration >> Services deaktivieren oder indem Sie die Tabelle 'serviceconfig' in der Datenbank löschen.
   2. Filter-Subscriptions, über die Nutzer Benachrichtigungen für abonnierte Filter erhalten: Löschen Sie Filter-Subscriptions aus der Tabelle 'filtersubscription' in der Datenbank.
   3. Benachrichtigungen über modifizierte Tickets: Hierfür heben Sie alle Notification-Schemes für Projekte auf, die Sie ohne E-Mail-Benachrichtigungen testen wollen.

3.4 Starten Sie den Staging-Server neu

Der Server ist nun einsatzbereit. Wenn Sie ihn neu gestartet haben, führen Sie mithilfe der folgenden Checks, dass Sie die vorherigen Schritte sicher durchgeführt haben:

1. Sicherstellen, dass die Datenbank nicht auf die Produktion verweist. Um dies zu überprüfen, siehe Viewing your System Information. Prüfen Sie die 'Database URL', um sicherzustellen, dass sie auf den richtigen ort verweist.
2. Sicherstellen, dass E-Mails deaktiviert sind. Siehe ebenfalls Viewing your System Information und prüfen Sie 'JVM Input Arguments' auf die Zeile 'atlassian.mail.senddisabled'.

3.5 Post-Startup-Modifizierungen

1. Modifizieren Sie die Farben der Instanz. Das ist sinnvoll, damit die Nutzer sofort merken, dass sie sich auf dem Staging-Server befinden.
2. Ändern Sie die URL der Instanz in die Staging-URL.
3. Berücksichtigen Sie die URL-Whitelist. Möglicherweise möchten Sie einige der zugelassenen URLs ändern und müssen dafür die Whitelist konfigurieren.
4. Fragen Sie eine Development-Lizenz an. Siehe die FAQ zur Lizenzierung von Atlassian-Produkten, um eine Lizenz für den Staging-Server zu generieren.
5. Konfigurieren Sie die Application Links neu. Wenn Sie via Application Links Verbindungen zu anderen Servern herstellen, müssen Sie die Server-ID für diese Instanzen ändern, da es ansonsten passieren kann, dass Ihre Produktivinstanz auf den Staging-Server verweist, wenn ein Link generiert wird.