Kontinuierliche Integration - Übersicht
Die kontinuierliche Integration wurde erstmals im Jahr 2000 mit der Software bekannt Cruise Control. Im Laufe der Jahre hat sich die kontinuierliche Integration zu einer Schlüsselpraxis in jeder Softwareorganisation entwickelt. Dies ist eine Entwicklungspraxis, bei der Entwicklungsteams aufgefordert werden, sicherzustellen, dass für jede an einem Softwareprogramm vorgenommene Codeänderung ein Build und anschließende Tests durchgeführt werden. Dieses Konzept sollte das Problem beseitigen, spät auftretende Probleme im Build-Lebenszyklus zu finden. Anstatt dass die Entwickler isoliert arbeiten und nicht genug integrieren, wurde die kontinuierliche Integration eingeführt, um sicherzustellen, dass die Codeänderungen und -erstellungen niemals isoliert durchgeführt wurden.
Warum kontinuierliche Integration?
Die kontinuierliche Integration ist zu einem integralen Bestandteil jedes Softwareentwicklungsprozesses geworden. Der kontinuierliche Integrationsprozess hilft bei der Beantwortung der folgenden Fragen für das Softwareentwicklungsteam.
Arbeiten alle Softwarekomponenten so zusammen, wie sie sollten? - Manchmal können Systeme so komplex werden, dass für jede Komponente mehrere Schnittstellen vorhanden sind. In solchen Fällen ist es immer wichtig sicherzustellen, dass alle Softwarekomponenten nahtlos miteinander arbeiten.
Ist der Code für Integrationszwecke zu komplex? - Wenn der kontinuierliche Integrationsprozess weiterhin fehlschlägt, besteht möglicherweise die Möglichkeit, dass der Code einfach zu komplex ist. Und dies könnte ein Signal sein, geeignete Entwurfsmuster anzuwenden, um den Code weniger komplex und wartbarer zu machen.
Entspricht der Code den festgelegten Codierungsstandards? - In den meisten Testfällen wird immer überprüft, ob der Code den richtigen Codierungsstandards entspricht. Wenn Sie nach dem automatisierten Build einen automatisierten Test durchführen, ist dies ein guter Punkt, um zu überprüfen, ob der Code alle gewünschten Codierungsstandards erfüllt.
Wie viel Code wird von automatisierten Tests abgedeckt? - Es macht keinen Sinn, Code zu testen, wenn die Testfälle nicht die erforderliche Funktionalität des Codes abdecken. Es ist daher immer eine gute Praxis, sicherzustellen, dass die geschriebenen Testfälle alle Schlüsselszenarien der Anwendung abdecken.
Waren alle Tests nach der letzten Änderung erfolgreich? - Wenn ein Test fehlschlägt, macht es keinen Sinn, mit der Bereitstellung des Codes fortzufahren. Daher ist dies ein guter Punkt, um zu überprüfen, ob der Code bereit ist, in die Bereitstellungsphase zu wechseln oder nicht.
Arbeitsablauf
Das folgende Bild zeigt einen kurzen Workflow, wie der gesamte Continuous Integration-Workflow in einem Softwareentwicklungsprojekt funktioniert. Wir werden uns dies in den folgenden Kapiteln genauer ansehen.
Basierend auf dem obigen Workflow funktioniert der kontinuierliche Integrationsprozess im Allgemeinen so.
Zunächst schreibt ein Entwickler den Code in das Versionskontroll-Repository. In der Zwischenzeit fragt der Continuous Integration-Server auf dem Integrations-Build-Computer das Quellcode-Repository nach Änderungen ab (z. B. alle paar Minuten).
Kurz nach dem Festschreiben erkennt der Continuous Integration-Server, dass Änderungen im Versionskontroll-Repository aufgetreten sind. Daher ruft der Continuous Integration-Server die neueste Kopie des Codes aus dem Repository ab und führt dann ein Build-Skript aus, das die Software integriert
Der Continuous Integration Server generiert Feedback, indem er die Build-Ergebnisse per E-Mail an die angegebenen Projektmitglieder sendet.
Unit-Tests werden dann durchgeführt, wenn der Build dieses Projekts erfolgreich ist. Wenn die Tests erfolgreich sind, kann der Code entweder auf dem Staging- oder dem Produktionsserver bereitgestellt werden.
Der Continuous Integration-Server fragt weiterhin nach Änderungen im Versionskontroll-Repository und der gesamte Prozess wird wiederholt.