Zum Hauptinhalt springen
Kontakt
Mit GitLab deinen eigenen Weg gehen
In sozialen Netzwerken teilen

Mit GitLab deinen eigenen Weg gehen

Val Naipaul
Val Naipaul
23. Januar 2024
11 Min. Lesezeit
Ein Mann mit einem Schlüssel schaut auf ein Schloss
Val Naipaul
Val Naipaul
23. Januar 2024
11 Min. Lesezeit
Zum Abschnitt springen
Gängige Ansätze
Vorgeschlagener Ansatz
Wie wäre es mit Auto DevOps?
Wenn du auf der Plattformseite und/oder mit DevOps arbeitest und vor einer Migration oder Implementierung von GitLab (SaaS oder selbstverwaltet) stehst, fällt dir vielleicht auf, dass GitLab eine Menge Regler und Schalter hat.
GitLab ist eine sehr umfangreiche Plattform, die mit ihrem VCS, den CI/CD-Pipelines, der Paketverwaltung, der Analyse der Softwarezusammensetzung, den Planungsfunktionen und vielem mehr alle deine Anforderungen abdeckt.
Aber musst du alle Funktionen implementieren, um erfolgreich zu sein? Vor allem die Bereitstellung von „GitLab Runnern“ in der Cloud hat Auswirkungen auf dein Geschäftsergebnis.
In diesem Blog schlagen wir einen Ansatz zur Planung einer GitLab-Migration oder -Implementierung vor, der den Stakeholdern schneller Mehrwert bietet und den Teams ermöglicht, sich auf ihre Weise mit GitLab zu beschäftigen, ohne unbedingt gleich voll durchzustarten.

Gängige Ansätze

Bevor wir uns mit unseren Vorschlägen für eine GitLab-Migration oder -Implementierung befassen, schauen wir uns einige gängige Ansätze an, um einen besseren Überblick zum Thema zu erhalten. Und vielleicht ist einer davon sogar für deine Situation am besten geeignet.
Big Bang (Migration)
Der „Big Bang“-Ansatz umfasst Iterationen von Analyse, Konfiguration, ETL und Validierung. Dabei werden möglicherweise zunächst repräsentative Quellinhalte verwendet, gefolgt von der Migration des gesamten Quellinhalts, die schließlich in einer „Big Bang“-Migration gipfelt.
Der Hauptvorteil dieser Vorgehensweise besteht darin, dass es einen klaren Übergabepunkt für alle Beteiligten gibt. Allerdings wird der Nutzen bis zu diesem Übergabepunkt aufgeschoben. Der iterative Charakter dieses Ansatzes kann zudem strukturelle Ineffizienzen in Form von zusätzlichem Aufwand für die Migrationsiterationen verursachen.
Inkrementell, phasenweise (Migration)
Bei einem inkrementellen Ansatz wird der Quellinhalt schrittweise partitioniert und migriert. Dies kann immer noch iterativ erfolgen, wie beim Big-Bang-Ansatz, jedoch mit überschaubareren Iterationen.
Bei einem phasenweisen Ansatz werden die Fähigkeiten der Zielumgebung in Phasen aktiviert, wobei jede Phase auf den vorherigen aufbaut.
Bei beiden Ansätzen wird der Mehrwert schneller realisiert als bei der Big-Bang-Methode. Allerdings sind sowohl die Quell- als auch die Zielplattform über einen längeren Zeitraum hinweg gleichzeitig aktiv, von der ersten bis zur letzten Phase, was belastend und verwirrend werden kann.
Plattform-Engineering mit Self-Service (Migration/Implementierung)
Beim Plattform-Engineering mit Self-Service-Ansatz legt ein Expertenteam die Grundlagen (Konfiguration, Automatisierung, Leitlinien) fest, damit Entwicklerteams GitLab selbst nutzen können, sei es bei der Migration von Inhalten, beim Onboarding oder beim Start neuer Projekte mit zugelassenen und empfohlenen Vorlagen.
Dieser Ansatz kann zwar auch ohne ein Framework für eine standardisierte Entwicklererfahrung, d. h. eine interne Entwicklerplattform (IDP), funktionieren, aber da er sich auf gemeinsames Wissen und Teamdisziplin stützt, kommt er mit einer solchen erst richtig zur Geltung. Zu den IDP-Optionen gehören Backstage, Compass, Venue.sh und GitLab selbst.

Vorgeschlagener Ansatz

Ein wertorientierter, Shift-Left-Ansatz für die GitLab-Migration oder -Implementierung
Der von uns vorgeschlagene Ansatz legt den Schwerpunkt darauf, den Stakeholdern einen Mehrwert zu bieten und gleichzeitig das Tempo der Implementierung so zu gestalten, dass eine zuverlässige Einbindung von Benutzern und GitLab gewährleistet ist.
Wenn deine Teams zum Beispiel GitLab Review Apps für die Zusammenarbeit nutzen wollen (und vielleicht auch, um die Kosten für ihre Infrastruktur zu senken), könntest du die Integration externer Repositories als Überbrückung in Betracht ziehen, um Review Apps zu umgehen, bevor die Git-Repositorys vollständig migriert wurden oder sogar bevor die Migration begonnen hat.
In einigen Bereichen kann es sinnvoll sein, die Einführung zu beschleunigen, während es in anderen Bereichen von Vorteil sein könnte, die Einführung zu bremsen. Das betrifft z. B. das automatische Spiegeln von Fehlern aus einem etablierten Planungstool in GitLab Team Planning. Dies ermöglicht es den Entwicklern, in ihrem eigenen Tempo mit minimalen Unterbrechungen wechseln.
Übrigens, auch wenn sie normalerweise im Zusammenhang mit der Implementierung/Migration von Plattformen nicht zum Einsatz kommt, ist die „Shift Left“-Denkweise das Herzstück dieses Ansatzes. Du wirst den Plan erweitern, um die verschiedenen Stakeholder und ihre Anliegen (z. B. Kosten, Entwicklererfahrung) neben den normalen Anliegen der Plattformimplementierung/Migration zu berücksichtigen.
Allgemeine Grundsätze
Dieser Ansatz beinhaltet, dass du zuerst deine Kriterien für den Erfolg mit GitLab identifizierst und diese dann anhand von drei Attributen priorisierst:
  1. Wichtigkeit/Dringlichkeit oder „Größe“
  2. Implementierungskosten
  3. Traktion (das erforderliche Personal, Know-how und Engagement)
Wenn du mit der Migration oder Implementierung nach den festgelegten Prioritäten vorgehst, kannst du den Beteiligten schneller einen Mehrwert bieten und gleichzeitig die Begeisterung der Teams für GitLab fördern.
Lege deine Erfolgskriterien fest.
An welchen Kriterien wird der Erfolg gemessen (von allen Beteiligten, nicht nur von deinem Team)? Identifiziere mindestens zwei Kriterien, aber nicht mehr als fünf.
Deine Kriterien, wie zum Beispiel die bekannten DORA-Metriken, können mit DevOps verknüpft werden. Aber bedenke, dass es dabei um deine Umgebung geht: Sind Sicherheits- und Compliance-Aspekte ausschlaggebend? Welchen Stellenwert haben Stringenz und Transparenz bei Tests?
Lege deine Kriterien für den Erfolg fest und kombiniere sie mit den Funktionen von GitLab.
Für jedes Erfolgskriterium solltest du Folgendes tun:
  1. Weise eine Zahl zu, die die relative Bedeutung repräsentiert, wobei 1 für die geringste Bedeutung steht (wichtigere/dringlichere Kriterien haben eine höhere Priorität). Lass Lücken zwischen den Kriterien, um relative Werte besser abzubilden, z. B. 1, 2, 3, 5, 10.
  2. Weise eine Zahl zu, die die relativen Umsetzungskosten (einschließlich Tools und Prozesse) für den Übergang vom Ist- zum Soll-Zustand (in Bezug auf das Kriterium) repräsentiert, wobei 1 für das höchste Kriterium steht (Kriterien mit geringeren Umsetzungskosten haben höhere Priorität). Denke beim Zielzustand kurz- bis mittelfristig, aber achte darauf, dass du ambitioniert bist – das Ziel zu erreichen, sollte sich wie ein Erfolg anfühlen.
  3. Weise eine Zahl zu, die die relative Traktion repräsentiert, wobei 1 für die geringste Bedeutung hat (Kriterien mit der höchsten Traktion haben eine höhere Priorität). Frage, ob du über das Personal, das Know-how und das Engagement verfügst, um Gewinne zu erzielen.
  4. Nun bewerte die Kriterien im Vergleich zueinander anhand des Produkts aus ihrer Größe, den Kosten und der Traktion, wobei höhere Prioritäten mit höheren Zahlen versehen werden.
  5. Identifiziere relevante GitLab-Funktionen, die helfen (oder behindern) könnten, und erkläre, wie. Beginne mit einem inklusiven Ansatz und verbessere ihn bei Bedarf, möglicherweise in Absprache mit den Beteiligten.
Alles klar!
Zum Beispiel:
Erfolgskriterium – Zusammenarbeit
  • Größe – 5
  • Kosten – 4
  • Traktion – 4
  • Wert – 80
Relevante GitLab-Funktionen
Erfolgskriterium – Betriebskosten
  • Größe – 1
  • Kosten – 3
  • Traktion – 3
  • Wert – 9
Relevante GitLab-Funktionen
Erfolgskriterium – Betriebskosten
  • Größe – 3
  • Kosten – 1
  • Traktion – 1
  • Wert – 3
Relevante GitLab-Funktionen
Siehe Beispiel im Tabellenformatarrow icon

Wie wäre es mit Auto DevOps?

Aber wie wäre es mit Auto DevOps? Berücksichtigt es nicht verschiedene Branching-Modelle, Entwicklungsmethoden und Historien – also nicht einheitlichen Inhalt? Könnten wir diese Priorisierung nicht einfach überspringen und alles gleichzeitig mit Auto DevOps bereitstellen (abgesehen von den Cloud-Betriebskosten)?
Nein, und nein: Auto DevOps (das nur eine Reihe von kuratierten Pipeline-Jobs ist) eignet sich gut als Modell und Ausgangspunkt für DevSecOps, und ist gut für die Anpassung und/oder Inspiration für eigene wiederverwendbare CI/CD-Komponenten und CI/CD-Katalog, aber es ist kein „Modell von“, sondern nur ein „Modell für“.
Zum Abschluss
Wir hoffen, dass du dich mit diesem Blogbeitrag besser gerüstet fühlst, um mit einer GitLab-Migration oder -Implementierung fortzufahren, unabhängig davon, ob es sich um eine SaaS-Lösung oder eine selbstverwaltete Lösung handelt, und dass du eine breitere Perspektive für die Planung eines erfolgreichen Ergebnisses in deiner Umgebung hast.
Mit dem von uns vorgeschlagenen Ansatz – der Priorisierung deiner Erfolgskriterien nach ihrer jeweiligen Größe, ihren Implementierungskosten und ihrer Traktion – werden deine Stakeholder den Nutzen von GitLab schneller erkennen. Deine Benutzer werden eine sinnvolle Zusammenarbeit mit GitLab genießen, wenn sie sehen, dass ihre Bedenken bei der Implementierung berücksichtigt werden.
Wie oben erwähnt, gibt es in GitLab eine Menge Regler und Schalter. Um die besten Ergebnisse mit dem von uns vorgeschlagenen Ansatz für die Migration oder Implementierung von GitLab zu erzielen, solltest du dir alle angebotenen Funktionen genau ansehen (und dabei auf den jeweiligen Abonnementplan – Premium oder Ultimate – achten). Auf diese Weise weißt du, welche Funktionen deine Erfolgskriterien am besten unterstützen.

Nimm Kontakt mit uns auf, um mehr zu erfahren!

Verfasst von
Val Naipaul
Val Naipaul
Principal DevOps Consultant
Val wendet DevOps-Denkweisen auf reale Probleme an, entwickelt unsere DevOps-Praxis weiter und teilt Ideen und Erfahrungen mit Kunden und Partnern. Val liebt es, mit unterschiedlichen Hintergrundgeschichten und Perspektiven zu arbeiten, um Innovationen voranzutreiben.
Cloud