Kontinuierliche Integration - Anforderungen
Im Folgenden finden Sie eine Liste der wichtigsten Anforderungen für die kontinuierliche Integration.
Check-In Regularly- Die wichtigste Methode für eine ordnungsgemäße kontinuierliche Integration ist das häufige Einchecken in den Trunk oder die Hauptleitung des Quellcode-Repositorys. Das Einchecken des Codes sollte mindestens ein paar Mal am Tag erfolgen. Das regelmäßige Einchecken bringt viele weitere Vorteile. Dadurch werden Änderungen kleiner und es ist weniger wahrscheinlich, dass der Build beschädigt wird. Dies bedeutet, dass die aktuellste Version der Software, auf die zurückgesetzt werden soll, bekannt ist, wenn bei einem nachfolgenden Build ein Fehler gemacht wird.
Es hilft auch, disziplinierter beim Refactoring von Code zu sein und sich an kleine Änderungen zu halten, die das Verhalten bewahren. Es hilft sicherzustellen, dass Änderungen, die viele Dateien ändern, weniger wahrscheinlich mit der Arbeit anderer Personen in Konflikt stehen. Dadurch können die Entwickler explorativer vorgehen, Ideen ausprobieren und verwerfen, indem sie zur letzten festgeschriebenen Version zurückkehren.
Create a Comprehensive Automated Test Suite- Wenn Sie nicht über eine umfassende Suite automatisierter Tests verfügen, bedeutet ein bestehender Build nur, dass die Anwendung kompiliert und zusammengestellt werden kann. Während dies für einige Teams ein großer Schritt ist, ist es wichtig, ein gewisses Maß an automatisierten Tests durchzuführen, um das Vertrauen zu schaffen, dass Ihre Anwendung tatsächlich funktioniert.
Normalerweise gibt es 3 Arten von Tests, die in Continuous Integration durchgeführt werden, nämlich unit tests, component tests, und acceptance tests.
Unit-Tests werden geschrieben, um das Verhalten kleiner Teile Ihrer Anwendung isoliert zu testen. Sie können normalerweise ausgeführt werden, ohne die gesamte Anwendung zu starten. Sie treffen nicht auf die Datenbank (falls Ihre Anwendung eine hat), das Dateisystem oder das Netzwerk. Sie erfordern nicht, dass Ihre Anwendung in einer produktionsähnlichen Umgebung ausgeführt wird. Unit-Tests sollten sehr schnell ausgeführt werden - Ihre gesamte Suite sollte selbst für große Anwendungen in weniger als zehn Minuten ausgeführt werden können.
Komponententests testen das Verhalten mehrerer Komponenten Ihrer Anwendung. Wie bei Unit-Tests muss nicht immer die gesamte Anwendung gestartet werden. Sie können jedoch die Datenbank, das Dateisystem oder andere Systeme (die möglicherweise ausgeblendet werden) treffen. Die Ausführung von Komponententests dauert normalerweise länger.
Keep the Build and Test Process Short - Wenn das Erstellen des Codes und das Ausführen der Komponententests zu lange dauert, treten die folgenden Probleme auf.
Die Benutzer hören auf, einen vollständigen Build durchzuführen, und führen die Tests vor dem Einchecken aus. Sie werden mehr fehlerhafte Builds erhalten.
Der Prozess der kontinuierlichen Integration dauert so lange, dass mehrere Commits stattgefunden haben, bis Sie den Build erneut ausführen können, sodass Sie nicht wissen, welcher Check-in den Build beschädigt hat.
Die Leute checken seltener ein, weil sie ewig darauf warten müssen, dass die Software erstellt und die Tests ausgeführt werden.
Don’t Check-In on a Broken Build- Der größte Fehler bei der kontinuierlichen Integration ist das Einchecken in einen defekten Build. Wenn der Build unterbrochen wird, warten die verantwortlichen Entwickler darauf, ihn zu beheben. Sie identifizieren die Ursache des Bruchs so schnell wie möglich und beheben sie. Wenn wir diese Strategie anwenden, sind wir immer in der besten Position, um herauszufinden, was den Bruch verursacht hat, und um ihn sofort zu beheben.
Wenn einer unserer Kollegen eingecheckt hat und infolgedessen den Build beschädigt hat, benötigen sie einen klaren Überblick über das Problem, um die beste Chance zu haben, das Problem zu beheben. Wenn diese Regel verletzt wird, dauert es unweigerlich viel länger, bis der Build repariert ist. Die Leute gewöhnen sich daran, dass der Build kaputt ist, und sehr schnell geraten Sie in eine Situation, in der der Build die ganze Zeit kaputt bleibt.
Always Run All Commit Tests Locally Before Committing- Stellen Sie immer sicher, dass die für die Anwendung entwickelten Tests zuerst auf einem lokalen Computer ausgeführt werden, bevor Sie sie auf dem CI-Server ausführen. Dies soll sicherstellen, dass die richtigen Testfälle geschrieben werden. Wenn der CI-Prozess fehlerhaft ist, liegt dies an den fehlgeschlagenen Testergebnissen.
Take Responsibility for All Breakages that Result from Your Changes- Wenn Sie eine Änderung vornehmen und alle von Ihnen geschriebenen Tests erfolgreich sind, andere jedoch nicht funktionieren, ist der Build weiterhin fehlerhaft. Normalerweise bedeutet dies, dass Sie einen Regressionsfehler in die Anwendung eingeführt haben. Es liegt in Ihrer Verantwortung - weil Sie die Änderung vorgenommen haben -, alle Tests zu korrigieren, die aufgrund Ihrer Änderungen nicht bestanden wurden. Im Kontext von CI scheint dies offensichtlich, aber tatsächlich ist es in vielen Projekten keine übliche Praxis.