Für alle, die vor der Herausforderung stehen, von einem DevOps-Toolset auf ein anderes zu migrieren, habe ich die wichtigsten Erkenntnisse zusammengestellt – mit zahlreichen Beispielen aus der Praxis. Erkenntnisse, die auf die harte oder einfache Tour gewonnen und in konkrete Handlungsempfehlungen übersetzt wurden.
Kalle Sirkesalo
Field CTO
Kalle sits at the intersection of executive strategy and engineering reality. He works directly with CTOs and engineering leaders to translate business pressures — speed, compliance, ROI — into technical decisions that actually hold. His job is to make sure what we recommend is something your organization can actually execute.
Inhaltsverzeichnis:
Welche Art von Migration planen wir?Was sind die KPIs für eine erfolgreiche Migration?Wofür ist das Migrationsteam verantwortlich?Wie migrieren die Teams selbst in die neue Umgebung?Wie verteilen wir die Kosten?Ein Beispiel: eine vollständige Migration
URL-ÄnderungenDevSecOps-PipelinesBinärspeicherEin Beispiel: Entscheidung für einen Docker Remote Proxy
Denkt ihr darüber nach, auf neue DevOps-Tools zu migrieren? Auch wenn das heute noch nicht der Fall ist – vielleicht eines Tages.
Heute gibt es großartige All-in-one-Lösungen wie GitHub, GitLab und Atlassian. Aber vielleicht geht es euch wie vielen anderen: Das Thema Migration ist schwer zu durchschauen.
Was dafür nötig ist
Wie ihr vorgeht
Wo ihr überhaupt anfangen solltet
Bei Eficode beobachten wir einen großen Wandel in der Sichtweise unserer Kunden:
Vor 10 Jahren – als wir mit unserer Eficode ROOT-Plattform gestartet sind – mussten wir erklären, warum ihr DevOps nutzen solltet.
Vor 5 Jahren mussten wir erklären, warum ihr eure DevOps-Tools zentralisieren solltet.
Heute zeigen wir euch, wie ihr eure Tools zentralisiert.
Nach mehr als 15 Jahren mit DevOps haben wir erkannt, dass nicht jeder versteht, wie schwierig der Wechsel von einer CI zu einer anderen ist.
Wir möchten euch helfen zu verstehen, wie ihr bei einer Migration Zeit und Aufwand spart und einige der häufigsten Fallstricke vermeidet. In diesem Blogbeitrag teilen wir acht wertvolle Punkte, die ihr beachten solltet.
Unser Ziel ist nicht, vollständige Antworten zu geben, sondern die Fragen aufzuzeigen, die eure Organisation stellen sollte. Die „unbekannten Unbekannten“: Was ihr wissen müsst, um zu wissen, was ihr nicht wisst.
Lest weiter und findet die richtigen Fragen und Eventualitäten, um eine reibungslose und erfolgreiche Migration zu planen.
‘migrations never fail due to technical problems’
1. Die Kultur ist noch nicht bereit
Migrationen bringen technische Herausforderungen mit sich, aber daran scheitern sie nie.
Sie scheitern an Menschen und Kultur. Viele denken, es gehe nur um eine Reihe von Tools, doch die zentrale Herausforderung ist das Management von Veränderungen. Change Management ist ein Kernbestandteil der Unternehmenskultur. Manche Unternehmen beherrschen es besser als andere. Warum ist das so wichtig? Schauen wir uns ein reales Beispiel an.
Ein Beispiel: Euer Versionskontrollsystem GitHub Enterprise von On-Premise in die Cloud migrieren
Das ist eine der einfachsten Migrationen, die ihr durchführen könnt. Ihr habt alles erledigt, und für die Nutzer ändert sich prozessual nichts. Einige Dinge funktionieren sogar einfacher als erwartet, und ihr müsst euch keine Gedanken um eure migrierten Setups machen. Dennoch muss jeder GitHub-Nutzer eine Einstellung in seiner Umgebung ändern: die URL des Repositorys. Auch alle CI/CD-Jobs enthalten diese URL.
Was tut ihr also? Schreibt ihr die Logik der DevOps-Pipeline um, damit sie das unterstützt?
Ja, das ist möglich – wir haben es getan. Aber was ist mit den Hash-Prüfungen für SSH-Authentifizierungen? Man könnte meinen, sie funktionieren, aber leider nein: Ihr müsst sie manuell freigeben.
Das führt dazu, dass ihr die Teams intensiv anleiten und antreiben müsst. Wahrscheinlich wird es Diskussionen geben wie: „Wer bezahlt für die verlorene Zeit?“, „Wir haben einen wichtigen Meilenstein verpasst“ und so weiter. In der Organisation habt ihr viel Vertrauen verspielt, weil ihr das eine einfache Update nicht gut gemanagt habt, bei dem eure Nutzer aktiv werden mussten.
Das war nur die Migration von Git-Repositories. Wie fühlen sich wohl die Nutzer von Jira, wenn ihr sie zu GitLab migrieren wollt?
Tipp: Erstellt bei Migrationen eine Übersicht der Integrationspunkte. So habt ihr eine Liste der betroffenen Systeme inklusive der URL des zu aktualisierenden Repositorys.
Um das zu lösen, geben wir unseren Kunden in der Regel folgende Ratschläge:
Bringt alle Beteiligten zusammen und informiert sie frühzeitig, um Orientierung und Unterstützung durch das Business zu schaffen. Führungskräfte können das „Warum“ der Migration erklären.
Kontinuierliche Kommunikation ist entscheidend – auch nach der Wartungsphase.
Unterstützung durch das Business setzt voraus, die Anreize zu verstehen. Die Migration sollte auf einem gut ausgearbeiteten Business Case und klaren Prioritäten basieren. Wenn euer Vorgesetzter euch fragt: „Was sparen wir damit?“, solltet ihr diese Frage auch beantworten können.
Wir haben einen Rechner zur Einschätzung von Einsparungen erstellt. Er basiert auf den Erfahrungen von Eficode und der Lösung Eficode ROOT, vermittelt aber einen guten Überblick über die Größenordnung.
Da diese Diskussionen hart sein können, ist es manchmal einfacher, ein externes Unternehmen mit der Migration zu beauftragen, damit ihr die Verantwortung nicht allein tragen müsst. Wir haben erlebt, dass Unternehmen ihre Mitarbeiter manchmal nicht informieren und sich erst entschuldigen, wenn etwas schiefläuft – weil sie glauben, das sei genauso effektiv. Das ist jedoch nicht die beste Art, mit Unternehmen zu kommunizieren, und führt in der Regel zu schlechteren Ergebnissen als Transparenz. Wenn es länger dauert, die nötigen Meetings zu organisieren, als sich bei den Beteiligten zu entschuldigen, lohnt es sich höchstwahrscheinlich nicht.
2. Menschen mögen keine Veränderungen
Nachdem wir über Schocks für die Unternehmenskultur gesprochen haben, schauen wir uns nun an, wie Einzelpersonen betroffen sind. Einflussreiche Personen in der Organisation stellen eine Herausforderung dar. Dabei handelt es sich meist um Power-User dieser Tools, die technisch und/oder sozial eine starke Position in der Organisation haben. Sie lieben die Tools, die sie nutzen und betreuen, und sehen daher keinen Grund, Tools zu ersetzen, in deren optimale Einrichtung sie so viel Zeit investiert haben.
Ihr müsst es für sie lohnenswert machen, das neue Tool zu erlernen, und ihre bisherigen Erfahrungen im Zusammenhang damit berücksichtigen.
Ihr müsst sie zu Fürsprechern und Change Agents machen. So gelingt das:
Findet sofort heraus, wer diese Personen sind.
Bezieht sie schon in den frühesten Phasen ein.
Zeigt ihnen, wie sie bestehende Probleme mit dem neuen Tool lösen können.
Bittet sie um ihren Rat, wo die Migration als Nächstes ausgeweitet werden sollte.
Das ist eine sehr wirksame Methode, sie dafür zu gewinnen, das neue Tool in den Teams zu vertreten. Wenn sie es verstehen, werden sie es annehmen und keine Angst vor der Veränderung haben. Stattdessen werden sie zu euren besten Botschaftern bei der Migration. Die Angst vor Veränderungen lässt sich oft durch Schulungen und Gespräche mit bestehenden Nutzern der Tools verringern.
Tipp: Bezieht die Power-User in den Entscheidungsprozess ein, damit sie ihre Sichtweise darlegen können.
Ein Beispiel: Jenkins auf den Grund gehen
Einer unserer Kunden war sehr skeptisch, ob wir ihn bei seiner Arbeit und beim Hosting seiner Tools unterstützen könnten. Wir sprachen darüber, einen Teil seiner Arbeitslast zu übernehmen, doch er hielt den Aufwand dafür für sehr gering.
Wir erklärten, wie das neue Tool Jenkins funktioniert und dass jedes Plugin überprüft werden muss. Wenn nachts etwas ausfällt, müssen sie aufstehen und es wieder zum Laufen bringen. Wir gingen das System durch und besprachen den zusätzlichen Aufwand, der täglich nötig war, um es am Laufen zu halten.
Was sie wirklich wollten, war eine bessere Testarchitektur für ihr System – statt täglich Brände zu löschen und Fehler zu beheben. Wir besprachen, wie wir diese Probleme zuvor gelöst hatten. Danach fragten sie uns, ob wir auch einige ihrer anderen Systeme betreuen könnten, damit sie sich stattdessen auf das Erstellen und Schreiben von Code konzentrieren können. Gehört zu werden, war der entscheidende Schritt, damit sie erkennen konnten, wo sie zuvor standen.
3. Der Fokus liegt nicht auf den richtigen Fragen
Wir haben unsere Botschafter gefunden, und unsere Unternehmenskultur öffnet sich zunehmend für die Migration. Wir können also loslegen, richtig? Lasst uns einfach diese lästigen technischen Probleme angehen!
Nein, noch nicht. Wir brauchen einen klaren Plan.
Wir müssen die fünf Fragen zur Migration beantworten, die über unseren Erfolg entscheiden werden. So stellen wir sicher, dass alle dieselben Migrationsziele vor Augen haben. Wir machen es wie bei Softwareprojekten: Wir müssen innehalten und prüfen, ob alle verstehen, warum wir das tun und worauf wir hinarbeiten.
Welche Fragen ihr bei der Migrationsplanung stellen solltet:
Welche Art von Migration planen wir?
Welche Daten sollen wir migrieren?
Soll die Migration für Entwickler vollständig automatisiert ablaufen, oder erwarten wir, dass sie selbst viele Änderungen vornehmen?
Migrieren wir zu einer anderen Instanz desselben Tools oder zu einem komplett neuen Tool?
Wenn es sich um ein neues Tool handelt: Was wollen wir an unserer bisherigen Arbeitsweise ändern?
Welche KPIs definieren eine erfolgreiche Migration?
Wir müssen unsere KPIs für eine erfolgreiche Migration festlegen.
Was verstehen wir unter Erfolg: Sind alle Nutzer migriert? Sind die Teams mit den neuen Tools zufrieden? Sind die Durchlaufzeiten kürzer? Sind die Kosten niedriger?
Wie bewerten wir diese Faktoren, und wo setzen wir die Zielwerte?
Wenn ihr diese Fragen beantwortet habt, könnt ihr die Zusammensetzung des Migrationsteams festlegen, das für das Erreichen dieser KPIs verantwortlich ist. Die größte Herausforderung bei der Zusammenarbeit besteht darin, alle auf einen gemeinsamen Stand zu bringen. Denkt deshalb bei der Festlegung der KPIs daran, wie sie sich auf die verschiedenen Stakeholder auswirken.
Wenn ihr die höchste Qualität anstrebt, wählt KPIs, die sich auf die Qualität der Migration auswirken, zum Beispiel:
Anzahl der Support-Tickets (mit dem Zielwert null)
Aufwand für Endnutzer (der minimal sein sollte)
Auswirkungen auf das Geschäft
Benutzerfreundlichkeit des neuen Systems (gemessen mit einer Nutzerzufriedenheitsumfrage).
Wenn ihr die niedrigsten Kosten anstrebt, verwendet KPIs, die Folgendes messen:
Projektdauer
Funktionsparität mit den bisher genutzten Systemen
Tickets, die zwei Wochen nach der Migration noch offen sind.
Diese Faktoren bestimmen, was das Migrationsteam optimiert.
Wofür wird das Migrationsteam verantwortlich sein?
Jetzt, da ihr wisst, welche Prioritäten unser Migrationsteam setzt, ist es Zeit zu fragen: „Was sollen die Teams tun müssen?“ Richtet dies an euren KPIs aus. Wenn ihr die niedrigsten Kosten anstrebt, ist mehr manuelle Arbeit erforderlich, als wenn ihr sechs Monate in die Entwicklung von Tools investiert, um alle auf einmal zu migrieren.
Überlegt euch daher genau, was ihr von euren Teams erwarten könnt.
Wie migrieren die Teams in die neue Umgebung?
Wir sehen oft große Investitionen in Aufgaben, die die Teams sehr einfach selbst erledigen könnten – und bei denen es sogar sinnvoll sein könnte, dass sie sie selbst übernehmen. Zum Beispiel die CI/CD-Jobs in die neue Umgebung zu verschieben und gleichzeitig alte Altlasten aufzuräumen.
In der Regel ergibt es keinen Sinn, etwas zu migrieren, das nicht genutzt wird – insbesondere, wenn es nie wie vom Team erwartet funktioniert hat. Manchmal möchten Teams ihr CI/CD jedoch in einem Zug umziehen. Sie wollen nichts an einem funktionierenden System ändern.
Fragt euch also, wie ihr Teams für die Migration belohnen und gleichzeitig den nötigen Druck erzeugen könnt. „Dieser Service wird in sechs Monaten abgeschaltet“ ist immer ein mögliches Druckmittel – aber ist es in unserer Organisation wirksam?
Ich habe viele Organisationen erlebt, die ihren Nutzern mitteilen, dass ein Service eingestellt wird. Weil die Betroffenen jedoch wissen, dass die Abschaltung nicht stattfinden wird, nutzen sie die alten Lösungen weiter. Die Teams verwenden möglicherweise sogar Umgebungen, die schon vor Jahrzehnten „abgeschaltet“ wurden.
Wenn ihr den Schmerz wieder spürbar machen wollt: Verrechnet die Kosten an die Teams, die das System weiterhin nutzen. Meist migriert das Team dann überraschend schnell auf ein neues System. Denkt aber auch daran, dass jede Organisation anders ist.
Ihr habt also KPIs, Anforderungen und die Spezifikation für die Migration. Doch die schwierigste Frage steht noch aus – eine, die ihr höchstwahrscheinlich nicht allein beantworten könnt und die euer Vorgesetzter wie die Pest meiden möchte. Wenn ihr sie aber nicht löst, bremst ihr eure Migration selbst aus.
Wie verteilen wir die Kosten?
Da sind die direkten Migrationskosten, etwa für Lizenzen und den dafür erforderlichen Arbeitsaufwand. Das ist klar.
Aber was ist mit indirekten Kosten und Opportunitätskosten? Beide wirken sich auf die oben genannten Punkte aus – deshalb wurde die Spezifikation überhaupt erstellt. Sie soll verhindern, dass jemand die Migration blockiert.
Ihr braucht einen klaren Plan dafür, wie ihr jedes Team darüber informiert, dass dieses Projekt umgesetzt werden muss. Alternativ müsst ihr die erforderlichen Kosten dem Migrationsteam zuordnen, wenn Verzögerungen aufgrund dieser Kosten entstehen. Wer bezahlt für die wertvolle Entwicklungszeit, die während der Migration nicht für andere Aufgaben zur Verfügung steht? Darauf sollte es eine klare Antwort geben, die vom gesamten Managementteam getragen wird. Zumindest sollte euer Sponsor wissen, dass diese Frage auf ihn zukommt. Wenn ihr alle informiert, bevor sie diese Frage stellen können, hinterlasst ihr bei euren Stakeholdern einen besseren Eindruck.
Ein Beispiel: eine vollständige Migration
Bei einer erfolgreichen Migration, die ich vor einigen Jahren durchgeführt habe, sagte der Kunde: „Wir möchten eine vollständige Migration, damit wir selbst nichts tun müssen.“ Und genau das haben wir umgesetzt:
Wir haben Skripte vorbereitet, um die Git-Repositories mit neuen URLs zu aktualisieren.
Wir haben Artifactory-URL-Weiterleitungen automatisch durch neue sichere Weiterleitungen ersetzen lassen.
Wir haben die Jobs von On-Premise-CI/CD in die Cloud migriert, getestet und so vorbereitet, dass sie wie zuvor laufen. Außerdem haben wir die Migration von Jira und Confluence von Oracle-Datenbanken zu PostgreSQL vorbereitet.
Dabei haben wir die gesamte Infrastruktur zu AWS verschoben.
Die Kosten für diese Arbeit waren deutlich höher als vom Kunden erwartet. Viel umgebungsspezifischer Code musste neu geschrieben werden, um URL-Weiterleitungen bereitzustellen und damit Ausfälle zu verhindern. Gleichzeitig musste der gesamte Traffic von http://address:port zu https://service umgestellt werden. Es handelte sich um einen kleinen Kunden, daher gingen wir davon aus, dass ihm die Zeit dafür fehlte. Nachdem wir jedoch das Feedback dazu eingeholt hatten, was schiefgelaufen war, sagte der Kunde:
„Wir hätten diese URLs selbst ändern können. Für unsere Entwickler wäre das im Rahmen ihrer normalen Arbeit sehr schnell gegangen.“ Weil wir nicht klar festgelegt hatten, „was die Teams übernehmen werden“, haben wir letztlich deutlich mehr Arbeit geleistet, als der Kunde erwartet hatte. Heute ist er weiterhin ein zufriedener Kunde, der uns vertraut – aber wir haben unsere Lektion gelernt. Wir unterstützen unsere Kunden nun immer dabei, die wichtigen Aufgaben zu definieren, die wir für sie lösen sollen, damit sie dafür auch ein Budget einplanen.
Hier noch einmal die Fragen für die Migration:
Welche Art von Migration planen wir?
Welche KPIs gelten für eine erfolgreiche Migration?
Wofür ist das Migrationsteam verantwortlich?
Was genau sollen die Teams migrieren? Gibt es Anreize für oder gegen die Migration?
Wie verteilen wir die Kosten? Alle drei Arten: direkte, indirekte und Opportunitätskosten.
4. Ihr müsst umfassend neu konfigurieren
Wenn ihr das verwendete Tool wechselt, können sich die Konfigurationen drastisch ändern: Die Tools funktionieren auf sehr unterschiedliche Weise. Definiert daher in der Planungsphase immer: „Was können wir verlieren?“ Nicht alles lässt sich einfach erneut implementieren. Viele Funktionen könnt ihr in der Regel umsetzen, doch der Aufwand kann im Verhältnis zum Nutzen der jeweiligen Funktion sehr hoch sein.
Beispielsweise könnt ihr Berechtigungsstufen meist nicht exakt übernehmen, da manche Tools wesentlich granularere Berechtigungsstufen und Rollen bieten als andere. Ihr müsst im Voraus festlegen, welche Berechtigungen wohin übertragen werden und welche Berechtigungen Teams standardmäßig benötigen.
Bei CI/CD gibt es in keiner Organisation, die ich kennengelernt habe, nur einen Weg zum Build oder Deployment. Ich habe sogar Organisationen erlebt, die fertige Deployment-Jobs anbieten und dennoch Unterschiede zwischen Teams feststellen.
Tipp: Erstellt einen allgemeinen Überblick über eure vorhandenen Jobs. Ermittelt, wie viele davon als Code definiert sind und wie viele über eine UI konfiguriert wurden – sofern das Tool die UI-Konfiguration von Jobs unterstützt.
Wahrscheinlich migriert ihr zu einem Tool, das nur as-a-code unterstützt, oder ihr möchtet alle Jobs in Code überführen. Deshalb ist es wichtig herauszufinden, bei wie vielen Jobs ihr lediglich die Syntax wechseln müsst und bei welchen ihr dem Team völlig neue Arbeitsweisen vermitteln müsst. Denn sie müssen lernen, dass CI/CD zum Repository gehört.
Bereitet gemeinsam mit euren Botschaftern gute Artikel zu den wichtigsten Sprachen und Anwendungsfällen vor. Stellt euch außerdem auf die noch unbekannten Herausforderungen einer Massenmigration ein. Dabei werdet ihr lernen, dass selbst die einfachste Konfigurationsänderung auf turbulente Gewässer treffen kann.
Ein Beispiel: Einen Jenkinsfile-Parser auf GitLab ausführen
Stellt euch folgendes Szenario vor: Ihr habt alles in Jenkins-Jobs und möchtet zu GitLab migrieren. Dazu verwendet ihr einen Jenkinsfile-Parser, damit GitLab die Jenkinsfiles auf denselben Servern mit derselben Konfiguration ausführt. Trotzdem wird es Probleme geben, denn nicht alles funktioniert in jeder Situation. In der Vergangenheit wurden beispielsweise viele Jobs erstellt, indem Binärdateien an den Jenkins-Master gesendet wurden.
Wenn ein solches Deployment von Binärdateien verwendet wird und die Binärdatei nirgendwo anders verfügbar ist, wird die künftige Einrichtung mit GitLab äußerst schwer umzusetzen sein. Der Grund ist, dass Binärdateien zwischen Jobs unterschiedlich übertragen werden. Einige Jobs müssen daher vollständig überarbeitet werden. Handelt es sich um eine Kette zusammenarbeitender Jobs, müssen sie in eine einzige Pipeline überführt werden. Das kann schwierig sein, da es für das ursprüngliche Design in der Regel Gründe gab.
Lernt zunächst, mit den neuen Tools zu arbeiten, und überlegt dann, was getan werden sollte, statt während der Migration zu viel auf einmal zu wollen. Ihr werdet nicht alle Szenarien abdecken können. Konzentriert euch daher lieber auf die breite Masse, statt alle komplexen Szenarien abdecken zu wollen.
In der Regel möchtet ihr sicherstellen, dass 80 % der Nutzer gut zurechtkommen. Und für den Rest habt ihr die ersten drei Schritte durchgeführt – damit ihr durch die trüben Gewässer navigieren könnt, ohne unterzugehen.
Unser wichtigster Tipp dazu: Wollt nicht zu viel auf einmal. Trefft allgemeine Annahmen und plant ein, den Rest nach der Migration zu beheben.
5. Solltet ihr automatisieren oder Menschen anleiten?
Ihr habt nun die Unterschiede zwischen den Tools erfasst und die Tools für eure Organisation beschafft. Jetzt geht es an die nächste große Frage: Was soll automatisiert werden, und wobei solltet ihr Menschen anleiten? Das Leitprinzip sollte sein: Wie beeinflussen wir die Arbeit sinnvoll?
Stellt euch daher folgende Fragen:
Welche Daten oder Funktionen müsst ihr in das neue System übernehmen?
Welche Daten oder Funktionen könnt ihr als optionale beziehungsweise zusätzliche Ziele betrachten?
Welche neuen Funktionen aktiviert ihr im neuen Tool standardmäßig? Gab es diese Funktionen in der alten Umgebung?
Jetzt, da ihr wisst, was erledigt werden muss und wer dafür verantwortlich ist, könnt ihr mit dem eigentlichen Implementierungs-Backlog beginnen. Was ihr automatisieren und wofür ihr Richtlinien festlegen möchtet, hängt davon ab, wie weit die Funktion im Tool verbreitet ist. Ebenso wichtig ist, wie viel Zeit Teams benötigen würden, um sie zu nutzen. Überlegt außerdem, ob es Vorschriften gibt, die verlangen, dass diese Funktionen vorhanden sind.
XKCD hat eine großartige Illustration erstellt, die zeigt, wie viel Zeit Menschen in die Effizienz von Routineaufgaben investieren können und über fünf Jahre hinweg dennoch Zeit sparen.
In einer Organisation mit 6.000 Entwicklern kann selbst die kleinste Automatisierung enorm viele Stunden sparen – etwa indem URLs nicht beschädigt werden und Abwärtskompatibilität gewährleistet bleibt oder indem CI-Pipelines bestimmte Funktionen automatisch enthalten.
Je größer der Umfang, desto mehr Zeit spart ihr. Das Ändern einer Git-URL in einer Organisation mit 6.000 Entwicklern kann beispielsweise nur zehn Minuten dauern. Für die Mitarbeiter summiert sich das theoretisch jedoch auf 60.000 Minuten zusätzlichen Aufwands, also 1.000 Stunden.
Tatsächlich geschieht das wahrscheinlich nebenbei, während jemand über eine andere Aufgabe nachdenkt oder noch seine morgendlichen E-Mails liest. Doch selbst 10 % dieser Zeit entsprechen 100 Stunden verlorener Arbeitszeit. Dinge zu automatisieren, die alle betreffen, ist daher meist die kluge Entscheidung.
Auch Branching- und Merging-Strategien in Git wirken sich direkt auf eure Mitarbeiter aus. Ihr möchtet daher nicht in jedem Projekt die falschen Strategien verwenden. Berücksichtigt deshalb:
Wie sich die Automatisierung auf den Endnutzer auswirkt
Wo und von wem wird die entwickelte Automatisierung genutzt?
Wie stellen wir sicher, dass die richtigen Einstellungen in die Projekte übernommen werden?
Ebenso wichtig ist es zu verstehen, was ihr über den CI/CD-Agent, Runner oder Action automatisieren könnt. Fragt euch:
Welche Art von Anpassungen erlauben wir?
Wie ermöglichen wir sie?
Wer wird sie künftig verwalten?
Ab welchem Punkt erzielen die Teams den größten Nutzen, ohne dass beispielsweise bereits alle Vorgaben erfüllt sein müssen?
Hosten wir diese für die Teams oder hosten die Teams sie selbst?
Wir empfehlen in der Regel, das Fachwissen für das Hosting dieser Komponenten als professionelle Dienstleistung einzukaufen, da Agents, Runner und Actions häufig für Überraschungen sorgen. Änderungen daran während der Migration führen daher fast immer zu Herausforderungen.
Ein Beispiel:
Unter Windows könnt ihr euch mit C# über AD-Berechtigungen bei einer SQL-Server-Datenbank authentifizieren. Dafür muss der Server:
mit AD verbunden sein, wobei erneute Deployments schwer zu automatisieren sind
Zugriff auf die genannten Zugangsdaten haben, was Sicherheitsbedenken aufwirft: Wer hat Zugriff auf die Agents, Runner und Actions?
Diese Punkte könnt ihr im Vorfeld gemeinsam mit dem Team klären und bearbeiten. Aufgrund der damit verbundenen Komplexität müssen die Agents, Runner und Actions während der Migration möglicherweise bestehen bleiben und vom Team manuell gewartet werden, statt in eine automatisch skalierende und automatisch gewartete Cloud-Umgebung umgezogen zu werden.
Versucht nicht, diese Pools während der Migration zu optimieren – das ist unmöglich. Achtet bei den ersten Massenmigrationen darauf, das System so ähnlich wie möglich beizubehalten, und konzentriert euch anschließend darauf. Das erfordert zusätzlichen Aufwand, spart aber insgesamt Zeit.
Manchmal glauben wir, dass Automatisierung unsere Probleme gelöst hat, doch in Wirklichkeit ist es nie so einfach. Nehmt etwa folgende Aussage: Wir haben bereits alle unsere Umgebungen containerisiert und dokumentiert – warum sollten wir uns darum kümmern?
Das bedeutet wahrscheinlich, dass ihr auf eine zentral verwaltete Agent-Plattform umsteigen könnt, indem ihr beispielsweise alles für alle Teams in einer einheitlichen Kubernetes-Umgebung betreibt. Es bedeutet aber auch, dass die Netzwerkanbindung weiterhin geplant und vorbereitet werden muss.
Komponenten auf Kubernetes umzustellen, ohne die Anforderungen der bisherigen Umgebung zu erfassen, ist riskant – auch wenn sie bereits dockerisiert waren. Wenn ihr auf zentral betriebene Kubernetes-Agent-Pools umsteigt, solltet ihr sie nach Möglichkeit in der Cloud bereitstellen.
Hosting und On-Premises-Kubernetes allein für Builds und Deployments sind sehr teuer, und ihr könnt nicht auf dieselbe Weise skalieren wie in der Cloud. Um Kosten und Fehleranfälligkeit in der Umgebung zu reduzieren, solltet ihr die zugrunde liegende Infrastruktur kontinuierlich herunterfahren.
Automatisierung ist euer Freund, aber alles zu automatisieren lohnt sich nicht immer. Konzentriert euch auf die kritischen Punkte, die wir zuvor festgelegt haben. Fragt euch: „Brauchen unsere Nutzer das wirklich, oder können sie es selbst verwalten?“ Wenn ihr weiterhin überzeugt seid, dass es nötig ist, solltet ihr die Automatisierung unbedingt prüfen.
6. Überlegt, wie ihr Artefakte migriert
Ein Wechsel der Software für das Artefaktmanagement klingt zunächst einfach. Die Migration dieser Binärdateien ist jedoch aufgrund vieler unterschiedlicher, miteinander verbundener Faktoren oft mit viel Aufwand verbunden. Ihr müsst erfassen, welche Repository-Typen ihr gegebenenfalls verwendet.
Viele CI/CD-Systeme ermöglichen es euch, dafür vorübergehend ihren eigenen Speicher zu nutzen. Das führt bei der Migration oft zu Problemen, weil die Binärdatei nicht so gespeichert wird, wie ihr es erwartet habt. Wenn ihr beispielsweise von statischen zu dynamischen Agents wechselt, die den Speicher nach jedem Build löschen, damit sich keine Altlasten ansammeln, kann das problematisch werden.
Das bedeutet, dass die Migration dieser Binärdateien riskant ist. Es reicht nicht zu prüfen, ob die neuen Systeme die Technologien x, y und z unterstützen, sondern auch: „Unterstützen sie auch Remotes und Virtuals?“ So könnt ihr beispielsweise einfach eine Remote-Repository-Verbindung zu npm.org aufbauen und sie über virtuelle Repositories mit euren anderen Repositories verbinden.
Fragt euch:
Wie sieht es mit den Layouts von Binaries aus? Auch diese lassen sich in vielen Tools anpassen.
Habt ihr Releases im Binärsystem verwendet?
Wie werdet ihr diese im künftigen System nutzen?
Vor Beginn der Migration gibt es überraschend viele Fragen zu klären – auch, ob das Tool die erforderlichen Funktionen unterstützt.
URL-Änderungen
Alle Änderungen an der URL für Binaries oder am Bereitstellungsort wirken sich auf sämtliche Jobs aus, die das von euch definierte Binär-Repository verwenden. Eine Änderung der URL betrifft alle Jobs, die dieses Binary nutzen. Das bedeutet, dass wir URLs suchen und ersetzen oder sie mithilfe von Proxys passend abbilden müssen, damit die Binaries weiterhin wie bisher erreichbar sind. In der Vergangenheit hatte unser Team große Schwierigkeiten damit, Ports zu entfernen und https für Artefakte einzuführen. Beides sind Standardsicherheitsfunktionen moderner Systeme, doch ihre Durchsetzung, ohne dass CI/CD nicht mehr funktioniert, ist nicht einfach.
DevSecOps-Pipelines
Wie sieht es mit euren DevSecOps-Pipelines aus? Wie integrieren sie sich in das neue Tool? Jfrog Xray funktioniert beispielsweise nur mit Jfrog Artifactory. Das bedeutet, dass ihr euer DevSecOps-Tool durch ein anderes ersetzen müsst. Es geht also nicht mehr darum, nur ein Tool zu wechseln, sondern mehrere.
Währenddessen müsst ihr auch klären, welche Remote-Repositories ihr anbieten solltet, da viele Teams aus unterschiedlichen Gründen möglicherweise direkt das öffentliche Internet nutzen. Ihr solltet ihnen daher über euer System für das Binary Management einen Zugriff mit geringerer Latenz bieten.
Binärspeicher
Binärspeicher sind mehr als nur ausgefeiltere gemeinsam genutzte Laufwerke. Sie bieten viele leistungsstarke Funktionen, die zum Problem werden können, wenn ihr beispielsweise vollständig zu GitLab migrieren möchtet, da viele dieser Funktionen im Tool selbst noch nicht verfügbar sind.
Dafür gibt es verschiedene Optionen: Ihr könnt alte Inhalte archivieren, um Kosten zu sparen, und Probleme erst beheben, wenn sie auftreten. Oder ihr wechselt zum neuen System, behaltet das alte zunächst bei, führt die neuen Funktionen schrittweise ein und prüft, welche Funktionen ihr weiterhin benötigt. Je nach benötigten Funktionen könnt ihr auch andere Wege finden, um das kostspielige System abzulösen, das ihr bisher für eure Entwickler betrieben habt.
Ein Beispiel: Entscheidung für einen Docker-Remote-Proxy
Einer unserer Kunden entschied sich, alles zu GitLab zu migrieren und alle anderen Lösungen aus seinen Pipelines zu entfernen. Dafür waren umfangreiche Untersuchungen dazu nötig, wie Binaries über GitLab bereitgestellt werden können und welche Einschränkungen es gibt. Wir kamen zu dem Schluss, dass die Teams Docker intensiv nutzten und einen Docker-Proxy benötigten.
Unsere Lösung bestand darin, den Empfehlungen von GitLab zu folgen und einen Docker-Remote-Proxy für Docker Hub einzurichten, damit die Images mit GitLab genutzt werden können, ohne die Lizenz für das alte System zu bezahlen. Dadurch erzielte der Kunde kleine Einsparungen bei seinen DevOps-Kosten.
Ich kann das nicht wirklich als Erfolg bezeichnen, denn die Einsparungen waren im Vergleich zu den Kosten des Projekts, das Binary Management ausschließlich zu GitLab zu migrieren, sehr gering. Es wird Jahre dauern, bis sich diese Änderung amortisiert. Deshalb empfehle ich oft:
die Software für das Binary Management beizubehalten und sie gegebenenfalls nur in die Cloud zu verlagern
sie mit S3-Buckets oder vergleichbaren Lösungen zu integrieren, um kostengünstigen Speicher zu nutzen
zu einer optimierteren Architektur für euer Binary Management zu wechseln
Kosten lassen sich in anderen Bereichen leichter senken als bei Lizenzen für das Binary Management, die aufgrund des Wettbewerbs in diesem Bereich recht günstig sind.
7. Legacy-Pipelines
Nun seid ihr endlich bereit, darüber nachzudenken, eure Legacy-Systeme auf neue Systeme zu migrieren und das Team mit den neuen Tools arbeiten zu lassen. Ihr habt die Politik und die Veränderungen in der Arbeitsweise hinter euch gebracht und könnt nun endlich fragen:
Wie migrieren wir die alten Tools auf das neue System?
Wir hören häufig von Teams, die wegen der Vorteile einer einheitlichen Plattform von Jenkins oder Teamcity zu GitLab oder GitHub wechseln. Sie suchen nach einer einfachen Universallösung dafür. Als Erstes fragen wir sie: „Verwendet ihr Jenkinsfiles oder Teamcity YAML?“ Die typische Antwort lautet: „Einige unserer Teams tun das.“
Das bedeutet, dass es manuell erstellte ClickOPS-Jobs gibt, die wir für diese Tools neu schreiben müssten. Die Jobs entstanden zu einer Zeit, als CI as Code noch ein wichtiges Konzept war, aber noch nicht umgesetzt wurde. Daher müssen diese handgefertigten Pipelines vollständig neu geschrieben werden, da es keine einfache Möglichkeit gibt, sie in das Pipeline-Modell zu migrieren.
Erstellt als Nächstes eine Liste mit:
den Änderungen, die ihr an den Jobs vornehmen müsst, damit sie funktionieren
der neuen Syntax
der Funktionsweise von Maven, NPM, Nuget oder anderen Paketmanagern im neuen Tool
Während der Migration müsst ihr Demos, Beispiele und Dokumentation für das Team erstellen. So kann es seine Jobs neu schreiben und korrigieren, wenn etwas nicht mehr funktioniert.
Möglicherweise könnt ihr einige Jobs durch Workarounds auf die neue Plattform übertragen, etwa indem ihr einen Jenkins Core in einem Agent ausführt. Damit könnt ihr Jenkinsfiles in einem GitLab Runner ausführen. Das eignet sich vor allem, um große Mengen zu migrieren, sollte aber als Übergangslösung betrachtet werden, die Teams dazu anregt, ihre Jobs neu zu schreiben.
Für die Einführung von SAST- und DAST-Funktionen ist ein Neuschreiben erforderlich. Und wenn ihr solche Teile nicht in den Job integriert:
Warum übertragt ihr dann überhaupt alles auf die neue Plattform? Wenn ihr nicht von den neuen Errungenschaften der DevOps-Community profitieren wollt, was möchtet ihr dann erreichen?
Kehren wir zum Anfang dieses Blogs zurück: Wenn ihr nicht vorhabt, auf die neue Plattform zu wechseln, habt ihr dann wirklich einen Business Case – oder verändert ihr euch nur um der Veränderung willen?
Die Migration von Tools erfordert oft, sie für neue Funktionen auf eine neue Plattform zu übertragen und zu refaktorieren. Außerdem verwendet keines der Tools eine ähnliche Syntax, weshalb die Migration in ein Produkt und aus ihm heraus sehr aufwendig ist. Deshalb scheuen viele Unternehmen diesen Schritt. Das Ergebnis lohnt sich meist: Nach der Migration könnt ihr Mitarbeiter einfach zwischen Tools und Produkten wechseln lassen, weil die Teams mit denselben Tools und Prozessen arbeiten.
Bei einer Migration müsst ihr planen, wie ihr Ausnahmen handhabt und unterstützt, den Fortschritt überwacht und die Systeme für eure Teams am Laufen haltet. Migrationen erfordern in der Regel ein sehr straffes Projektmanagement sowie die Überwachung folgender Punkte:
Wer führt seine Jobs noch aus und warum?
Was müssen wir lösen?
Einige Teams werden sagen, dass eine Funktion fehlt oder ihre Implementierung für sie ein Hindernis darstellt. Es gibt viele Möglichkeiten, eine Pipeline zu erstellen. Keine davon sollte darin bestehen, ein Groovy-Skript mit 400 Codezeilen zu schreiben, nur um ein Prozessproblem zu lösen.
Versucht nicht, alles mit CI/CD zu lösen, sondern schafft eine Kultur des Vertrauens. Wenn ihr eurer Arbeit und euren Schritten nicht vertrauen könnt, haltet inne und prüft, woran und wie ihr arbeitet. Wenn ihr euren Pipelines und Arbeitsweisen nicht vertrauen könnt, worauf könnt ihr dann in eurem DevOps vertrauen?
Beginnt damit, die Funktion mit dem Team zu besprechen, und fragt nach dem „Warum“.
Warum vertrauen wir unseren Tests nicht?
Warum ist hier menschliches Eingreifen erforderlich?
Sorgt dafür, dass dem Team vertraut wird. Andernfalls macht ihr kein DevOps.
Wenn ihr CI/CD einsetzt, um Deployments zu beschleunigen, lasst diese Teams in diesem Tool arbeiten. Sie werden sich nicht ändern, unabhängig davon, mit welchen Tools ihr sie ausstattet. Verschiebt das Git-Repository und lasst CI/CD dort. Das Build-Tool nur zu ändern, um das Team zu verändern, funktioniert selten.
Wenn sie jedoch bereit sind, sich zu verändern und das Vertrauen anzunehmen, das ihr ihnen entgegenbringt, ist es an der Zeit, ihnen zu vertrauen. Sie werden es schaffen.
8. Ihr braucht neue Dashboards und Ansichten
Vergesst zunächst, eure Dashboards und Ansichten zu migrieren. Sie werden im neuen Tool nicht so funktionieren wie im alten. Erstellt sie neu, damit sie zum neuen Tool passen. Denkt während der Migration auch über Fragen nach wie: „Brauchen wir dieses Dashboard, das nur Grün oder Rot anzeigt, wirklich, oder können wir daraus etwas machen, das für Remote-Arbeit hilfreicher ist?“
Dashboards können nur das anzeigen, was ihr ihnen mit den Daten vorgebt. Ihr könnt keine Datenansicht anzeigen, für die euch die Daten fehlen. Euer Team muss die Datenflüsse implementieren. Überlegt euch daher, warum ihr jedes Dashboard braucht.
Dashboards sind ein zweischneidiges Schwert. Wenn eure Teams sich darauf konzentrieren, die Kennzahlen des Dashboards zu verbessern, riskiert ihr, dass das Dashboard eure Entscheidungen für euch trifft.
Bei einem Kunden haben wir beispielsweise begonnen, Releases in Jira zu messen. Kurz darauf implementierten wir für das Team die automatische Erstellung und den automatischen Abschluss von Releases – basierend auf Tickets, die innerhalb eines Zeitraums nach „Done“ verschoben wurden. So konnten sie ihre Releases in der Kennzahl ausweisen, ohne die Funktion tatsächlich nutzen zu müssen. Dadurch stieg die Kennzahl um das Zehnfache, für das Team löste das jedoch kein wirkliches Problem.
Ein weiterer Nachteil von Dashboards: Wenn sich das Team nicht für das Dashboard interessiert, schaut es nicht darauf. Statt also alles in ein Dashboard zu verwandeln, haltet inne und fragt euch: „Was brauchen wir wirklich?“ und „Was wollen wir damit erreichen?“
Daten sind außerdem nur so gut wie die Verarbeitung, die ihnen zugrunde liegt. Wie man so sagt: „Garbage in, Garbage out.“ Wenn ihr ein Dashboard mit Daten „schnell“ erstellt, könnt ihr das Team in die falsche Richtung führen.
Ich habe beispielsweise Kunden erlebt, die bei A/B-Tests Sessions und Benutzer verwechselt haben. Dadurch wurden die Tests mit riesigen Mengen an Datenpunkten verfälscht, anstatt durch eine gezielte Gruppierung festzustellen, ob eine Funktion nützlich war oder nicht.
Compliance- und Application-Lifecycle-Kennzahlen erstrecken sich oft über mehrere Teams – ein ganz eigener Bereich mit Optimierungspotenzial. Wir betrachten sie normalerweise in jeder Phase der Migration, von der Vorplanung bis zur langfristigen Nachhaltigkeit.
Um den Erfolg eurer Migration zu messen, solltet ihr keine herkömmlichen Kennzahlen für den Software Development Lifecycle verwenden. Solange keine ausreichende Abdeckung besteht, sind sie irreführend. Nutzt stattdessen Kennzahlen, die die Akzeptanz messen.
Einige unserer Kunden dachten beispielsweise, beim DevOps-Tooling gut aufgestellt zu sein. Als wir jedoch ihre DevOps-Nutzung untersuchten, stellten wir fest, dass sie in ihrem Stack nur die Versionsverwaltung nutzten. Sie machten also kaum DevOps und konzentrierten sich auf die falschen Dinge, um ihr Tooling weiterzuentwickeln. Ihre Kennzahlen zeigten ihnen, dass sie gut unterwegs waren: Sie nutzten das Tool. Das stimmte technisch gesehen zwar, aber Kennzahlen sollten das Team und die Arbeitsweisen im Tool unterstützen – nicht nur die Produktnutzung messen.
Ein paar abschließende Worte
An diesem Beitrag zu arbeiten, war eine spannende Erfahrung: der Versuch, die schwer fassbare Migration der Träume zusammenzufassen. Hier sind ein paar letzte Ratschläge.
Es wird vielleicht nicht schön
Ein paar Mal ist es mir gelungen, fantastische Migrationen durchzuführen, aber das ist meiner Erfahrung nach sehr selten. Meistens werden sie ziemlich chaotisch – selbst mit all dem Wissen, das ich in den letzten zehn Jahren bei Migrationen für DevOps-Tools und die Cloud gesammelt habe. Hinter dem Requirements-Management-Prozess wartet immer eine Überraschung, die ihr dann am Samstag um 1 Uhr nachts allein behebt. Ihr wisst, dass die Tests morgen früh beginnen und die gesamte Migration verschoben wird, wenn bis 10 Uhr nicht alles bereit ist. Dann müsst ihr die letzten 36 Stunden der Hölle noch einmal durchleben. Also macht ihr weiter und hofft, das Problem zu lösen.
Habt keine Angst vor Fehlern
Manchmal gelingt es, öfter scheitert man. Habt bei einer Migration keine Angst vor Fehlern. Nehmt die Erkenntnisse daraus mit, bereitet euch beim nächsten Mal besser vor und versucht, Migrationstage von mehr als 40 Stunden zu vermeiden. Sie sind weder gesund noch wirklich produktiv. Stimmt euch mit einem Kollegen ab, sorgt für gute Übergaben und stellt sicher, dass euer Team einen frischen Kopf behält.
Ein Beispiel für eine gelungene Migration
Zum Abschluss möchte ich euch von einer Migration erzählen, die gut gelaufen ist.
Wir gingen zu einem Meeting, und der Kunde erklärte, dass die Migration im nächsten Monat stattfinden sollte. Sie musste gelingen, da der bisherige Anbieter den Support für die Software in eineinhalb Monaten einstellen würde. Wir erstellten einen Plan für das Produkt, mit dem wir bestens vertraut waren, bereiteten die Umgebungen und Datenmigrationen vor und stellten sicher, dass alles bereit war. Wir führten zahlreiche Testmigrationen durch und prüften, ob alles reibungslos funktionierte.
Am Go-live-Tag begannen wir mit der Migration, und die DNS-Migration erfolgte wie vereinbart. Aufgrund eines Versehens bei DNS war die TTL jedoch auf eine Stunde gesetzt, wodurch die Migration eineinhalb Stunden dauerte. Weitere Probleme gab es überhaupt nicht, und wir gingen wie geplant in Produktion. Selbst mit all der Erfahrung und Schulung kann ein einziges Versehen ein solches Projekt verdreifachen. Es lief gut, und wir waren froh, in Produktion zu sein.
Denkt einfach daran: Versucht, die stressige Reise zu genießen, und feiert den Erfolg. Ich hole mir jetzt ein Bier und feiere die Migration dieser Daten aus meinem Kopf aufs Papier.
- DevOps
- Eficode ROOT
Subscribe to our newsletter
Related blogs
