Atlassian-basierte DevOps-Transformation

Lösung

Wir haben Atlassian-Beratungsdienstleistungen geliefert, die in folgende Initiativen unterteilt sind:

• Eine kollaborative DevOps-Umgebung auf der Basis des Atlassian-Stacks zu schaffen.
• Die Implementierung von Atlassian-Tools zur Optimierung und Automatisierung der damit verbundenen Release-Management-Vorgänge.
• Um Atlassian-Tools für die Identifizierung potenzieller Abhängigkeiten zwischen IT-Projekten und die Bewertung ihrer Auswirkungen auf das Geschäft zu nutzen.

Werkzeuge für die Zusammenarbeit

Unser Team analysierte die bestehenden Prozesse und Hauptphasen in der DevOps-Kette des Kunden und schlug Lösungen vor, um die Zusammenarbeit zu fördern, Releases zu beschleunigen und die Qualität in jeder Phase des Softwareentwicklungslebenszyklus (SDLC) des Kunden kontinuierlich zu verbessern.

Die Phase der Anforderungsanalyse

Unsere Atlassian-Experten entdeckten in dieser Phase die folgenden Probleme:

• Kein zentraler Ort zum Speichern und Verwalten von Anforderungen, was die Nachverfolgung und gemeinsame Nutzung erschwerte.
• Kein Benutzer- und Berechtigungsmanagement sowie fehlende Automatisierungs- und Integrationsmöglichkeiten in Atlassian Confluence.

Um die festgestellten Probleme zu lösen, schlugen wir vor, Confluence als zentralen Ort für alle Projektanforderungen und -dokumente zu nutzen und Atlassian Access in Verbindung mit allen anderen Atlassian-Tools einzusetzen. Außerdem schlugen wir vor, eine gruppenbasierte Benutzerverwaltung anzuwenden, anstatt einzelne Benutzer hinzuzufügen.

Die Entwicklungsphase

Wir haben folgende Schwachstellen festgestellt:

• Unterschiedliche Konfigurationen und Regeln in Bitbucket-Instanzen, die auch allgemeine Probleme bei der Repository-Verwaltung enthielten.
• Inkonsistente und ineffiziente Nutzung von Jira Software in Bezug auf Tracking, Sprintpläne und Sicherheit.

Wir verknüpften Jira Software mit Bitbucket für alle Projekte, um eine einzige Ansicht der Feature-Entwicklung zu erhalten. Dadurch konnten die Benutzer Jira-Probleme in Bitbucket anzeigen und Bitbucket-Aktivitäten in Jira anzeigen, Jira-Workflows automatisieren und Jira-Software-Projekte in Verbindung mit Repositories anzeigen. Um Kosten zu sparen, wurden alle Bitbucket-Instanzen zu einer einzigen Instanz zusammengeführt.

Unsere Experten rieten dem Kunden, Jira, Confluence und Bitbucket für alle SDLC-Phasen zu verwenden und vorbereitete Projekt-Workflow-Vorlagen zu nutzen. Außerdem empfahlen wir eine regelmäßige externe Überwachung durch ein technisches oder Managementteam, um die Einhaltung der Richtlinien zu gewährleisten. Um die Integrationsmöglichkeiten für alle Teamtypen und Tools optimal zu nutzen, schlugen wir die Integration von Jira und Bitbucket mit Azure DevOps Services vor.

Die Build/Release-Phase

Wir haben die folgenden Probleme festgestellt:

• Automatisierung und Integration wurden kaum genutzt.
• Die Jira-Release-Management-Funktionalität, einschließlich Release-Planung und -Dokumentation, wurde nicht in allen Projekten genutzt.
• Die vorhandenen Tools des Kunden passten nicht vollständig in eine vollautomatische Bereitstellungspipeline.
• Es gab keinen etablierten Prozess zum Wissensaustausch.

Um diese Probleme zu lösen, nutzte unser Team die Integration zwischen Bitbucket-Pipelines, Jira Software, dem Testmanagementsystem Tosca zum Auslösen automatisierter Tests und anderen Produkten für den Build- und Release-Prozess. Dies half bei der Planung von Releases, der Bewertung und Freigabe von Projektfortschritten und der Verfolgung von Änderungen. Wir rieten dem Kunden auch, Rückrufe zu Bitbucket zu verwenden, um Build-, Test- und Validierungsinformationen vor einer manuellen Überprüfung bereitzustellen.

Die Betriebsphase

Unsere Analyse ergab einige Probleme:

• Unvollständige Integration zwischen dem Service-Management-System ServiceNow des Kunden und den übrigen Tools.
• Verstreute und fehlende Daten aufgrund einer zu großen Anzahl nicht miteinander verbundener Prozesse und Tools.
• Keine gemeinsame Wissensbasis, die die Prozesse und Regeln der Betriebsphase beschreibt.

Wir ermutigten den Kunden, Jira Service Desk als Lösung für das kollaborative Servicemanagement zu verwenden und es mit anderen Tools aus den SDLC-Phasen, einschließlich Salesforce, zu verbinden. Alternativ schlugen wir vor, die bestehende Service-Management-Software des Kunden mit Jira Software und Confluence zu integrieren. Wir empfahlen außerdem, Confluence als zentralen Ort für den Wissensaustausch und als Repository für Richtlinien zur Fehlerbehebung zu nutzen.

Unser Team schlug vor, die Onboarding- und Offboarding-Prozesse toolübergreifend mit Hilfe einer vordefinierten HR-Projektvorlage von Jira Service Desk oder benutzerdefinierten Workflows anzupassen. Diese Regeln halfen den Betriebs- und Entwicklungsteams, enger zusammenzuarbeiten, wobei das Feedback über alle Projekte hinweg gesammelt wurde und an einem einzigen Ort verfügbar war.

Grundsätze der Zusammenarbeit

Der Kunde arbeitete mit geografisch verteilten Teams über mehrere Zeitzonen hinweg. Außerdem wurden unterschiedliche Tools und Prozesse eingesetzt, die die Zusammenarbeit entscheidend beeinflussten, wobei die Automatisierung und Integration in allen SDLC-Phasen die wichtigsten Themen waren.

Um das Problem zu lösen, wechselten alle Teams des Kunden zum Atlassian-Stack, um eine transparente teamübergreifende Zusammenarbeit in jeder Phase des Entwicklungslebenszyklus zu ermöglichen, das Feedback zwischen den Teams zu verbessern und Probleme schnell zu erkennen und zu beheben. Automatisierte Benachrichtigungen minimierten menschliche Fehler und verhinderten, dass Teammitglieder wichtige Aufgaben oder Updates zum Projektfortschritt verpassten. Wir optimierten die Zusammenarbeit durch die Integration von Microsoft Teams des Kunden mit Jira Software, Confluence, Bitbucket und Jira Service Desk.

Automatisierte Bereitstellung

Zusammen mit den Salesforce-Teams des Kunden haben wir den bestehenden Workflow für Salesforce-Releases bewertet und eine Roadmap für die Implementierung durch Atlassian definiert. Ziel war es, das Release Management zu optimieren und zu automatisieren und dabei die Nachvollziehbarkeit der Prozesse zu gewährleisten.

Bei der Analyse stützten wir uns auf die bestehende Einrichtung, Konfiguration und Nutzung der für das Release-Management verwendeten Atlassian-Produkte. Die Experten von Itransition untersuchten die Details des Release-Managements ausgewählter Projekte, identifizierten alle Engpässe und erstellten einen Verbesserungsbericht, der sich darauf konzentrierte, die Fähigkeiten des Atlassian-Stacks optimal zu nutzen.

Jira Arbeitsabläufe

Die Entwicklungsteams des Kunden hielten sich nicht richtig an die agilen Prinzipien und Sprintpläne und nutzten auch nicht Jira für die Planung und Verfolgung des Release-Status.

Unser Team schlug vor, alte Entwicklungsprojekte zu überprüfen und zu bereinigen, ungenutzte Code-Repositories zu archivieren und eine vorbereitete Release-Management-Vorlage in Jira zu verwenden, die die Verfolgung des Release-Status in Salesforce ermöglicht. Das Ergebnis war, dass jedes für die Entwicklung und Freigabe vorgesehene Projekt ein eigenes Jira-Projekt hatte, während die Entwicklungsteams Scrum- und Kanban-Entwicklungsworkflows sowie Versionsmanagement in Jira und Confluence verwendeten.

Wir halfen dabei, eine unternehmensweite Überwachung der Jira-Prozesse zu implementieren, um sicherzustellen, dass es für jede geplante Veröffentlichung verantwortliche Teammitglieder gab, und planten Versionsplanungs- und Retrospektivtreffen. Außerdem schlugen wir die Verwendung von Jira-Workflow-Triggern vor, um den Übergang von Problemen in Bezug auf Zweigaktualisierungen wie Commits, Pull Requests und andere zu automatisieren.

Einfluss

Unsere Analyse der Confluence-Nutzung ergab, dass es keine gemeinsamen Regeln für die Dokumentation und die Speicherung von Salesforce-Versionsinformationen gab. Außerdem fanden wir heraus, dass Entwicklungsteams bei der Veröffentlichung von Änderungen im Master-Repository automatisierte Tests ignorierten, was zusätzliche Arbeit für die Release-Manager bedeutete.

Unsere Atlassian-Experten unterstützten den Kunden bei der Erstellung eines Confluence-Bereichs zur Speicherung der gesamten Salesforce-Entwicklungsdokumentation mit Verweisen auf bestimmte Dokumente. Jedes Projekt erhielt einen eigenen Confluence-Bereich, der Projektziele und -zwecke, Teambeschreibung und Verantwortlichkeiten sowie Projektanforderungen mit Release-Planung und Release-Notizen enthielt.

Bitbucket

Bei der Untersuchung der Bitbucket-Abläufe stellten wir fest, dass ein Bitbucket-Admin die Repository-Konfigurationen nicht überwachte. Stattdessen hatte jedes Team die Berechtigung, seine eigenen Repository-Regeln und -Prüfungen zu konfigurieren, was Einschränkungen und Empfehlungen für den Entwicklungs-Workflow in diesem Zusammenhang nutzlos machte. Darüber hinaus verhinderte das bestehende Verzweigungsmodell zusammen mit zeitaufwändigen automatisierten Tests in den Systemintegrationstests (SIT) und Vorproduktionsumgebungen eine ordnungsgemäße Verfolgung von Änderungen am Code.

Fehlgeschlagene Commits wurden nicht zurückgenommen, wobei die Teams die SIT- und Vorproduktionsumgebungen synchronisierten, bevor sie ihre Änderungen in diese Zweige schoben, was dazu führte, dass Änderungen verschiedener Teams vermischt wurden und die Codevalidierung zu kompliziert war. Darüber hinaus wurden die Releases nicht mit Tags versehen, und bei einer beträchtlichen Anzahl von Commit-Meldungen fehlten die zugehörigen Schlüsselprobleme, was die Rückverfolgbarkeit von Problemen behinderte.

Um eine konsistente Benennung von Verzweigungen und Validierungsregeln zu gewährleisten, schlug das Team von Itransition vor, Leitfäden für Entwickler zur Verwendung des Verzweigungsmodells zu erstellen. Dies ermöglichte auch das Schreiben komplexerer Build-Skripte und die Automatisierung von Prozessen auf der Grundlage von Verzweigungsarten. Wir rieten dem Kunden, Feature-, Bugfix-, Hotfix- und Release-Zweige direkt aus Jira Issues zu erstellen. Gleichzeitig hatten einzelne Teams eine eingeschränkte Berechtigung zur Verwaltung von Repositories, wobei nur ein Bitbucket-Admin für die Verwaltung von Repository-Konfigurationen zuständig war.

Build und Bereitstellung

Bei der Bewertung dieser Phase fiel uns auf, dass nicht alle Entwicklungs- und Testteams die Release- und Test-Workflows befolgten. Zum Beispiel war die Build-Automatisierung nicht für alle geforketen Repositories konfiguriert, so dass Bitbucket keine Build-Status für Commits empfangen und speichern konnte.

Wir schlugen vor, Release-Branch-Pipelines zu implementieren und Builds für Branch-Typen zu erstellen, wie zum Beispiel:

• Build- und Deployment-Automatisierung für Releases/Zweige durchführen
• Builds für die Arbeit mit bestimmten Repository-Umgebungen konfigurieren
• Bereitstellung von SIT, Preproduction und Production-Release aus den jeweiligen Zweigen
• Planen von Test-Pipelines
• Verwendung von Callbacks zur Kommunikation langlaufender Builds

Das Team von Transition riet dem Kunden, die Automatisierung von Build, Deployment und Test auf Bitbucket-Pipelines zu verlagern oder alternativ die aktuelle Bamboo Server-Instanz auf die neueste Version ohne Schwachstellen zu aktualisieren.

Prozessmanagement

Das Prozessmanagement des Kunden hatte mehrere kritische Nachteile. Zunächst einmal diente der Release Manager als Single Point of Knowledge und war gleichzeitig Bitbucket-Administrator, DevOps Engineer und Deployment Manager. Darüber hinaus gab es keinen gemeinsamen Release-Zeitplan, und die Dokumentation der Projektprozesse wurde außerhalb von Confluence gespeichert.

Unser Team führte eine zentralisierte Planung und Fortschrittsverfolgung in Jira und Confluence für alle Projekte ein. Die Entwicklungsteams des Kunden führten termingerecht eine technische Überprüfung der Projekte und Repositories durch, dokumentierten Schätzungen zum Projektstatus und entwarfen Pläne zur Behebung von Problemen.

Wir schlugen vor, Callbacks zu Bitbucket mit Build-Status für Tests sowie Code-Review-Regeln zu implementieren. Releases sollten wöchentlich geplant oder verworfen werden, mit anschließender Neuplanung für den Fall, dass Tests oder Reviews nicht bestanden werden. Die Rollen des Release-Managers und des Bitbucket-Administrators wurden getrennt.

Interdependenzmanagement

Im Rahmen des Projekts zum Management von Abhängigkeiten zeigte unser Team, wie man potenzielle projektübergreifende Abhängigkeiten mit Hilfe von Atlassian Jira und Confluence effektiv verwalten kann. Wir halfen bei der Einführung eines unternehmensweiten Prozesses, der die wichtigsten Schritte zur Identifizierung, Verwaltung und Verfolgung von Abhängigkeiten während des Projektlebenszyklus mit Hilfe dieser Plattformen beschreibt.

Wir erstellten auch eine Übersicht über Atlassian-Produkte und Atlassian Marketplace-Apps zur Anpassung und Erweiterung der Funktionen von Jira und Confluence und zur Verfolgung von Abhängigkeiten über Projekte hinweg. Wir haben Tools wie Jira Align, Portfolio for Jira, BigPicture, Structure for Jira und Tempo Planner ausgewählt, um die Jira Software so anzupassen, dass sie für jede Facette des Interdependenzmanagements geeignet ist und gleichzeitig eine breite Palette von Funktionen zur Steigerung der Teamproduktivität bietet.