Migration des GIT Repository und der CI/CD Pipeline by inits. 20. Juli 2022

Migration des GIT Repository und der CI/CD Pipeline

Softwareentwicklungsprojekte mit mehreren EntwicklerInnen und möglicher externer Unterstützung erfordern ein Versionsverwaltungssystem. De facto Standard ist GIT. In unseren Projekten setzen wir darauf und stellen so sicher, dass wir gemeinsam mit unseren Kunden arbeiten, ohne dass wir unsere Arbeitsergebnisse gegenseitig überschreiben. Was passiert eigentlich, wenn interne Mitarbeiter und externe Dienstleister die gleiche Zeile des Quelltextes verändern? Zusätzlich automatisieren wir den Erstellungsprozess der Software mit einer CI/CD Pipeline. Worum es sich dabei handelt, erfahrt ihr im folgenden Text …

Mit GIT - einem Versionsverwaltungsystem - ist es möglich, mehrere Versionsstände desselben Dokuments zu speichern und bei Bedarf auf frühere Versionen zurückzugreifen. Mittels sogenannter GIT-Reviews können sich alle Mitglieder des Projektteams gegenseitig noch einmal kontrollieren und erst nach erfolgter Qualitätssicherung des Quelltextes die Veröffentlichung anstoßen. Kurz gesagt ist GIT also ein digitales Archiv, in dem alle Änderungen von Dateien dokumentiert werden.

Das kontinuierliche Mitschreiben der Änderungsdaten führt häufig zu einem großen Umfang der sog. GIT Repositories. Dadurch stellt der komplikationslose Umzug dieser wichtigen Daten eine große Herausforderung dar und wird damit zu einem wesentlichen Erfolgsfaktor bei vielen Migrationsprojekten.

Um Software-Releases schneller und robuster bereitstellen zu können, gibt es in vielen Projekten die sogenannte “Content Integration / Delivery Pipeline” (CI/CD). Zentraler Bestandteil einer solchen Pipeline ist der Aufbau verschiedener Stages. Als Stages bezeichnen wir jeweils abgetrennte Umgebungen, in denen die Software autark betrieben werden kann. In unserem Beispiel arbeiten wir mit insgesamt vier Umgebungen. Neue Features können dann zum Beispiel in der “DEV-Umgebung” (1. Stage) programmiert, in der “TEST-Umgebung” (2. Stage) mittels automatisierter Unit-Tests geprüft und danach in eine sog. “STAGING-Umgebung” (3. Stage) übertragen und durch den Kunden abgenommen werden. Nach erfolgter Abnahme wird der aktuelle Stand aus der “STAGING-Umgebung” dann in die “LIVE-Umgebung” (4. Stage) übertragen (auch Deployment genannt).

Je höher die Anzahl verschiedener Stages wird, desto sicherer wird auch ein Release neuer Entwicklungen. Mit vielen verschiedenen Stages erhöht sich allerdings auch der Verwaltungsaufwand innerhalb des GIT und somit die Fehleranfälligkeit. Um die Systeme stabil zu betreiben und unsere Qualitätsansprüche aufrecht zu erhalten, arbeiten wir daher mit zahlreichen Automatisierungsmechanismen.

  • Automatisierte Erkennung von Änderungen im GIT
  • Automatisierte Unit-, Integrations-, End-to-End-Tests
  • Automatisiertes Deployments

Durch automatisierte Builds, Tests, Bugfixes und Deployments können sich unsere Entwickler so im Projektverlauf jederzeit auf das Wesentliche konzentrieren: Die Erstellung und Optimierung umfangreicher Anwendungen für unsere Kunden.

Die Migration einer solchen Pipeline, der angeschlossenen Tools und des dazugehörigen GIT-Systems umfasst in der Regel auch die Analyse und Optimierung bestehender Pipelines unserer Kunden. Neben der Optimierung der Pipeline besteht die größte Schwierigkeit für Teams und Unternehmen darin, die Testeffizienz zu verbessern und zeitgleich die hohen Anforderungen an Qualität und Sicherheit zu erfüllen. Das Ganze natürlich ohne den Projektverlauf in Bezug auf die Timeline und die Kosten zu beeinträchtigen.

Durch unsere langjährige Erfahrung in der Nutzung verschiedenster GIT-Systeme in Verbindung mit umfangreichen CI/CD Pipelines und automatisierten Tests können wir euch ideal in allen Projektphasen unterstützen.

Du möchtest mehr dazu erfahren? Schau’ doch einmal rein unter www.inits.io oder schreib’ uns eine Nachricht!

P.S. Übrigens helfen wir natürlich auch, wenn ihr aktuell noch keine Versionsverwaltung (GIT) oder CI/CD Pipeline nutzt ;-)