Analysieren von Continuous Integration
Continuous Integration ist eine der acht Funktionen in der DevOps-Taxonomie.
Erkunden, warum Continuous Integration notwendig ist
Am 23. September 1999 verstaute der Mars Climate Orbiter seine Solar-Arrays, um sie bei einem vorübergehenden Abstieg in die obere Marsatmosphäre zu schützen.
Nach dem erfolgreichen Eintritt in die Umlaufbahn sollte der Satellit mehrere Jahre lang Fotos vom Mars zur Erde senden. Doch leider verglühte das Raumschiff in der Marsatmosphäre.
Ein Fehler in der Bodenkontrollsoftware, die von einem Drittanbieter geliefert wurde, berechnete den Wert in einer imperialen Maßeinheit, Pfund-Sekunden. Die von der NASA erstellte Software erwartete den Wert in einer metrischen Einheit, Newton-Sekunden. Da diese Werte nicht korrekt umgerechnet wurden, summierten sich kleine Abweichungen in der Position der Raumsonde über eine Strecke von Millionen von Meilen.
Die Qualitätssicherung hatte die Verwendung einer imperialen Einheit in der externen Software nicht bemerkt, obwohl die Programmierstandards der NASA zu dieser Zeit die Verwendung metrischer Einheiten vorschrieben. Die Berechnungen wurden aufgrund von Dateiformatfehlern und diversen Bugs auch nicht mit der mitgelieferten Software, sondern manuell durchgeführt. Diese Situation ist ein Beispiel für die Notwendigkeit von Continuous Integration.
Erkunden von Continuous Integration
Continuous Integration ist eine Mentalität und eine Teamstrategie. Darüber hinaus sagt der Autor und Sprecher Martin Fowler, dass Continuous Integration eine Softwareentwicklungspraxis ist, bei der die Mitglieder eines Teams ihre Arbeit häufig integrieren – normalerweise integriert jede Person mindestens täglich, was zu mehreren Integrationen pro Tag führt.
Jede Integration wird durch einen automatisierten Build (inklusive Test) verifiziert, um Integrationsfehler schnellstmöglich zu erkennen.
Richtig angewendet, führt dieser Ansatz zu geringeren Integrationsproblemen, da sie früher im Prozess erkannt werden.
Die Ziele von Continuous Integration sind:
- Nutzen der Zusammenarbeit
- Ermöglichen paralleler Entwicklung
- Minimieren von Integrationsschulden
- Fungieren als Qualitätsschleuse (Quality Gate)
- Ganzheitliche Automatisierung!
Hinweis
Beachten Sie, dass die Ziele von Continuous Integration auch kontinuierliche Zusammenarbeit, Continuous Delivery und kontinuierliche Qualität umfassen!
Was aber passiert, wenn es keine Continuous Integration gibt? Ein Mangel an Continuous Integration-Bemühungen kann häufig in Folgendem resultieren:
- Lange Entwicklungszyklen
- Nicht kompilierfähiger Code
- Zu einem beliebigen Zeitpunkt ist der Quellcode möglicherweise nicht funktionsfähig
- Code Freezes
- Hohe Anzahl von Buildausfällen/Fehlern
- Langlebige Branches, die mehrtägigen Zusammenführungsaufwand verursachen
- In der Quellcodeverwaltung fehlender Code
- Spät im Entwicklungszyklus gefundene Sicherheitslücken
- Große Mengen technischer Schulden
- Keine oder niedrige Code Coverage-Zahlen
- Insgesamt verringerte Qualität
- Eingeschränkte Kommunikation und Zusammenarbeit
- Code hält Programmierstandards nicht ein
- Keine oder wenige Code Reviews
- Testen spät im Entwicklungszyklus
- In vielen Fällen manuell, wenn überhaupt
Integrationspunkte sind die schnelle Feedbackschleife, die zur Verbesserung des Systems dient. Wenn sich das Timing von Integrationspunkten verschiebt, ist das Projekt in Schwierigkeiten. Folgendes sagt Dantar Oosterwal darüber in dem Buch The Lean Machine:
Die Offenbarung der Integrationspunkte ist, dass sie die Produktentwicklung steuern. Sie sind die Ansatzpunkte, um das System zu verbessern. Wenn sich das Timing von Integrationspunkten verschiebt, ist das Projekt in Schwierigkeiten.
Dantar Oosterwal, The Lean Machine
© Scaled Agile, Inc.
Wenn Sie sich fragen, ob Ihr Team wirklich Continuous Integration betreibt, können Ihnen diese Fragen helfen, die Antwort zu finden.
- Arbeiten alle Entwickler trunkbasiert?
- Löst jede Änderung an einem Trunk einen Buildprozess aus?
- Wenn Build und Test fehlschlagen, repariert das Team den Build innerhalb weniger Minuten?
Die Leistung wird auch durch das Vorhandensein oder Fehlen von Continuous Integration beeinflusst. Daten, die für das Buch The Science Of DevOps – Accelerate – Building and scaling high performing technology organizations, von Nicole Forsgren, Jez Humble und Gene Kim, gesammelt und analysiert wurden, zeigen, dass die Qualität bei Low Performern abnimmt, wenn deren Geschwindigkeit der Markteinführung steigt.
High Performer können die Qualität aber erhalten und gleichzeitig die Markteinführung beschleunigen. Sie haben kürzere (und weniger komplexe) Bereitstellungszyklen und nutzen Continuous Integration, um Probleme sofort zu beheben, was den Fluss und die Effizienz erhöht.
| 2017 | High Performer | Medium Performer | Low Performer |
|---|---|---|---|
| Bereitstellungshäufigkeit | Mehrmals pro Tag | 1 Woche – 1 Monat | 1 Woche – 1 Monat |
| Vorlaufzeit für Änderungen | < 1 Stunde | 1 Woche – 1 Monat | 1 Woche – 1 Monat |
| MTTR | < 1 Stunde | < 1 Tag | 1 Tag – 1 Woche |
| Fehlerrate bei Änderungen | 0–15 % | 0–15 % | 31–45 % |