imported>Polluks: /* Nachteile */

2024-03-25T09:13:30Z

Nachteile

Neue Seite

'''Kontinuierliche Integration''' (auch ''fortlaufende'' oder ''permanente Integration''; {{enS|'''continuous integration'''}}, '''''CI''''') ist ein Begriff aus der [[Softwaretechnik|Software-Entwicklung]], der den Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer [[Anwendungsprogramm|Anwendung]] beschreibt. Das Ziel der kontinuierlichen Integration ist die Steigerung der [[Softwarequalität]]. Typische Aktionen sind das [[Compiler|Übersetzen]] und [[Linker (Computerprogramm)|Linken]] der Anwendungsteile, prinzipiell können aber auch beliebige andere Operationen zur Erzeugung abgeleiteter Informationen durchgeführt werden. Üblicherweise wird dafür nicht nur das Gesamtsystem neu gebaut, sondern es werden auch [[Testautomatisierung|automatisierte Tests]] durchgeführt und [[Softwaremetrik]]en zur Messung der Softwarequalität erstellt. Der gesamte Vorgang wird automatisch ausgelöst durch [[Commit|Einchecken]] in die [[Versionsverwaltung]].

Eine Vorstufe der kontinuierlichen Integration ist der ''[[Nightly Build]]'' (nächtlicher [[Erstellungsprozess]]). In der Praxis trifft man auch auf kontinuierliche Integration, gepaart mit einem Nightly Build, um die Vorteile beider Systeme zu kombinieren. In der Methode [[DevOps]] wird diese Automatisierung auch Pipeline genannt, da die einzelnen Schritte sequentiell abgearbeitet werden. Die Pipeline ermöglicht hier, die Entwicklungsgeschwindigkeit zu erhöhen, denn schon nach wenigen Minuten erhält der Entwickler Rückmeldung, ob die Qualitätsansprüche erreicht wurden oder nicht.

Eine Weiterentwicklung der kontinuierlichen Integration stellt die '''[[Continuous Delivery]]''' ('''CD''') dar. Dabei wird in bestimmten Zeitabständen oder bei Erreichen einer bestimmten Qualitätsmetrik eine neue Version der Software ausgeliefert.

== Grundsätze ==
Spätestens seit das Konzept der [[Extreme Programming#Permanente Integration|permanenten Integration]] von [[Kent Beck]] im Rahmen von [[Extreme Programming]] populär gemacht wurde, ist der Begriff der kontinuierlichen Integration an sich bekannt, für die erfolgreiche Einführung müssen allerdings einige Grundsätze (vgl. "Continuous Integration"<ref>FOWLER, Martin. [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] (englisch)</ref> von [[Martin Fowler]]) befolgt werden:

;Gemeinsame [[Codebasis]]: Um innerhalb einer Arbeitsgruppe sinnvoll integrieren zu können, muss eine [[Versionsverwaltung]] existieren, in die alle Entwickler ihre Änderungen kontinuierlich integrieren können.
;Automatisierte Übersetzung: Jede Integration muss einheitlich definierte Tests wie [[Statische Code-Analyse|statische Code-Überprüfungen]] durchlaufen, bevor die Änderungen integriert werden. Dafür ist eine automatisierte Übersetzung notwendig.
:Um Testergebnisse von den Arbeitsumgebungen unabhängig zu machen, empfiehlt sich der Einsatz von separaten Test-Umgebungen. Damit können auf diesen Rechnern auch gezielt Verfahren implementiert werden, um die Testlaufzeit zu minimieren.
;Kontinuierliche Test-Entwicklung: Jede Änderung sollte möglichst zeitgleich mit einem dazugehörigen Test entwickelt werden (beispielsweise mittels [[Testgetriebene Entwicklung|testgetriebener Entwicklung]]). Mit Hilfe von [[Kontrollflussorientierte Testverfahren|kontrollflussorientierten Testverfahren]] (Analyse der Code-Überdeckung, engl.: "Code Coverage Analysis") kann diese Vorgehensweise dokumentiert und kontrolliert werden.
;Häufige Integration: Jeder Entwickler sollte seine Änderungen so oft wie möglich in die gemeinsame Code-Basis integrieren. Mit kurzen Integrations-Intervallen reduziert man das Risiko fehlschlagender Integrationen und sichert gleichzeitig den Arbeitsfortschritt der Entwickler in der gemeinsamen Code-Basis (Datensicherung, engl.: "backup").
;Integration in den Hauptbranch: Jeder Entwickler sollte seine Änderungen in den Hauptbranch des Produktes integrieren, wo dann automatisch ein Build- und Testzyklus gestartet wird. Dieser Build wird der kontinuierliche Integrationsbuild genannt.
;Kurze Testzyklen: Der Test-Zyklus vor der Integration sollte kurz gehalten sein, um häufige Integrationen zu fördern. Mit steigenden Qualitätsanforderungen für die einzelnen Integrationen steigt auch die Laufzeit zur Ausführung der Test-Zyklen. Die Menge der vor der Integration durchgeführten Tests muss sorgfältig abgewogen werden, weniger wichtige Tests werden dann nur nach der Integration durchgeführt.
;Gespiegelte Produktionsumgebung: Die Änderungen sollten in einem Abbild der realen Produktionsumgebung getestet werden.
;Einfacher Zugriff: Auch Nicht-Entwickler brauchen einfachen Zugriff auf die Ergebnisse der Software-Entwicklung. Dies müssen nicht notwendigerweise Quellen sein, sondern kann beispielsweise das in das Testsystem gespielte Produkt für Tester, die Qualitäts-Zahlen für Qualitäts-Verantwortliche, die Dokumentation oder ein fertig paketiertes Abbild für [[Release Manager]] sein.
;Automatisiertes Reporting: Die Ergebnisse der Integrationen müssen leicht zugreifbar sein. Sowohl Entwickler als auch andere Beteiligte müssen leicht Informationen darüber bekommen können, wann die letzte erfolgreiche Integration ausgeführt wurde, welche Änderungen seit der letzten Lieferung eingebracht wurden und welche Qualität die Version hat.
;Automatisierte Verteilung: Jede Version sollte leicht in eine Produktionsumgebung (oder ein Abbild derselbigen) überführt werden können. Hierfür sollte die [[Softwareverteilung]] automatisiert sein.

Kontinuierliche Integration kann auf jedem Rechner mit Zugang zum Quellcode durchgeführt werden. Es ist insbesondere möglich, die Integration gleichzeitig auf unterschiedlichen Systemen (etwa verschiedenen Betriebssystemen) durchzuführen.

== Vorteile ==
* Integrations-Probleme werden laufend entdeckt und behoben (gefixt) – nicht erst kurz vor einem [[Meilenstein (Projektmanagement)|Meilenstein]].
* Frühe Warnungen bei nicht zusammenpassenden Bestandteilen.
* Sofortige [[Modultest|Unittests]] entdecken Fehler zeitnah. Im Idealfall kann so beispielsweise direkt bemerkt werden, wenn ein [[Commit#Versionsverwaltung|Commit]] einen Fehler einführt.
* Ständige Verfügbarkeit eines lauffähigen Standes für Demo-, Test- oder Vertriebszwecke.
* Die sofortige Reaktion des Systems auf das Einchecken eines fehlerhaften oder unvollständigen Codes „erzieht“ die Entwickler im positiven Sinne zu einem verantwortlicheren Umgang und kürzeren Checkin-Intervallen. Der [[Merge]]-Aufwand wird immer größer, je länger man mit der Integration wartet.

== Nachteile ==
* Es gibt keine traditionellen [[Meilenstein (Projektmanagement)|Meilensteine]] im herkömmlichen Sinne mehr.

== Software ==
Beispielhafte Werkzeuge für kontinuierliche Integration: 
* [[Bamboo (Software)|Bamboo]] – ein kommerzieller Server für fortlaufende Integration von [[Atlassian]].
* [[Rational Build Forge]] – ein Framework der [[IBM]]-Tochtergesellschaft [[Rational Software]], das die Build- und Release-Prozesse automatisieren soll.
* [[Apache Continuum|Continuum]] – ein Subprojekt des [[Apache Maven]] Projekts. Unterstützt Maven 1, Maven 2, Ant und Shell-Skripte.
* [[CruiseControl]] – ein [[Java (Programmiersprache)|Java]]-basiertes Framework für kontinuierliche Erstellungsprozesse, Derivate auch für das [[.Net-Framework]] und [[Ruby (Programmiersprache)|Ruby]].
* [[GitLab]] – mit [[MIT-Lizenz]], unterstützt [[Git]] und [[Unix-Shell#Skripte|Shell-Skripte]].
* [[Hudson (Software)|Hudson]] – mit [[MIT-Lizenz]], geschrieben in Java, läuft in [[Servlet]]-Container, unterstützt CVS, Subversion, Ant, Maven und [[Unix-Shell#Skripte|Shell-Skripte]].
* [[Jenkins (Software)|Jenkins]] – mit [[MIT-Lizenz]], geschrieben in Java, läuft standalone oder in [[Servlet]]-Container, unterstützt [[Concurrent Versions System|CVS]], [[Apache Subversion]], [[Git]], [[ClearCase]], [[Apache Ant|Ant]], [[Apache Maven|Maven]], [[Perforce]] und [[Unix-Shell#Skripte|Shell-Skripte]] (Hudson [[Abspaltung (Softwareentwicklung)|Fork]]).
* [[Team Foundation Server]] – eine Plattform für kollaborative Softwareprojekte auf Basis von [[Microsoft SQL Server]] und [[Windows SharePoint Services]].
* [[Teamcity]] – ein Werkzeug von [[JetBrains]], webbasiert, verträglich mit den [[Integrierte Entwicklungsumgebung|integrierten Entwicklungsumgebungen]] [[IntelliJ IDEA]], [[Eclipse (Software)|Eclipse]] und [[Microsoft Visual Studio]].
* [[Travis CI]] – gehostetes und verteiltes Tool für [[GitHub]]-Projekte.

== Weblinks ==
* [http://www.ddj.com/development-tools/212201506 Multi-stage Continuous Integration von Damon Poole] (englisch)
* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous integration] von [[Martin Fowler]] (eine Einführung, englisch)
* [http://www.c2.com/cgi/wiki?ContinuousIntegration Continuous Integration] im ''Portland Pattern Repository'' (englisch)
* [http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix Continuous Integration Server Feature Matrix] (Übersicht über diverse Werkzeuge, englisch)
* [http://www.methodsandtools.com/archive/archive.php?id=42 Continuous Integration: The Cornerstone of a Great Shop] von Jared Richardson (Einführung, englisch)
* [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] von James Shore (Anleitung, englisch)
* [http://jayflowers.com/joomla/index.php?option=com_content&task=view&id=26 A Recipe for Build Maintainability and Reusability] von Jay Flowers (englisch)

== Einzelnachweise ==
<references />

[[Kategorie:Kontinuierliche Integration| ]]

Kontinuierliche Integration - Versionsgeschichte

imported>Polluks: /* Nachteile */