Kontinuierliche Integration

Im Softwareentwicklung, kontinuierliche Integration (CI) ist die Praxis, alle Arbeitskopien aller Entwickler zu einem gemeinsamen Zusammenhang zu verschmelzen Hauptlinie mehrmals am Tag.[1] Grady Booch Vorgeschlagen vorgeschlagen den Begriff CI in Seine Methode von 1991,[2] Obwohl er sich nicht mehrmals am Tag einsetzte. Extremes Programmieren (XP) übernahm das Konzept von CI und befürwortete mehr als einmal pro Tag - vielleicht bis zu zehnmal pro Tag.[3]

Begründung

Bei einer Änderung, a Entwickler Nimmt eine Kopie des Stroms Codebasis auf dem arbeiten. Wie andere Entwickler geänderten Code in die einreichen Quellcode -RepositoryDiese Kopie hört allmählich auf, den Repository -Code widerzuspiegeln. Der vorhandene Codebasis kann nicht nur sich ändern, sondern auch neuer Code sowie neue Bibliotheken und andere Ressourcen, die Abhängigkeiten und potenzielle Konflikte erzeugen.

Die längere Entwicklung setzt sich an einem Zweig fort, ohne sich auf die Hauptlinie zu verschmelzen, desto größer ist das Risiko mehrerer Integrationskonflikte[4] und Fehler, wenn der Entwicklerzweig schließlich zurückgeführt wird. Wenn Entwickler Code an das Repository senden, müssen sie zuerst ihren Code aktualisieren, um die Änderungen im Repository zu widerspiegeln, da sie ihre Kopie genommen haben. Je mehr Änderungen das Repository enthält, desto mehr Arbeitsentwickler müssen Entwickler vor der Einreichung ihrer eigenen Änderungen erledigen.

Schließlich kann das Repository so unterschiedlich werden von den Baselines der Entwickler, dass sie das, was manchmal als "Zusammenführung" oder "Integration Hell" bezeichnet wird, eingeben.[5] Wo die Zeit für die Integration benötigt wird, übersteigt die Zeit, die sie benötigten, um ihre ursprünglichen Änderungen vorzunehmen.[6]

Workflows

Testen vor Ort ausführen

CI soll in Kombination mit automatisierten Unit -Tests verwendet werden, die durch die Praktiken von geschrieben wurden Testgetriebene Entwicklung. Dies erfolgt durch Laufen und Durch Bestreben aller Einheitstests im lokalen Entwickler des Entwicklers Umgebung Bevor Sie sich zur Hauptlinie verpflichten. Dies hilft zu vermeiden, dass die Arbeit eines Entwicklers in der Progress die Kopie eines anderen Entwicklers bricht. Bei Bedarf können teilweise vollständige Funktionen vor dem Verhalten deaktiviert werden Funktionen umschalten zum Beispiel.

Compile Code in CI kompilieren

Ein Build -Server erstellt den Code regelmäßig oder sogar nach jedem Commit und meldet die Ergebnisse den Entwicklern. Die Verwendung von Build -Servern wurde außerhalb der XP -Community (Extreme Programing) eingeführt, und viele Organisationen haben CI ohne die gesamte XP übernommen.

Führen Sie Tests in CI durch

Zusätzlich zu automatisierten Unit -Tests verwenden Organisationen, die CI verwenden kontinuierlich Bewerbungsprozesse Qualitätskontrolle Im Allgemeinen - kleine Anstrengungsstücke, häufig angewendet. Neben der Ausführung der Einheiten- und Integrationstests führen solche Prozesse zusätzliche statische Analysen, Mess- und Profilleistung durch QA Prozesse. Auf dem Populär Travis CI Der Service für Open-Source führen nur 58,64% der CI-Jobs Tests durch.[7]

Diese kontinuierliche Anwendung der Qualitätskontrolle zielt darauf ab, die zu verbessern Qualität der Software und reduzieren Sie die Zeit, die für die Bereitstellung benötigt wird, indem Sie die traditionelle Praxis der Anwendung der Qualitätskontrolle ersetzen nach alle Entwicklung abschließen. Dies ist der ursprünglichen Idee, häufiger zu integrieren, sehr ähnlich, um die Integration zu vereinfachen, nur für QA -Prozesse angewendet.

Starten Sie ein Artefakt von CI

Jetzt ist CI oft miteinander verflochten mit kontinuierliche Lieferung oder kontinuierliche Bereitstellung in der sogenannten CI/CD -Pipeline. "Continuous Delivery" stellt sicher, dass die in der Hauptstrecke eingecheckte Software immer in einem Zustand ist, der für Benutzer bereitgestellt werden kann, und die "kontinuierliche Bereitstellung" macht den Bereitstellungsprozess vollständig automatisiert.

Geschichte

Die früheste bekannte Arbeit zur kontinuierlichen Integration war die von G. E. Kaiser, D.E. Perry und W. M. Schell entwickelte Infuse -Umgebung.[8]

1994 verwendete Grady Booch die Phrase kontinuierliche Integration in Objektorientierte Analyse und Design mit Anwendungen (2. Auflage)[9] Um zu erklären, wie sich bei der Entwicklung von Mikroprozessen "interne Freisetzungen eine Art kontinuierliche Integration des Systems darstellen und existieren, um die Schließung des Mikroprozesses zu erzwingen".

In 1997, Kent Beck und Ron Jeffries erfunden Extremes Programmieren (Xp) während des Chrysler umfassendes Kompensationssystem Projekt, einschließlich kontinuierlicher Integration.[1][selbstveröffentlichte Quelle] Beck veröffentlichte 1998 über die kontinuierliche Integration und betonte die Bedeutung der persönlichen Kommunikation für die technologische Unterstützung.[10] 1999 arbeitete Beck in seinem ersten vollständigen Buch über extreme Programme mehr aus.[11] Tempomat, eines der ersten Open-Source-CI-Tools,[12][selbstveröffentlichte Quelle] wurde im Jahr 2001 veröffentlicht.

Im Jahr 2010 veröffentlichte Timothy Fitz einen Artikel, in dem beschrieben wurde, wie IMVUDas technische Team hatte das erste praktische CI -System gebaut und verwendet. Während sein Posten ursprünglich mit Skepsis getroffen wurde, fiel er schnell auf und fand eine weit verbreitete Adoption[13] Im Rahmen des Lean Softwareentwicklung Methodik, auch basierend auf IMVU.

Gemeinsame Praktiken

Dieser Abschnitt listet auf empfohlene Vorgehensweise Vorgeschlagen von verschiedenen Autoren, wie sie eine kontinuierliche Integration erreichen und diese Praxis automatisieren können. Automatisierung bauen ist selbst eine beste Praxis.[14][15]

Kontinuierliche Integration - die Praxis, häufig den neuen oder geänderten Code in das vorhandene Code -Repository zu integrieren, sollte häufig genug auftreten, dass kein intervenierendes Fenster dazwischen bleibt verpflichten und bauenund so, dass keine Fehler auftreten können, ohne dass Entwickler sie bemerken und sofort korrigieren.[1] Normale Praxis besteht darin, diese Builds durch jeden Verpflichtung zu einem Repository auszulösen, anstatt einen regelmäßig geplanten Build. Die praktischen Aspekte in einer multi-Entwicklerumgebung mit schnellen Commits sind so, dass es üblich ist, eine kurze Zeit nach jedem Commit zu auslösen, und dann einen Build zu starten, wenn entweder dieser Timer abgelaufen ist, oder nach einem eher längeren Intervall seit dem letzten Build. Beachten Sie, dass der Timer, der für den kurzen Zeitauslöser verwendet wird, dieselbe Technik, die in vielen Schaltflächen -Debouncing -Algorithmen verwendet wird.[16] Auf diese Weise werden die Commit-Ereignisse "entlarvt", um unnötige Builds zwischen einer Reihe von Schnellfeuer-Commits zu verhindern. Viele automatisierte Tools bieten diese Planung automatisch an.

Ein weiterer Faktor ist die Notwendigkeit eines Versionskontrollsystems, das unterstützt Atomic Commits; d.h. Es macht keinen Sinn, nur die Hälfte der geänderten Dateien zu erstellen.

Um diese Ziele zu erreichen, beruht die kontinuierliche Integration auf folgenden Prinzipien.

Verwalten Sie ein Code -Repository

Hauptartikel: Versionskontrolle

Diese Praxis befürwortet die Verwendung eines Revisionskontrollsystems für den Quellcode des Projekts. Alle für den Bau des Projekts erforderlichen Artefakte sollten im Repository platziert werden. In dieser Praxis und der Revisionskontrollgemeinschaft besteht die Konvention darin, dass das System aus einer neuen Kasse erbaubar sein sollte und keine zusätzlichen Abhängigkeiten benötigt. Extremes Programmieren Fürsprecher Martin Fowler erwähnt auch das wo Verzweigung wird durch Tools unterstützt, seine Verwendung sollte minimiert werden.[17] Stattdessen wird es vorgezogen, dass Änderungen integriert werden, anstatt dass mehrere Versionen der Software gleichzeitig aufrechterhalten werden. Die Hauptlinie (oder Rüssel) sollte der Ort für die Arbeitsversion der Software sein.

Automatisieren Sie den Build

Hauptartikel: Automatisierung bauen

Ein einzelner Befehl sollte die Fähigkeit haben, das System aufzubauen. Viele bauen Tools, wie z. machen, haben seit vielen Jahren existiert. Andere neuere Tools werden häufig in kontinuierlichen Integrationsumgebungen verwendet. Die Automatisierung des Builds sollte die Automatisierung der Integration umfassen, die häufig umfasst Einsatz in eine produktionähnliche Umgebung. In vielen Fällen erstellt das Build -Skript nicht nur Binärdateien, sondern generiert auch Dokumentation, Website -Seiten, Statistiken und Vertriebsmedien (wie Debian Deb, Roter Hut Drehzahl oder Fenster MSI Dateien).

Die Selbstprüfung bauen

Sobald der Code erstellt wurde, sollten alle Tests durchgeführt werden, um zu bestätigen, dass er sich so verhält, wie die Entwickler erwarten, dass er sich verhalten wird.[18]

Jeder verpflichtet sich jeden Tag zur Grundlinie

Durch regelmäßiges Engagement kann jeder Committer die Anzahl der widersprüchlichen Änderungen verringern. Das Überprüfen der Arbeit in einer Woche besteht aus dem Risiko, mit anderen Merkmalen widersprüchlich zu sein, und kann sehr schwer zu lösen sein. Frühe, kleine Konflikte in einem Bereich des Systems veranlassen den Teammitgliedern, über die Veränderungen zu kommunizieren, die sie vornehmen.[19] Mindestens einmal täglich alle Änderungen zu begehen (einmal pro Merkmal) wird allgemein als Teil der Definition der kontinuierlichen Integration angesehen. Darüber hinaus durchführen a nächtlich gebaut wird im Allgemeinen empfohlen. Dies sind untere Grenzen; Es wird erwartet, dass die typische Frequenz viel höher ist.

Jeder Commit (zur Grundlinie) sollte gebaut werden

Das System sollte Commits für die aktuelle Arbeitsversion erstellen, um zu überprüfen, ob sie korrekt integriert werden. Eine gängige Praxis ist die Verwendung einer automatisierten kontinuierlichen Integration, obwohl dies manuell erfolgen kann. Die automatisierte kontinuierliche Integration verwendet einen kontinuierlichen Integrationsserver oder Dämon um die zu überwachen Revisionskontrollsystem Führen Sie bei Änderungen den Build -Prozess automatisch aus.

Jeder Bug-Fix-Commit sollte mit einem Testfall geliefert werden

Bei der Behebung eines Fehlers ist es eine gute Praxis, einen Testfall voranzutreiben, der den Fehler reproduziert. Dies vermeidet die Fix, um zurückverkehrt zu werden, und der Fehler, der als a bekannt ist Regression. Forscher haben vorgeschlagen, diese Aufgabe zu automatisieren: Wenn ein Bug-Fix-Commit keinen Testfall enthält, kann er aus den bereits vorhandenen Tests generiert werden.[20]

Halten Sie den Build schnell

Der Build muss schnell abgeschlossen werden, so dass es schnell identifiziert wird, wenn es ein Problem mit der Integration gibt.

Test in einem Klon der Produktionsumgebung

Hauptartikel: Test Umgebung

Ein ... haben Test Umgebung kann zu Fehlern in getesteten Systemen führen, wenn sie in der bereitgestellt werden Produktionsumfeld Weil die Produktionsumgebung in erheblicher Weise von der Testumgebung abweichen kann. Der Aufbau einer Nachbildung einer Produktionsumgebung ist jedoch kostenintensiv. Stattdessen die Testumgebung oder eine separate Vorproduktionsumgebung ("Staging") sollte als skalierbare Version der Produktionsumgebung gebaut werden, um die Kosten zu lindern, während sie aufrechterhalten werden Technologiestapel Komposition und Nuancen. Innerhalb dieser Testumgebungen, Service -Virtualisierung wird üblicherweise verwendet, um On-Demand-Zugang zu Abhängigkeiten zu erhalten (z. B. APIs, Anwendungen von Drittanbietern, Dienste, Dienste, Mainframesusw.), die über die Kontrolle des Teams hinausgehen, sich immer noch weiterentwickeln oder zu komplex sind, um sie in einem virtuellen Testlabor zu konfigurieren.

Machen Sie es einfach, die neuesten Leistungen zu erhalten

Das Erstellen von Builds für Stakeholder und Tester kann die erforderliche Überarbeitung reduzieren, die beim Wiederaufbau einer Funktion erforderlich ist, die die Anforderungen nicht entspricht. Zusätzlich reduziert frühzeitige Tests die Chancen, dass Defekte bis zum Einsatz überleben. Wenn Sie frühere Fehler finden, können Sie die für die Lösung erforderliche Arbeit verringern.

Alle Programmierer sollten den Tag beginnen, indem sie das Projekt aus dem Repository aktualisieren. Auf diese Weise bleiben sie alle auf dem Laufenden.

Jeder kann die Ergebnisse des neuesten Builds sehen

Es sollte leicht herauszufinden, ob der Build bricht und wenn ja, wer die relevante Änderung vorgenommen hat und was diese Änderung war.

Automatisieren Sie die Bereitstellung

Die meisten CI -Systeme ermöglichen das Ausführen von Skripten nach Abschluss eines Builds. In den meisten Situationen ist es möglich, ein Skript zu schreiben, um die Anwendung auf einem Live -Testserver bereitzustellen, den sich jeder ansehen kann. Ein weiterer Fortschritt in dieser Denkweise ist kontinuierliche Bereitstellung, die erfordert, dass die Software direkt in Produktion eingesetzt wird, häufig mit zusätzlicher Automatisierung, um Mängel oder Regressionen zu verhindern.[21][22]

Kosten und Nutzen

Die kontinuierliche Integration soll Vorteile bringen wie:

  • Integrationsfehler werden früh erkannt und sind aufgrund kleiner Änderungen leicht aufzuspüren. Dies spart sowohl Zeit als auch Geld über die Lebensdauer eines Projekts.
  • Vermeidet das Chaos in letzter Minute bei Veröffentlichungsdaten, wenn jeder versucht, seine etwas inkompatiblen Versionen einzuchecken
  • Wenn Unit -Tests ausfallen oder a Insekt Es entsteht, wenn Entwickler die Codebasis in einen fehlerfreien Zustand ohne zurückkehren müssen DebuggenEs gehen nur eine kleine Anzahl von Änderungen verloren (weil häufig die Integration stattfindet)
  • Ständige Verfügbarkeit eines "aktuellen" Builds für Tests, Demo- oder Freigabeberichte
  • Häufiger Code-Check-in drückt Entwickler dazu, einen modularen, weniger komplexen Code zu erstellen

Bei kontinuierlichen automatisierten Tests können Vorteile umfassen:

  • Erzwingt die Disziplin häufiger automatisierter Tests
  • Sofortiges Feedback zum systemweiten Einfluss lokaler Änderungen
  • Software -Metriken generiert aus automatisierten Tests und CI (wie Metriken für Codeabdeckung, Codekomplexität, und Vollständigkeit) Konzentrieren Sie Entwickler auf die Entwicklung funktionaler, Qualitätscode und helfen bei der Entwicklung von Dynamik in einem Team

Einige Nachteile der kontinuierlichen Integration können umfassen:

  • Der Bau einer automatisierten Testsuite erfordert eine beträchtliche Menge an Arbeit, einschließlich fortlaufender Anstrengungen, um neue Funktionen abzudecken und absichtliche Codeänderungen zu befolgen.
    • Testen wird als a betrachtet Best Practice für die Softwareentwicklung selbstständig, unabhängig davon, ob eine kontinuierliche Integration eingesetzt wird oder nicht, und die Automatisierung ist ein wesentlicher Bestandteil von Projektmethoden wie Testgetriebene Entwicklung.
    • Eine kontinuierliche Integration kann ohne Testsuite durchgeführt werden, aber die Kosten von Qualitätssicherung Um ein lösbares Produkt zu produzieren, kann es hoch sein, wenn es manuell und häufig erfolgen muss.
  • Es gibt einige Arbeiten, um a einzurichten System aufbauenund es kann komplex werden, was es schwierig macht, flexibel zu ändern.[23]
  • Die kontinuierliche Integration ist nicht unbedingt wertvoll, wenn der Umfang des Projekts klein ist oder einen untestslichen Legacy -Code enthält.
  • Werte hinzugefügt hängt von der Qualität der Tests und davon ab, wie der Code wirklich testbar ist.[24]
  • Größere Teams bedeuten, dass der Integrationswarteschlange ständig neuer Code hinzugefügt wird. Daher ist die Verfolgung von Lieferungen (während die Qualität der Qualität) schwierig ist und die Warteschlange aufbaut, die alle verlangsamen können.[24]
  • Mit mehreren Commits und Fusion pro Tag kann ein Teilcode für eine Funktion problemlos gedrückt werden, und daher fehlschlagen Integrationstests, bis die Funktion abgeschlossen ist.[24]
  • Sicherheit und missionskritische Entwicklung (z. B.,, z. B.,, Do-178c, ISO 26262) Erfordernde strenge Dokumentation und In-Process-Überprüfung, die mit der kontinuierlichen Integration schwer zu erreichen sind. Diese Art von Lebenszyklus erfordert häufig zusätzliche Schritte, die vor der Produktfreigabe ausgeführt werden müssen, wenn die regulatorische Genehmigung des Produkts erforderlich ist.

Siehe auch

Verweise

  1. ^ a b c Fowler, Martin (1. Mai 2006). "Kontinuierliche Integration". Abgerufen 9. Januar 2014.
  2. ^ Booch, Grady (1991). Objektorientiertes Design: mit Anwendungen. Benjamin Cummings. p. 209. ISBN 9780805300918. Abgerufen 18. August 2014.
  3. ^ Beck, K. (1999). "Veränderung mit extremer Programmierung". Computer. 32 (10): 70–77. doi:10.1109/2.796139. ISSN 0018-9162.
  4. ^ Duvall, Paul M. (2007). Kontinuierliche Integration. Verbesserung der Softwarequalität und Reduzierung des Risikos. Addison-Wesley. ISBN 978-0-321-33638-5.
  5. ^ Cunningham, Gemeinde (5. August 2009). "Integration Hölle". Wikiwikiweb. Abgerufen 19. September 2009.
  6. ^ "Was ist kontinuierliche Integration?". Amazon Web Services.
  7. ^ Durieux, Thomas; Abreu, Rui; Monperrus, Martin; Bissyande, Tegawende F.; Cruz, Luis (2019). "Eine Analyse von mehr als 35 Millionen Arbeitsplätzen von Travis CI". 2019 IEEE International Conference für Software -Wartung und -entwicklung (ICSME). IEEE: 291–295. Arxiv:1904.09416. Bibcode:2019ArXIV190409416d. doi:10.1109/ICSME.2019.00044. ISBN 978-1-7281-3094-1. S2CID 203593737.
  8. ^ Kaiser, G. E.; Perry, D. E.; Schell, W. M. (1989). Infuse: Integrationstestmanagement mit Änderungsmanagement verschmelzen. Proceedings der dreizehnten jährlichen Conference für internationale Computersoftware- und Anwendungen. Orlando Florida. S. 552–558. doi:10.1109/cmpsac.1989.65147.
  9. ^ Booch, Grady (Dezember 1998). Objektorientierte Analyse und Design mit Anwendungen (PDF) (2. Aufl.). Abgerufen 2. Dezember 2014.
  10. ^ Beck, Kent (28. März 1998). "Extreme Programmierung: Eine humanistische Disziplin der Softwareentwicklung". Grundlegende Ansätze für Software Engineering: Erste internationale Konferenz. Vol. 1. Lissabon, Portugal: Springer. p. 4. ISBN 9783540643036.
  11. ^ Beck, Kent (1999). Extreme Programmierung erklärt. Addison-Wesley Professional. p.97. ISBN 978-0-201-61641-5.
  12. ^ "Eine kurze Geschichte von DevOps, Teil III: Automatisierte Tests und kontinuierliche Integration". Circleci. 1. Februar 2018. Abgerufen 19. Mai 2018.
  13. ^ Sane, Parth (2021), "Eine kurze Übersicht über aktuelle Software -Engineering -Praktiken in kontinuierlicher Integration und automatisierte Testen der Zugänglichkeit", 2021 Sechste internationale Konferenz über drahtlose Kommunikation, Signalverarbeitung und Networking (Wispnet), S. 130–134, Arxiv:2103.00097, doi:10.1109/wispnet51692.2021.9419464, ISBN 978-1-6654-4086-8, S2CID 232076320
  14. ^ Brauneis, David (1. Januar 2010). "[OSLC] Mögliche neue Arbeitsgruppe - Automatisierung". Open-Services.net Community (Mailingliste). Archiviert von das Original am 1. September 2018. Abgerufen 16. Februar 2010.
  15. ^ Taylor, Bradley. "Rails -Bereitstellung und Automatisierung mit Shadowpuppet und Capistrano". Rails -Maschine (Blog). Archiviert von das Original am 2. Dezember 2012. Abgerufen 16. Februar 2010.
  16. ^ Siehe zum Beispiel "Divounce". Arduino. 29. Juli 2015.
  17. ^ Fowler, Martin. "Praktiken Methoden Ausübungen". Kontinuierliche Integration (Artikel). Abgerufen 29. November 2015.
  18. ^ Radigan, Dan. "Kontinuierliche Integration". Atlassian Agile Coach.
  19. ^ "Kontinuierliche Integration". Gedankenwerke.
  20. ^ Danglot, Benjamin;Monperrus, Martin;Rudametkin, Walter;Baudry, Benoit (5. März 2020)."Ein Ansatz und ein Benchmark, um Verhaltensänderungen von Commits in der kontinuierlichen Integration zu erkennen". Empirische Software -Engineering. 25 (4): 2379–2415. Arxiv:1902.08482. doi:10.1007/s10664-019-09794-7. ISSN 1382-3256. S2CID 67856113.
  21. ^ Ries, Eric (30. März 2009). "Kontinuierliche Bereitstellung in 5 einfachen Schritten". Radar.O’Reilly. Abgerufen 10. Januar 2013.
  22. ^ Fitz, Timothy (10. Februar 2009). "Kontinuierlicher Einsatz bei IMVU: Das Unmögliche fünfzig Mal am Tag durchführen". WordPress. Abgerufen 10. Januar 2013.
  23. ^ Laukkanen, Eero (2016). "Probleme, Ursachen und Lösungen bei der Einführung kontinuierlicher Lieferung - eine systematische Literaturübersicht". Informations- und Softwaretechnologie. 82: 55–79. doi:10.1016/j.infsof.2016.10.001.
  24. ^ a b c Debbiche, Adam. "Bewertung der Herausforderungen der kontinuierlichen Integration im Kontext der Aufschlüsselung der Softwareanforderungen: Eine Fallstudie" (PDF).

Externe Links