Serie | Data Integration (Migration & ETL) – Schritte zur erfolgreichen Umsetzung eines DevOps-Projekts: Tools, Techniken und Best Practices
Die Implementierung eines DevOps Projektes kann eine Herausforderung sein, wenn sie noch nie zuvor damit gearbeitet haben. In diesem Artikel werden wir Ihnen die grundlegenden Schritte zur Umsetzung eines DevOps-Projektes aufzeigen und die verschiedenen Bestandteile erklären. Im Folgenden werden Ihnen die Tools und Techniken beschreiben, die Sie benötigen, um Ihre Ziele zu erreichen.
Die ersten fünf Schritte in Azure DevOps
Beginnen sie mit den Ersten fünf Schritten um ein neues Projekt aufzusetzen. Voraussetzung fürs Starten eines neuen Projektes ist eine Basic Lizenz mit einer Organisation. Falls sie diese noch nicht haben, besuchen Sie unseren Impuls. Außerdem müssen sie Mitglied der Gruppe Mitwirkender oder Projektadministratoren sein.
- Richtige Seite und Organisation finden: Öffne die Azure DevOps-Website azure.com und melden Sie sich mit Ihrem Konto an. Wählen Sie die richtige Organisation aus, bei der das Projekt durchgeführt werden soll.
- Erstellung eines Projektes: Klicken sie auf Neues Projekt in der linken Navigationsleiste, um ein neues Projekt zu erstellen.
- Auswahl des Projektprozess: Geben sie Ihrem Projekt einen passenden Namen und eine kurze Beschreibung und wählen sie aus, welche Art Projekt sie haben wollen (SCRUM, CMMI, …). Wenn Sie nicht wissen, was Sie auswählen sollen, lesen Sie bitte den folgenden Abschnitt.
- Auswahl der CI/CD Konfiguration (Optional, Falls Sie mit Code arbeiten): Wählen sie aus, ob sie sich mit einem Git Repository oder einem bereits vorhanden verknüpfen möchten
- Teammitglieder hinzufügen: Fügen Sie Mitglieder hinzu, die am Projekt arbeiten sollen, indem Sie Ihre E-Mail-Adressen eingeben oder vorhandene Mitglieder auswählen (weitere Erläuterungen folgen)
Wie wähle ich meinen Projektprozess in Azure DevOps aus?
Agile
- Eignet sich gut für Projekte mit kontinuierlich sich ändernden Anforderungen, wo man das Agile Manifesto einhalten möchte,
- Ermöglicht Verwaltung von Aufgaben in einem flexiblen Backlog, Priorisierung und iterative Entwicklung
- Erfordert Selbstorganisation im Team
SCRUM
- Eignet sich für größere Teams, die innerhalb des SCRUM Frameworks arbeiten möchten
- Verlangt feste Rollen wie SCRUM Master, Product Owner, etc… sowie regelmäßige Meetings (Daily SCRUM, Sprint Review, etc…)
- Gut für Projekte, die in festem Zeitraum absolviert werden sollen und Teams mit klaren Rollen, wo eine enge Kollaboration gewünscht ist
Basic
- Eignet sich für kleine Projekte und Teams
- Vereinfachte Version des Agile-Prozesses
- Einfach und leicht zu verstehen, d.h. gut geeignet für Teams ohne agile Erfahrung
- Wenig Funktionen und keine formale Projekmanagementstruktur
- Bietet nur grundlegende Funktionen wie Aufgabenverwaltung und Iterationen
Was ist ein Work Item in DevOps?
Jedes Work Item basiert auf einem Work Item-Typ, der bestimmt, welche Work Item-Felder für die Nachverfolgung von Informationen zur Verfügung stehen. Welche Work Item-Typen Ihnen zur Verfügung stehen, hängt von dem Projektprozess ab, der bei der Erstellung Ihres Projekts verwendet wurde: Agile, Basic, Scrum oder CMMI.
Neues Work Item hinzufügen
Um Arbeit zu ihrem Projekt hinzuzufügen, müssen sie wissen, wie man ein Work Item hinzufügen kann. Um eines zu erstellen, gehen sie innerhalb ihres Projektes im linken Menü zu Azure Boards -> Work Items -> New Work Item. Die Drop down liste gibt Ihnen die vorhandenen Typen zur Auswahl.
DevOps Projekt Prozess – Hierarchie
In einem Projekt hat jedes Work Item einen zugewiesenen Typ, den Sie bei der Erstellung selbst definieren. Um Ihrem Projekt eine Struktur zu geben, wird von Microsoft für jeden Projektprozess eine Hierarchie vorgeschlagen.
Nachfolgend die Struktur für den Agile-Prozess:
Azure DevOps verwendet eine bereits bekannte Hierarchie, die sich an der agilen Softwareentwicklung orientiert.
Epics
Ein Agile Epic ist ein umfangreiches Werk, das über mehrere Sprints geliefert wird. Häufig werden Sie oft durch einen Business Case unterstützt und sind wichtige Arbeiten, die einen strategischen Mehrwert schaffen.
Epics helfen Organisationen, ihre Arbeit aufzuschlüsseln und zu organisieren, während sie weiter auf ein größeres Ziel hinarbeiten.
Beispiele:
- Kundenbindung stärken
- Verbesserung und Vereinfachung der Benutzer Oberfläche einer App
- Implementierung einer neuen Hub-and-Spoke Architektur
- Datalake Aufsetzung
Feature
Ein Feature ist ein Stück Arbeit aus dem Epic – eine Leistung, die einen Mehrwert schafft und zur Vervollständigung des Epic beiträgt.
Ein Feature sollte:
- einen Geschäftswert liefern
- es sollte abschätzbar sein – es muss ausreichend definiert sein, damit das Team eine Schätzung des Arbeitsaufwands für die Implementierung abgeben kann
- klein genug sein, um in 1 bis 3 Sprints zu passen – wenn es also zu groß ist, sollte es weiter heruntergebrochen werden
- testbar sein – Sie sollten wissen, welchen Test eine Funktion bestehen muss, damit sie um für den Kunden akzeptabel zu sein.
Beispiele:
- Hinzufügen eines mobilen Einkaufwagens
- Hinzufügen E-Mail-Benachrichtigung Funktionalität
- Erweiterung der Ansichtsoptionen des Berichtes
- Alle Software auf Schwachstellen prüfen
User Stories
Eine User Story ist die kleinste Arbeitseinheit in einem agilen Framework. Sie sind kurze Anforderungen oder Anfragen, die aus der Perspektive eines Endbenutzers geschrieben werden. Sie können auch Enabler-Tasks sein, die die Arbeit an einer Fertigstellung einer Funktion unterstützen. Stories sind Dinge, die Teams normalerweise innerhalb eines einzigen Sprints erledigen können. Der Zweck einer User Story besteht darin, darzulegen, wie ein Teil der Arbeit dem Kunden einen bestimmten Wert zurückgibt. Beachten Sie, dass “Kunden” nicht unbedingt externe Endbenutzer im traditionellen Sinne sein müssen, sondern auch interne Kunden oder Kollegen innerhalb Ihrer Organisation sein können, die von Ihrem Team abhängig sind.
Beispiele:
- Als Manager möchte ich die Kapazität meiner Kollegen visualisieren können, damit ich besser über unsere Erfolge und Misserfolge berichten kann.
- Als Kunde möchte ich meine Reservierung jederzeit stornieren können, damit ich kein Geld verliere, wenn es zu Störungen kommt.
- Als Student möchte ich eine Bestätigung erhalten, wenn ich ein Dokument hochlade, damit ich zur Sicherheit es nicht mehrmals hochladen muss
Anatomy of a Work Item – “Task” example
Unter allen verfügbaren Feldern sind einige entscheidend und müssen von jedem bekannt sein:
State / Status: Der aktuelle Zustand des Work Items. Dieses Feld ermöglicht es Ihnen, den Status eines Work Items zu aktualisieren, während es sich von einem neuen oder aktiven Zustand zu einem abgeschlossenen oder geschlossenen Zustand entwickelt (geschlossen – Work Item nicht relevant/ alternative Lösung gefunden)
Reason / Grund: Der Grund, warum sich das Work Item im aktuellen Zustand befindet. Jeder Übergang von einem Workflow-Zustand zu einem anderen ist mit einem entsprechenden Grund verknüpft. Für einen CMMI-Prozess wird der Grund standardmäßig definiert und kann nur im Fall eines aktiven Zustands geändert werden: Untersuchen oder Akzeptieren.
Area/ Bereich: Bereichspfade ermöglichen es Ihnen, Work Items nach Team, Produkt oder Funktionsbereich zu gruppieren. Beispiele können sein: „Support“, „IT“. „Data Eng.“, etc…
Iteration: Iterationspfade ermöglichen es Ihnen, Arbeit in Sprints, Meilensteine oder andere ereignisspezifische oder zeitbezogene Zeiträume zu gruppieren.
Related Work: Jedes Work Item kann mit anderen über verschiedene Links verbunden werden. Ein Work Item kann mit anderen über verschiedene Links verbunden werden. Ein Work Item kann Eltern, Kinder, Vorgänger haben, der Nachfolger eines anderen Work Items sein. Diese Beziehungen sind wichtig für die Erstellung von Lieferplänen und Sprints.
Discussion / Diskussion: Dieses wichtige Feld ist dazu gedacht, eine isolierte Kommunikation über den spezifischen Work Item-Typ zu ermöglichen, bei dem Sie andere Mitglieder informieren können. Erwähnungen sind mit dem Symbol @ möglich, bei dem Sie andere Mitglieder oder Teams markieren können, um effizienter zusammenzuarbeiten
Folgende Zustände kann eine Task annehmen:
Genehmigungen und Zusammenarbeit – Projekt mit dem Team in Azure DevOps koordinieren
Um bei Azure DevOps zusammenzuarbeiten, muss jedes Mitglied entweder auf organisatorischer Ebene für eine Multi-Projekt-Teilnahme oder direkt auf einer einzelnen Projekt-Ebene per E-Mail eingeladen werden. Nur der Organisationsbesitzer kann auf einer organisatorischen Ebene Einladungen senden.
Organisations-Ebene
Auf dieser höchsten Ebene gibt es zwei Arten von Mitgliedern, die dem Lizenzierungsschema entspricht und die Funktionen festlegt, die die Nutzer erhalten.
- Basic: erhalten die meisten Funktionen und entsprechen einer “Voll”-Lizenz für Azure DevOps. In der Regel sind die Benutzer kostenpflichtig.
- Achtung: Der Begriff Basic ist irreführend, da diese in der Regel als “Vollständiger”-Benutzer bezeichnet werden.
- Bemerkung: Benutzer in der M365 Organisation mit Visual Studio Enterprise Lizenzen bekommen automatisch Basic Lizenzen in Azure DevOps. Auch wenn sie im System anders eingetragen sind, erhalten sie die gleichen Features wie andere Basic-Nutzer.
- Stakeholder: Kostenlose unbegrenzte Benutzer, haben jedoch eingeschränkte Features.
Die Einschränkungen als Stakeholder sind folgendes:
- Hinzufügen von Arbeitsaufgaben-Tags
- Ändern der Priorität eines Elements
- Löschen von Arbeitsaufgaben
- Anzeigen oder Einstellen der Teamkapazität
- Hinzufügen von Aufgaben zu einem Sprint-Backlog
- Ändern von Feldern auf Karten auf einem Board, außer dem Feld “State”
- Ziehen und Ablegen von Arbeitsaufgaben im Backlog
Projekt-Ebene
Auf Projektebene werden Berechtigungen über Berechtigungsgruppen vergeben. Innerhalb eines Projekts sind die Mitglieder in Teams unterteilt.
Jedes Projekt hat automatisch ein Standardteam, dem jedes Mitglied hinzugefügt wird.
Es gibt verschiedene Grade von Zugriffsrechten für alle Mitglieder:
- Reader/Projekt gültige Benutzer: können alle Arbeitsaufgaben ansehen, können sie jedoch nicht löschen/hinzufügen/ändern. Für Azure Boards haben beide Gruppen dieselben Berechtigungen –> Nur Lesezugriff
- Contributor: kann alle Arbeitsaufgaben ansehen, hinzufügen, ändern, löschen –> Lese-/Schreibzugriff.
- Bemerkung: Alle neuen Mitglieder sind standardmäßig an diese Gruppenberechtigung gebunden.
- Build-Administrator/Projektadministrator: Für Azure Boards haben beide Gruppen das gleiche Niveau an Rechten. Es umfasst alle Rechte des Contributors sowie: Verwalten von Benutzerberechtigungen, Erstellen oder Bearbeiten von Teams, Ändern von Teameinstellungen, Definieren von Bereichs- und Iterationspfaden oder Anpassen der Arbeitsaufgabenverfolgung, Hinzufügen und Entfernen von Benutzern aus der Projektmitgliedschaft, Hinzufügen und Entfernen von benutzerdefinierten Sicherheitsgruppen –> Lese-/Schreibzugriff + Management Role
- <Teamname>: Bei der Projekt Erstellung wird auch das Standardteam als Gruppenberechtigung hinzugefügt, das unabhängig von allen anderen Gruppenberechtigungen angepasst werden kann.
Delivery Plans: Projekte aus der Vogelperspektive betrachten
Um insbesondere mit nicht-technischem Personal besser zusammenarbeiten zu können, ist es hilfreich, Ihrem Projekt einen Delivery Plan hinzuzufügen.
Beim Hinzufügen eines neuen Delivery Plans sollten Sie folgendes beachten
- Überlegen Sie sich welche Teams und Mitglieder an dem Projekt beteiligt sein werden und stellen Sie sicher dass diese die erforderlichen Berechtigungen und Zugriffsrechte bekommen
- Definieren Sie Aufgaben und Meilensteine, welche erfasst werden sollen. Legen Sie Start- und End Daten fest und weisen die Aufgaben den entsprechenden Teams/ Mitarbeitern zu.
- Behalten Sie den Delivery Plan im Auge und aktualisieren Sie ihn regelmäßig, um den Fortschritt des Projektes zu verfolgen
Um einen Delivery Plan hinzuzufügen, gehen Sie im rechten Menü zu Azure Boards und wählen Sie Delivery Plan aus. Klicken Sie dann auf Hinzufügen.
Der Delivery Plan ordnet sich nach Backlog Level Items mit einer Zeitachse, entsprechend den Daten, die in den entsprechenden Feldern ihrer Karten aufgeführt sind (siehe “Anatomie eines Arbeit Elements“).
Ein Delivery Plan ist wie folgt aufgebaut:
- Delivery Plan Titel
- Filtern nach Typ, Zugewiesen an, Status, Bereich, Iteration und Tag
- Einstellungen
- An dieser Stelle können sie unter anderem weitere Teams oder work items hinzufügen, die Ihnen im selben Delivery Plan angezeigt werden
- Plan skalieren
- Felder zusammenklappen oder erweitern
- Makers
- Der blaue today Maker ist immer per default gesetzt. Hinzufügen können sie individuelle Maker via Settings
- Team und Work Item Name
- Hier können sie weitere Work Items zu dem angegebenen Sprint hinzufügen
Fazit Azure DevOps
Die Implementierung eines DevOps-Projekts kann eine Herausforderung sein, aber mit den richtigen Schritten, Tools und Techniken können Sie erfolgreich sein. Indem Sie die richtige Projektorganisation auswählen, die CI/CD-Konfiguration festlegen, Teammitglieder hinzufügen und die Hierarchie der Work Items verstehen, legen Sie den Grundstein für ein effizientes und kollaboratives Projektmanagement. Durch die Nutzung von Azure DevOps und die Zusammenarbeit in Teams können Sie den gesamten Projektablauf optimieren und die Lieferzeiten verkürzen. Halten Sie sich an bewährte Methoden wie Agile, Scrum oder den Basic-Prozess und nutzen Sie Delivery Plans, um das Projekt aus einer Vogelperspektive zu betrachten. Mit diesen Schritten können Sie die Vorteile von DevOps voll ausschöpfen und erfolgreich in Ihre Projekte implementieren.
Interessiert an Azure DevOps? Schauen Sie sich unsere DevOps Projektmanager Schulung an.
Übersicht der Data Integration (Migration & ETL) Serie:
- Einführung in Microsoft Azure Data Factory
- Einführung in Azure DevOps
- Schritte zur erfolgreichen Umsetzung eines DevOps-Projekts: Tools, Techniken und Best Practices
- Einführung & Anwendungsbeispiel in Databricks
- Einführung & Anwendungsbeispiele in Microsoft Fabric
Haben wir Ihr Interesse geweckt? Kontaktieren Sie uns!
Ihr Ansprechpartner
