Regelmäßig und automatisiert integrieren

Was ist Continuous Integration?

Continuous Integration ist eine Softwareentwicklungspraxis, bei der die Mitglieder eines Entwicklungsteams ihren Softwarestand regelmäßig und automatisiert mit dem Stand der anderen Teammitglieder in einen gemeinsamen Softwarestand integrieren. Bei dieser Integration wird geprüft, ob der aus allen Ständen gebildete Code zusammenpasst, ob alle Tests fehlerfrei durchlaufen und ob aus dem gemeinsamen Softwarestand ein Artefakt gebaut werden kann.

Prinzipien kontinuierlicher Integration

Die am weitesten verbreitete der Umsetzung geht von einem zentralen Integrationsserver aus, der bei jedem Commit in das Versionsverwaltungssystem den aktuellsten Softwarestand herunterlädt, daraus das Softwaresystem baut und alle Tests ausführt. Der gesamte Prozess sollte nicht länger als 10 Minuten dauern, damit das Feedback des Integrationsservers wertvoll für das Team ist.

Implementierungen

Es gibt eine Vielzahl von fertigen Softwarelösungen, die das Aufsetzen eines Integrationsservers beschleunigen sollen. Die bekannteste Software in diesem Bereich ist der Automatisierungsserver Jenkins. Die einfachste Variante von Continuous Integration mit dem Namen “Continuous Integration on a Dollar a Day” kommt sogar ganz ohne Toolunterstützung aus, sodass man sofort loslegen kann:

  1. Lokal bauen bis grün: Prüfe deine Änderungen am Code lokal. Ist der Build erfolgreich? Laufen alle Tests noch? Committe deine Änderungen (git commit).
  2. Integrationstoken reservieren: Nimm dir das Build-Maskottchen. Integrieren darf nur, wer dieses Token besitzt. Damit verhinderst du, dass sich Integrationen gegenseitig behindern und du unnötig mergen musst.
  3. Lokal integrieren bis grün: Hole die letzten Updates aus der Quellcodeverwaltung (git update). Damit stellst du sicher, dass du keine Änderungen deiner Teammitglieder:innen verpasst. Prüfe, ob der Build lokal durchläuft. Sind deine Änderungen mit den Änderungen der Teammitglieder:innen kompatibel? Laufen noch immer alle Tests?
  4. Einchecken: Bringe deine Änderungen in die Quellcodeverwaltung (git push).
  5. Auf Integrationsserver integrieren bis grün: Aktualisiere die Workarea auf dem Integrationsrechner. Starte dort den Build. Ist alles noch grün, laufen alle Tests? Hast du alles eingecheckt?
  6. Bescheid geben: Gib das Integrationstoken frei und informiere deine Teammitglieder über deine Änderungen. Diese können jetzt ihre Arbeitsumgebungen aktualisieren, um auf dem neuesten Stand zu arbeiten und Merges zu verringern.
  7. Ausliefern (optional): Alle Änderungen sind integriert, der Build ist erfolgreich und alle Tests laufen. Warum nicht gleich ausliefern? Frühes Feedback ist wichtig und zeigt uns, ob wir auf dem richtigen Weg sind.

Vorteile von Continuous Integration

Schnelles Feedback

Je länger es dauert, bis die Mitglieder:innen eines Entwicklungsteams ihre Softwarestände integrieren, desto schwieriger und desto länger wird die Integration werden. Im Umkehrschluss gilt somit: Je häufiger die Softwarestände integriert werden, desto seltener und weniger umfangreich können Probleme beim Synchronisieren der Softwarestände auftreten.

Erhöhte Transparenz

Die Software wird an einem Ort zusammengeführt, der die zentrale Wahrheit über den aktuellen Stand der Softwareentwicklung darstellt. Dieser zentrale Stand kann sehr gut visualisiert werden. So gibt es Build-Ampeln, die grün leuchten, wenn das letzte Softwareinkrement fehlerfrei getestet und erfolgreich gebaut wurde. Alternativ kann man auf Build-Monitoren die gesamte Strecke vom Bau der Software, über den Stand der Unit-Tests bis hin zur Durchführung der Akzeptanztests visualisieren. Tritt auf einer Teilstrecke ein Fehler auf, so sieht man auf den ersten Blick, wo die möglichen Fehlerquellen liegen.

Bessere Qualität

Der zentrale Stand der Anwendung wird stets durch den Integrationsserver getestet. Im Vergleich zu Entwickler:innen vergisst dieser niemals alle vorhandenen Tests auszuführen. Wenn das Team für eine hohe Testabdeckung des Source Codes sorgt und vom Integrationsserver gemeldete Fehler direkt vom Team behoben werden, führt das zu der hohen Qualität der Software, die durch agile Softwareentwicklung bedingt wird.

Erhöhte Geschwindigkeit durch Sicherheit

Dank der besseren Qualität und der erhöhten Sicherheit können Änderungen schneller und mutiger durchgeführt werden. Die in der agilen Softwareentwicklung notwendige Vorgehensweise des kontinuierlichen Refactorings wird dadurch ermöglicht. Dadurch entsteht eine Feedbackschleife, in der sich die Qualität, Sicherheit und Geschwindigkeit positiv verstärken.

Unser it-agile Lagerraum

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

 

+ 49 40 4135 848-0    info@it-agile.de    Online Termin buchen

Agile Coaching von it-agile

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.

  • Wir integrieren Pragmatismus mit Idealismus
  • Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
  • Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
agile review Magazin

agile review

Unser Kundenmagazin 

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

  • Als Abo oder Einzelausgabe erhältlich
  • Digital oder Print
  • Einzelne Artikel sofort digital verfügbar

Wissens- und Lesenswertes

Das könnte Sie zu Agiler Arbeit auch interessieren

Agile Teams

Ein Haufen abhängiger agiler Teams ergibt noch kein agiles Unternehmen. Die übergreifenden Themen führen zu extremen Overhead, schlechter Vorhersagbarkeit und langsamer Time-To-Market. Diese Probleme…

Agile Teams

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings. Was steckt dahinter?

Agile Entwicklung

DORA (DevOps Research and Assessment) ist ein wissenschaftliches Studienprogramm, das unser Kollege Andreas Havenstein zur Weiterentwicklung von Teams angewandt hat.

it-agile Newsletter

Sichern Sie sich regelmäßige Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle und neue Termine für unsere Schulungen sowie vieles mehr.


* Benötigte Angaben