Migration von Jenkins zu GitLab leicht gemacht

GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Das bedeutet, dass GitLab alles bietet, was du benötigst, um sichere Software schneller zu planen, zu entwickeln und bereitzustellen – alles in einem Tool.

Plattformen vereinfachen die Integration verschiedener Tools (DIY-DevOps), um den Software-Entwicklungsprozess (SDLC) zu unterstützen. Da Jenkins keine Plattform ist, sind zusätzliche Tools erforderlich, um den Software-Entwicklungsprozess zu vervollständigen. Dieser DIY-DevOps-Ansatz erhöht die Komplexität der Toolchain, was die folgenden Nachteile mit sich bringt:

Bedarf an individuellem Support für die Integration und Orchestrierung von Tools
Schwierigkeiten bei der Wartung/Aktualisierung/Sicherung separater Tools
Ineffizienz bei der Evaluierung der Unternehmenstransformation
Schlechte Entwicklererfahrung
Zusätzliche Management-/Zeit-/Budgetkosten
Produktivitätsverlust
Ineffizienz im Hinblick auf Kontextwechsel und Zusammenarbeit

Import project selection — DIY-DevOps im Vergleich zu einer DevSecOps-Plattform

Aus diesen Gründen erwägen viele Jenkins-Teams, zu einer DevSecOps-Plattform zu migrieren. Wer nach einer leistungsfähigeren, zuverlässigeren und sichereren Lösung sucht, sollte GitLab wählen! GitLab ist kostenlos für Einsteiger(innen) und bietet verschiedene Abonnementstufen, je nachdem, welche Anforderungen dein Unternehmen hat. Weitere Informationen zu unseren Angeboten und Funktionen findest du auf unserer Preisseite.

In diesem Blog erfährst du:

wie du eine Migration planst
wie du Repositories von anderen Tools für die Quellcodeverwaltung (SCM) zu GitLab migrierst
wie du CI/CD-Pipelines von Jenkins zu GitLab migrierst
welche weiteren Überlegungen du dir zu Migrationen machen solltest

Planung einer Migration

Bevor du eine Migration von einem anderen Tool zu GitLab CI/CD startest, solltest du zunächst einen Migrationsplan erstellen. Ein Migrationsplan ist ein wichtiger technischer Schritt, um Erwartungen festzulegen. CI/CD-Tools unterscheiden sich im Hinblick auf ihren Ansatz und Aufbau sowie ihre technischen Besonderheiten. Das bedeutet, dass Migrationen keine simplen, direkten Zuordnungen von Daten sind. Ein Migrationsplan bietet folgende Vorteile:

Er legt eine klare Vorstellung deiner Migrationsziele fest und kommuniziert sie. Dies hilft deinen Benutzer(innen) dabei, zu verstehen, warum sich der Aufwand lohnt. Der Nutzen wird deutlich, wenn die Migration abgeschlossen ist, aber die Beteiligten müssen sich dessen auch während der Migration bewusst sein.
Er ermöglicht die Unterstützung und Beteiligung der entsprechenden Führungsteams – dies trägt zum oben genannten Punkt bei.
Er bietet die Gelegenheit, Benutzer(innen) über Veränderungen aufzuklären.
Er findet Wege, um Teile der Migration zu sequenzieren oder zu verzögern und zu verhindern, dass nicht migrierte (oder teilweise migrierte) Zustände zu lange bestehen bleiben.
Er dokumentiert die Vorteile der Verbesserungen, die GitLab CI/CD bietet, und aktualisiert deine Implementierung im Rahmen der Umstellung.

Mit einem Migrationsplan kannst du einen Prozess einrichten, bei dem du mit minimalen Unterbrechungen langsam zu GitLab migrieren kannst. Dies kann bedeuten, dass Jenkins und GitLab parallel eingesetzt werden, während bestimmte Projekte zu GitLab verschoben und von Jenkins abgezogen werden.

Definition eines Change-Management-Prozesses

Der Migrationsplan sollte einen effektiven Change-Management-Prozess definieren. Entwicklungs- und IT Operations-Teams, Cloud-Administrator(inn)en sowie Sicherheits- und Qualitätsteams haben möglicherweise keine Erfahrung mit GitLab und sie wissen möglicherweise nicht, warum du oder deine Führungskraft sich entschieden haben, diesen Weg einzuschlagen.

Wer von den Veränderungen betroffen ist, muss Folgendes wissen:

Warum die Veränderung vorgenommen wird
Wie der zukünftige Zustand aussehen wird
Wie das Unternehmen den neuen Zustand erreichen möchte
Wo weitere Informationen oder Unterstützung zu finden sind

Zu diesem Zweck solltest du die folgenden Schritte in Erwägung ziehen, um Veränderungen für diese funktionalen Rollen zu steuern:

Analysiere den aktuellen Zustand: Dokumentiere den aktuellen Zustand der Prozesse. Sammle Indikatoren als Basis. Ermittle, was im Hinblick auf CI/CD funktioniert und was nicht, indem du wichtige Teammitglieder befragst. Dokumentiere die Herausforderungen, die du feststellst, sowohl in quantitativer als auch in qualitativer Hinsicht. Du musst andere von der Vision und dem Grund für die Veränderung überzeugen. Je klarer du also die Problemstellung definieren kannst, desto einfacher wird es, die Zustimmung des gesamten Unternehmens zu gewinnen.
Baue eine Vision auf: Nun, da du die aktuellen Probleme quantitativ mithilfe von Basisindikatoren und qualitativ (mit den Worten deiner Teammitglieder) beschrieben hast, stelle eine Vision des zukünftigen Zustands vor. Erläutere, warum dies wichtig ist (stelle einen Zusammenhang zu geschäftlichen Erfolgsindikatoren her). Biete Live- sowie aufgezeichnete Demos an, um aufzuzeigen, welche Möglichkeiten es gibt, und vergleiche diese Vision mit dem aktuellen Zustand. Betone diese Botschaft auf mehreren Kanäle und in verschiedenen Medien – Chat-Gruppen, allgemeine Meetings, E-Mail-Benachrichtigungen, Banner-Benachrichtigungen auf GitLab usw.
Kläre die Belegschaft auf: Investiere in GitLab-CI/CD-Schulungen (nur in englischer Sprache verfügbar), die von GitLab-Expert(inn)en durchgeführt werden. Evaluiere den Erwerb und das Verinnerlichen von Kenntnissen mithilfe von GitLab-Zertifizierungen (nur in englischer Sprache verfügbar).
Kommuniziere Roadmap und Ressourcen: Teile deinen Teammitgliedern den geplanten Zeitplan sowie die verfügbaren Ressourcen für die Migration mit. Nenne Community-Ressourcen wie Chat-Gruppen, Q&A-Boards oder die Kontaktzeiten von GitLab-Influencern oder -Influencerinnen, damit dein Team Fragen stellen und Unterstützung erhalten kann. Der Aufbau eines Belohnungssystems, das das Teams dazu anregt, frühzeitig umzusteigen und ihre Erfahrungen mit anderen Anwendergruppen zu teilen, wäre ein Pluspunkt!

Wenn du diese Elemente zu Beginn der Migration sicherstellst, stellst du die Weichen für ihren Erfolg.

Festlegung von Migrationszielen

Bevor du eine Migration durchführst, solltest du dir über deine Ziele im Klaren sein und wissen, wie du sie erreichen kannst. Einige Fragen, auf die du Antworten haben solltest, sind beispielsweise folgende:

Was ist dein Zeitplan für die Migration?
Wie ist dein Jenkins-Server aktuell konfiguriert?
Wie viele Projekte müssen migriert werden?
Wie komplex ist deine Pipeline?
Gibt es externe Abhängigkeiten, mehrere Pipeline-Trigger, parallele Builds usw.?
Wie/wo stellst du deinen Code bereit?
Was ist der Veröffentlichungs-/Überprüfungsprozess für die Bereitstellung von Code?
Ist der Workflow in Jenkins integriert oder gibt es einen separaten Workflow, der von Jenkins ausgelöst wird?
Welche Build-Artefakte oder Binärdateien sind für den Erfolg der Pipeline erforderlich?
Welche Plugins verwenden Jobs in Jenkins derzeit?
Welche Software ist auf den Jenkins-Agenten installiert?
Welche Lösung für die Quellcodeverwaltung verwendest du aktuell?
Verwenden deine Jenkins-Jobs gemeinsam genutzte Bibliotheken?
Welche Authentifizierungsmethode kommt für Jenkins zum Einsatz (Basic Authentication, LDAP/AD, SSO)?
Gibt es andere Projekte, auf die du von deiner Pipeline aus zugreifen musst?
Gibt es Zugangsdaten in Jenkins, die für den Zugriff auf externe Dienste verwendet werden?

Wenn du diese Fragen beantwortest, weißt du, wie du bei der Migration vorgehen solltest, wie lange sie dauert und wo du anfangen solltest. Wenn du einen Plan erstellt hast und dir die Erwartungen und möglichen Fallstricke bewusst sind, kannst du mit dem Migrationsprozess beginnen.

Voraussetzungen für die Migration

Sobald du einen Migrationsplan erstellt und alle Erwartungen an die Migration bedacht hast, kannst du mit der Einrichtung von GitLab beginnen. Hier sind einige empfohlene Voraussetzungen für die Migration:

Mache dich mit GitLab vertraut. Informiere dich über die wichtigsten GitLab CI/CD-Funktionen (nur in englischer Sprache verfügbar).
Folge den englichsprachigen Tutorials, um deine erste GitLab-Pipeline und komplexere Pipelines zu generieren, die eine statische Website erstellen, testen und bereitstellen.
Lies die Keyword-Referenz für .gitlab-ci.yml (nur in englischer Sprache verfügbar).
Richte GitLab ein und konfiguriere es.
Teste deine GitLab-Instanz.

Sobald du mit GitLab vertraut bist und eine Instanz konfiguriert hast, kannst du deinem Migrationsplan folgen und damit beginnen, Projekte von Jenkins zu GitLab zu verschieben. Stelle sicher, dass deine GitLab-Instanz mithilfe von bewährten Methoden für GitLab und gemäß Referenzarchitekturen (nur in englischer Sprache verfügbar) ordnungsgemäß eingerichtet wurde.

Migration von Repositories zu GitLab

Einer der wichtigsten Nachteile von Jenkins ist, dass es keine Lösung für die Quellcodeverwaltung (SCM, Source Code Management) bietet. Wenn du Jenkins verwendest, muss dein Code in einer separaten SCM-Lösung gespeichert werden, auf die Jenkins Zugriff haben muss. Da GitLab über eine integrierte Quellcodeverwaltung verfügt, ermöglicht der Umstieg von Jenkins auch die Migration der zuvor genutzten SCM-Lösung. Dies verringert die Kosten zusätzlich.

GitLab bietet Tools, mit denen du dein Repository und seine Metadaten einfach zu GitLab verschieben kannst. Die folgenden Importer (nur in englischer Sprache verfügbar) unterstützen dich bei der Migration deiner Projekte zu GitLab:

GitHub to GitLab Repo Exporter — Repoitory-Exporter von GitHub zu GitLab

Jeder Importer importiert unterschiedliche Daten aus einem Projekt. Lies die Dokumentation zum Import und zur Migration von Projekten (nur in englischer Sprache verfügbar), um mehr Informationen über die bereitgestellten Importer zu erhalten und zu erfahren, welche Daten zu GitLab migriert werden. Darüber hinaus kannst du den Import von Gruppen und Projekten automatisieren (nur in englischer Sprache verfügbar) und eine benutzerdefinierte Lösung erstellen, welche die Anforderungen deines Unternehmens noch besser erfüllt:

So migrierst du ein Repository

Mit unseren integrierten Importern kannst du Repositories ganz einfach zu GitLab migrieren. In diesem Beispiel erfährst du, wie du ein Repo zusammen mit seinen Ressourcen (nur in englischer Sprache verfügbar) (Tickets, Pull Requests, Meilensteine usw.) aus GitHub zu GitLab kopierst. Um ein Repository aus einem anderen GitHub zu GitLab zu migrieren, führe die folgenden Schritte aus:

1. Wähle oben in der linken Menüleiste Neu erstellen (+) aus. 2. Wähle im Abschnitt „In GitLab“ Neues Projekt/Repository aus. 3. Wähle Projekt importieren aus.

Klicke auf die Schaltfläche GitHub.
- Wenn du GitLab Self-Managed verwendest, musst du den GitHub-Importer aktivieren (nur in englischer Sprache verfügbar).
- Beachte, dass andere Importer auf dieselbe Weise initiiert werden können.
Jetzt kannst du:
- dich mit GitHub OAuth autorisieren: Wähle Mit GitHub autorisieren aus.
- einen persönlichen GitHub-Zugriffstoken verwenden:
  - Gehe zu https://github.com/settings/tokens/new.
  - Gib im Feld Notizen eine Token-Beschreibung ein.
  - Wähle den Geltungsbereich für das Repository aus.
  - Um Beteiligte zu importieren, wähle optional den Geltungsbereich read:org aus.
  - Klicke auf die Schaltfläche Token generieren.
  - Füge auf der GitLab-Importseite im Feld „Persönlicher Zugriffstoken“ den persönlichen GitHub-Zugriffstoken ein.
Klicke auf die Schaltfläche Authentifizieren.
Wähle die Elemente aus, die du migrieren möchtest.
Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie migrieren möchtest.
Klicke auf die Schaltfläche Importieren.

Nun sollte sich das importierte Projekt in deinem Arbeitsbereich befinden. Weitere Informationen über die Migration von GitHub zu GitLab findest du in diesem englischsprachigen Video:

Sobald du die Migration des Repositories abgeschlossen hast, kannst du deine Jenkins-Pipeline so einstellen, dass sie die Jenkins-Datei in GitLab nutzt. Lege dazu die Repository-URL für dein neu importiertes Projekt über das Jenkin-Pipeline-Konfigurationsmenü fest:

Jenkins Pipeline SCM settings — SCM-Einstellungen für die Jenkins-Pipeline

Dies ist nützlich für die anfängliche Repo-Migrationsphase und hilft dir dabei, sowohl Jenkins als auch GitLab parallel zu verwenden. So kannst du Dienstunterbrechungen vermeiden, während du die CI/CD-Funktionalität migrierst.

Darüber hinaus kannst du das GitLab-Jenkins-Plugin als Hilfestellung bei der Migration nutzen. Mit diesem Plugin kann GitLab den Status von Jenkins-Builds auslösen und abrufen.

Migration von CI/CD-Pipelines

Sobald du deine Repositories zu GitLab migriert hast, kannst du mit der Migration deiner Jenkins-Pipelines zu GitLab fortfahren. Dieser Prozess kann relativ simpel sein, du solltest dazu jedoch die Konzepte und die Syntax von Jenkins und GitLab verstehen.

Jenkins bietet zwei verschiedene Arten von Syntax für die Definition von Pipelines: Declarative und Scripted. Dieser Leitfaden behandelt die Migration von Pipelines des Typs Declarative, da diese am häufigsten vorkommen.

Schritt-für-Schritt-Migration der Pipeline

In diesem Tutorial wird eine Jenkins-Datei (Groovy) im Vergleich zu einer GitLab-CI/CD-Konfigurationsdatei (YAML) analysiert, die einen in Golang geschriebenen Microservice generiert, testet und bereitstellt. Anschließend werden die Pipeline in GitLab aktiviert und die Ergebnisse angezeigt. Die Pipeline wird:

das Golang-Container-Image mit dem Tag alpine verwenden,
einen Job zur Erstellung des Golang-Codes in einer ausführbaren Binärdatei ausführen,
- die erstellte ausführbare Datei als Artefakt speichern,
einen Job ausführen, um Unit-Tests durchzuführen,
einen Jobs zur Bereitstellung im Staging ausführen.
- Dieser wird nur ausgeführt, wenn der Commit auf den Branch Staging abzielt,
- beginnt, nachdem die Phase Test erfolgreich abgeschlossen wurde,
- verwendet das erstellte ausführbare Artefakt aus dem vorherigen Job.

Unten findest du die Pipeline-Definitionen aus Jenkins und GitLab sowie beschreibende Kommentare. Im Meow-Migrationsprojekt kannst du die Pipeline in Aktion sehen.

Schaue dir eine in Groovy geschriebene Jenkins-Datei an:

// Die höchste Ebene der Declarative-
// Pipeline.
pipeline {

  // Definiert den zu verwendenden Standard-Agenten,
  // sofern nicht explizit in einem Job
  // definiert.
    agent any

  // Definiert die Staging-Phasen, die in
  // numerischer Reihenfolge ausgeführt werden. Jede Staging-Phase
  // führt nur einen Job aus.
    stages {

    // Definiert den Namen der Staging-Phase.
        stage('build') {
      // Definiert das Container-Image,
      // das für diesen Job verwendet werden soll. Dies überschreibt
      // die Standardeinstellung 'agent any'.
      // Das Jenkins-Docker-Plugin
      // muss konfiguriert sein, damit dies
      // ausgeführt wird.
            agent { docker 'golang:alpine' }

      // Definiert die Abfolge von Schritten,
      // die bei der Ausführung der Staging-Phase
      // befolgt werden soll.
            steps {
                sh 'go build -o bin/meow-micro'
                sh 'chmod +x bin/meow-micro'
            }

      // Die Schritte, die nach Abschluss der
      // Staging-Phase ausgeführt werden sollen.
            post {
              always {

        // Speichert die Artefakte der Staging-Phase,
        // die zur Verwendung in einem anderen Job
        // generiert wurden.
                archiveArtifacts artifacts: 'bin/meow-micro'
                onlyIfSuccessful: true
              }
            }
        }

    stage('test') {
            agent { docker 'golang:alpine' }
            steps {
                sh 'go test .'
            }
        }

        stage('deploy') {
      // Definiert die Bedingungen,
      // die zur Ausführung des Jobs
      // erfüllt sein müssen. In diesem Fall wird der
      // Bereitstellungs-Job nur auf dem 
      // Staging-Branch ausgeführt.
            when {
              branch 'staging'
            }
            steps {
                echo 'Deploying meow-micro to staging'
        // Verwendet das Artefakt, das in der
        // Build-Staging-Phase gespeichert wurde.
                sh './bin/meow-micro'
            }
        }
    }
}

Schaue dir nun an, wie die gleiche Funktion in GitLab erstellt werden kann:

# Definiert das zu verwendende Standard-Image,
# sofern nicht explizit in einem Job
# angegeben.
default:
  image: alpine:latest

# Definiert die Reihenfolge der auszuführenden Staging-Phasen.
# Jede Staging-Phase kann mehrere Jobs umfassen.
stages:
  - build
  - test
  - deploy

# Definiert den Namen des Jobs.
create-binary:
 # Definiert die Staging-Phase, in welcher der Job ausgeführt wird.
  stage: build
 # Definiert das Container-Image, das für
 # diesen Job verwendet werden soll. Dies überschreibt die Standardeinstellung.
  image: golang:alpine
 # Definiert die Reihenfolge der Schritte,
 # die bei der Ausführung des Jobs befolgt werden sollen.
  script:
    - go build -o bin/meow-micro
    - chmod +x bin/meow-micro
 # Speichert die Job-Artefakte, die zur
 # Verwendung in einem anderen Job gespeichert wurden.
  artifacts:
    paths:
      - bin/meow-micro
    expire_in: 1 week

unit-tests:
  stage: test
  image: golang:alpine
  script:
    - go test .
 # Definiert Befehle, die im Anschluss an den Job
 # ausgeführt werden sollen.
 after_script:
  - echo "Tests Complete"

staging-deploy:
  stage: deploy
 # Definiert die Befehle, die vor dem
 # eigentlichen Job ausgeführt werden sollen.
  before_script:
    - apk update
  script:
    - echo "Deploying meow-micro to staging environment"
    - ./bin/meow-micro
 # Definiert die Bedingungen, die zur
 # Ausführung dieses Jobs erfüllt sein müssen. In
 # diesem Fall wird der Bereitstellungs-Job der Staging-Phase nur 
 # auf dem Staging-Branch ausgeführt.
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'
 # Erlaubt die Verwendung der Artefakte, die im
 # Build-Job gespeichert wurden, in diesem Job.
  artifacts:
    paths:
      - bin/meow-micro

Wie du vielleicht bemerkt hast, gibt es viele Gemeinsamkeiten zwischen Jenkins und GitLab im Hinblick auf die Syntax. Dies vereinfacht die Pipeline-Migration. Sieh dir die umfassende Liste der Funktions- und Konzeptvergleiche (nur in englischer Sprache verfügbar) zwischen den beiden Tools an.

Nun, da du verstehst, wie man Jenkins in GitLab abbildet, kannst du damit beginnen, eine Pipeline mit der gleichen Funktionalität in GitLab zu erstellen. Um CI/CD zu migrieren, kannst du die folgenden Schritte ausführen:

1. Öffne das Repository, das du im obigen Abschnitt zu GitLab migriert hast.

Klicke oben in der linken Seitenleiste auf Suchen oder aufrufen ….
Wähle dein Projekt aus.

2. Öffne den Pipeline-Editor (nur in englischer Sprache verfügbar).

Wähle in der linken Seitenleiste Build > Pipeline-Editor aus.

Pipeline editor menu — Pipeline-Editor-Menü

Klicke auf die Schaltfläche Pipeline konfigurieren.

Configure pipeline selection — Auswahl der Schaltfläche „Pipeline konfigurieren“

3. Befülle die Datei .gitlab-ci.yml (nur in englischer Sprache verfügbar).

Füge den GitLab-CI-Pipeline-Code hinzu.

Pipeline editor input — Eingabe im Pipeline-Editor

Prüfe, ob die Syntax korrekt ist.

Pipeline syntax validation — Validierung der Pipeline-Syntax

Visualisiere die Pipeline.

Pipeline visualization — Visualisierung der Pipeline

4. Committe die Datei in den Main-Branch.

Füge eine Commit-Nachricht hinzu.
Stelle sicher, dass es sich um den Main-Branch handelt.
Klicke auf die Schaltfläche Änderungen committen.

Commit changes dialog — Dialog „Änderungen committen“

Sobald die Datei zusammengeführt wurde, wird die definierte Pipeline gestartet. Du kannst zu deinem Projekt zurückkehren und die Pipeline anzeigen (nur in englischer Sprache verfügbar), indem du sie auf der Seite deines Projekts Build > Pipelines auswählst. Da sie auf dem Main-Branch ausgeführt wurde, siehst du nur den Job create-binary sowie die „unit-test“ Jobs. Der Job staging-deploy wird nur auf dem Staging-Branch ausgeführt.

Pipeline running on main branch — Auf dem Main-Branch ausgeführte Pipeline

Bei der Erstellung eines Staging-Branches wird die folgende Pipeline gestartet.

Pipeline running on staging branch — Auf dem Staging-Branch ausgeführte Pipeline

Wenn du auf einen Job klickst, wird dessen Ausgabe angezeigt:

create-binary job output — Ausgabe des Jobs create-binary

unit-tests job output input — Eingabe/Ausgabe des Jobs unit-tests

staging-deploy job output — Ausgabe des Jobs staging-deploy

Du kannst sehen, wie das Artefakt im Job create-binary gespeichert und im Job staging-deploy verwendet wird. Und so einfach ist es, eine Pipeline von Jenkins zu GitLab zu migrieren!

Zusätzliche Überlegungen zur Migration

Einige hilfreiche Überlegungen, die den Bereitstellungsprozess unserer Ansicht nach einfacher machen, sind folgende:

Versuche nicht, Aufgaben exakt als GitLab-Jobs zu replizieren. Nimm dir Zeit und schaue dir genauer an, was die aktuelle Pipeline bewirkt und welches Problem sie löst.
Einige Jenkins-Jobs sind möglicherweise zu komplex, um sofort zu GitLab migriert zu werden. Deshalb kann es von Vorteil sein, das GitLab-Jenkins-Plugin zu verwenden, um Jenkins-Pipelines zu starten und ihre Ergebnisse direkt in GitLab anzuzeigen. Auf diese Weise kannst du bestimmte Aktionen langsam zu GitLab migrieren, bis die gesamte Pipeline verschoben werden kann.
Implementiere Sicherheitsscanner und Codequalität (nur in englischer Sprache verfügbar) mithilfe von integrierten Vorlagen, die GitLab von Anfang an bereitstellt. So kannst du die Sicherheit im Vorfeld kontrollieren und die Gefahr eines Sicherheitsverstoßes verringern. Gestalte die CI/CD-Konfiguration nicht zu kompliziert und versuche nicht, alle Funktionsvorteile gleichzeitig zu nutzen. Modularisiere den Code und implementiere ihn in kleinen Iterationen.
Implementiere Funktionen zur Überwachung und Steuerung von Anfang an.
Bedenke, dass sich ein GitLab Runner (Go) möglicherweise anders verhält als ein Jenkins-Agent (Java). Die CPU-Auslastung und der Speicherverbrauch können unterschiedlich sein – achte darauf, sie im Laufe der Zeit miteinander zu vergleichen.
Ziehe in Erwägung, in automatische Skalierungsmechanismen zu investieren, und lege nicht benötigte Ressourcen am Wochenende oder außerhalb der Arbeitszeiten still.
Modernisiere die Anwendungsentwicklung, indem du deine Jobs containerisierst. Jenkins-Jobs laufen aktuell nicht in einem Container, sondern auf einem Jenkins-Agenten, der als VM ausgeführt wird.

Diese Liste ist nicht erschöpfend, stellt aber einen guten Ausgangspunkt für einige Überlegungen dar, die du beachten solltest. Wenn du zusätzliche Hilfe benötigst, bietet GitLab Professional Services an, um dich bei deiner Migration zu unterstützen.

Mehr erfahren

Vielen Dank, dass du diesen Leitfaden gelesen hast! Ich hoffe, dass er dir dabei geholfen hat, besser zu verstehen, warum und wie du von Jenkins zu GitLab migrieren kannst. Noch nicht überzeugt? Melde dich für eine kostenlose Testversion von GitLab an und erkenne den Nutzen einer DevSecOps-Plattform!

Hier findest du einige englischsprachige Ressourcen mit weiteren Informationen zu GitLab, den Vorteilen einer DevSecOps-Plattform und der Migration aus Jenkins: