Continuous Integration, Delivery

CI

CI ist der Teil, in dem der Workflow jeden Entwickler-Commit automatisch validieren sollte.

Die automatischen Unit- und Funktionstests werden von der Integrationsmaschine z.B. GitLab CI oder CircleCi validiert. Sobald die Tests bestanden sind, wird ein Build/Artefakt erzeugt und in der TEST-Umgebung bereitgestellt.

Um zu einem Build/Artefakt zu gelangen

• Der Code wird bei jedem Commit gebaut
• Der Code wird bei jedem Commit automatisch unitgetestet
• Jeder hat Zugriff auf den Build- und Testbericht
• Tests werden auf einer verkleinerten Version der Produktionsumgebung ausgeführt
• Deliverables werden in einem versionskontrollierten Artefakt-Repository gespeichert
• Deliverables werden nach einem erfolgreichen Build automatisch in einer Testumgebung bereitgestellt

Wenn einer der Schritte fehlschlägt, erhält der für den Commit verantwortliche Entwickler eine Benachrichtigung, um so schnell wie möglich zu korrigieren.

Die Implementierung eines CIs und aller zu integrierenden Prozesse

Die verschiedenen Arten von Tests

• Unit-Tests dienen zum Testen von Methoden oder Funktionen, die nicht für das Projekt erforderlich sind.
• Integrationstests dienen dazu, sicherzustellen, dass sich mehrere Komponenten zusammen korrekt verhalten, sie sind für funktionale Regressionen
• Abnahmetests ähnlich der Integration, aber mit Fokus auf das Geschäft
• Tests der Benutzeroberfläche dienen dazu, sicherzustellen, dass die Aktionen der Benutzeroberfläche aus Sicht des Benutzers funktionieren

Um kontinuierliche Integration einzuführen, müssen Sie Ihre Tests in jedem Zweig, den Sie pushen, ausführen.

Dazu einige einfache Fragen:

• Wo wird der Code gehostet? Einschränkung…
• welches Betriebssystem und welche Ressourcen benötigen wir für die Anwendung? Abhängigkeiten…
• Wie viele Ressourcen benötigen wir für Ihre Tests?
• Ist die Anwendung monolithisch oder Microservice?
• Verwenden Sie Container? Docker…

Test coverage & complexity

Es ist gut, eine Abdeckung von mehr als 80% anzustreben, aber seien Sie vorsichtig, einen hohen Abdeckungsgrad nicht mit einer guten Testsuite zu verwechseln. Ein Code-Coverage-Tool hilft uns, den ungetesteten Code zu finden. Die Qualität Ihrer Tests wird am Ende des Tages den Unterschied ausmachen.
Ein Werkzeug wie SonarQube ist dazu da, Entscheidungen zu treffen, wenn der Code komplex und ungetestet ist.

Duplizierung und toter Code

Duplizierter Code ist der zukünftige tote Code oder der zukünftige doppelt behobene Fehler! Es ist sehr wichtig, Ihren Code zu überprüfen und Duplikation zu reduzieren. Maximal 5% duplizierter Code bei einem großen oder Legacy-Projekt ist akzeptabel, aber versuchen Sie, bei jedem Projekt, das mit Qualitätscode-Metriken beginnt, unter 2% zu bleiben.

Refactoring

Wenn Sie im Begriff sind, signifikante Änderungen an Ihrer Anwendung vorzunehmen, die keine ausreichende Testabdeckung haben, sollten Sie damit beginnen, Akzeptanztests für die Funktionen zu schreiben, die davon betroffen sein könnten. Dies bietet ein Sicherheitsnetz, um sicherzustellen, dass das ursprüngliche Verhalten nach einem Refactoring oder dem Hinzufügen neuer Funktionen nicht beeinträchtigt wurde.

Die Umgebung

Das gesamte IT-Dev/DevOps/Admin-Team sollte darauf achten, überall die gleiche Umgebung beizubehalten. Die Revisionsnummer aller von der Anwendung verwendeten Komponenten sollte in Dev/Build/Test/Integration/Prod die gleiche sein. Hier sind Container (Docker) und Orchestratoren (Kubernetes) nützlich.

Denkweise

Wenn ein Entwickler den CI-Workflow stört, hat die Behebung des Fehlers oberste Priorität.

Um gute Tests zu schreiben, müssen Sie sicherstellen, dass die Entwickler einbezogen werden und Zugriff auf ein Code-Analyse-Tool haben.

Unabhängig davon, ob Sie eine bestehende Code-Basis haben oder gerade erst anfangen, sind Bugs als Teil Ihrer Releases vorprogrammiert. Stellen Sie sicher, dass Sie Tests hinzufügen, wenn Sie die Probleme beheben, um zu verhindern, dass sie wieder auftreten.

CD

Die Bereitstellung der Anwendung wird durch den Code verwaltet. Der Code beschreibt genau, was die Anwendung zum Starten und Ausführen benötigt. Das Artefakt und die Umgebung werden zwischen den Systemen Test/Integration/Production gleich sein, da das Image nur einmal vom CI erzeugt wird.

Continuous Delivery

Nach der Automatisierung der Erstellung und der Unit- und Integrationstests bei der kontinuierlichen Integration automatisiert die kontinuierliche Auslieferung die Veröffentlichung des validierten Codes in einer Registry/einem Repository. Um die Effektivität des Continuous-Delivery-Prozesses zu gewährleisten, muss der Continuous-Delivery-Prozess daher zunächst in die Entwicklungspipeline eingeführt werden. Continuous Delivery stellt sicher, dass die Codebasis immer bereit ist, in einer Produktionsumgebung eingesetzt zu werden.

Bei der kontinuierlichen Bereitstellung umfasst jeder Schritt (vom Zusammenführen der Codeänderungen bis zur Verteilung der produktionsreifen Versionen) die Automatisierung der Code-Test- und Freigabeprozesse. Am Ende dieses Prozesses ist das Betriebsteam in der Lage, eine Anwendung einfach und schnell in einer Produktionsumgebung einzusetzen.

Continuous Deployment

Der letzte Schritt in einer ausgereiften CI/CD-Pipeline ist die kontinuierliche Bereitstellung. Zusätzlich zum Continuous-Delivery-Prozess, der die Freigabe einer produktionsreifen Version in ein Code-Repository automatisiert, automatisiert das Continuous Deployment den Start einer Anwendung in eine Produktionsumgebung. In Ermangelung einer manuellen Brücke zwischen der Produktion und der vorherigen Stufe der Pipeline hängt die kontinuierliche Bereitstellung in erster Linie von der Gestaltung automatisierter Testprozesse ab.

In der Praxis könnte eine Änderung, die ein Entwickler an einer Anwendung vornimmt, unter Continuous Deployment innerhalb von Minuten nach dem Schreiben des betreffenden Codes freigegeben werden (vorausgesetzt, er besteht die automatisierten Tests). Das macht es viel einfacher, kontinuierlich Benutzer-Feedback zu erhalten und zu integrieren. Zusammen reduzieren diese drei CI/CD-Praktiken die Risiken, die mit der Anwendungsbereitstellung verbunden sind, da es einfacher ist, Änderungen in kleinen Inkrementen als in einem einzigen Block zu veröffentlichen. Dieser Ansatz erfordert jedoch eine erhebliche Vorabinvestition, da automatisierte Tests geschrieben werden müssen, um eine Vielzahl von Test- und Freigabestufen in der CI/CD-Pipeline zu berücksichtigen.