Continuous Integration (CI)

CI ist eine Praxis der Softwareentwicklung, bei der Entwickler ihre Änderungen am Code regelmäßig in einer zentralen Repository integrieren, in der Regel mehrmals täglich. Dieser Ansatz soll Probleme wie Merge-Konflikte oder schwer auffindbare Fehler aufgrund von Inkonsistenzen im Code frühzeitig erkennen und beheben.

Vor- und Nachteile von CI/CD

Einige der Hauptvorteile von CI sind:

• Früherkennung von Fehlern und Konflikten: Durch regelmäßige Integration und automatisierte Tests findet die Fehlerfindung und dadurch die Behebung der Fehler frühzeitig statt, bevor sie zu größeren Problemen führen.
• Reduzierung von Risiken: Da man Änderungen in kleineren Schritten und häufiger integriert, reduziert sich das Risiko, dass neue Funktionen bestehende Funktionen beeinträchtigen.
• Verbesserung der Codequalität: CI ermutigt Entwickler, Code häufiger zu testen, was zur Verbesserung der Codequalität beiträgt.

CI-Tools:

Es gibt eine Vielzahl von CI-Tools auf dem Markt, darunter Jenkins, GitLab CI, Travis CI und CircleCI. Diese Tools automatisieren den Integrationsprozess, indem sie den Code überprüfen, bauen und testen, sobald Änderungen eingecheckt sind.

Continuous Deployment (CD)

Continuous Deployment ist ein Prozess, bei dem man automatisierte Tests und Freigabeprozesse durchführt, um neue Codeänderungen kontinuierlich und in kürzester Zeit in die Produktionsumgebung einzuführen. Im Gegensatz zu Continuous Delivery, bei dem man die Freigabe in die Produktion noch manuell auslösen muss, geschieht dies bei Continuous Deployment vollautomatisch.

Vorteile von CD:

• Schnellere Markteinführung: Durch den Einsatz von CD kann man Software schneller auf den Markt und in Umlauf bringen, da man dadurch den manuellen Aufwand für die Bereitstellung minimiert.
• Automatisierte Fehlerbehebung: CD-Systeme bieten Möglichkeiten zur automatischen Fehlerbehebung und Rollbacks, um sicherzustellen, dass die Produktionsumgebung stabil bleibt.
• Bessere Zusammenarbeit: Durch CD kann man verschiedene Teams wie die Entwicklung, QA bzw. Testing und Operations besser aufeinander abstimmen, was die Zusammenarbeit und Kommunikation wesentlich verbessert.

CD-Tools:

Zu den beliebtesten CD-Tools gehören Spinnaker, GitLab CD, Octopus Deploy und Harness. Diese Tools helfen bei der Automatisierung von Bereitstellungsprozessen, einschließlich der Erstellung von Umgebungen, dem Ausführen von Tests und dem Verwalten von Konfigurationen.

Einige wichtige Punkte, die noch bei der Einführung und Anwendung von CI/CD zu beachten sind:

• Organisationskultur: Die Implementierung von CI/CD erfordert eine Veränderung in der Denkweise und Kultur eines Teams oder einer Organisation. Es ist wichtig, dass alle Beteiligten die Vorteile erkennen und bereit sind, sich auf kontinuierliche Verbesserung und Zusammenarbeit zu konzentrieren.
• Automatisierung: Um die Vorteile von CI/CD voll auszuschöpfen, ist es entscheidend, möglichst viele Schritte im Entwicklungs- und Bereitstellungsprozess zu automatisieren. Dies kann das Schreiben von Skripten für das Erstellen, Testen und Bereitstellen von Code oder die Verwendung von Tools und Plattformen umfassen, die diese Prozesse unterstützen.
• Testabdeckung: Um sicherzustellen, dass der Code in einer CI/CD-Pipeline zuverlässig funktioniert, ist es wichtig, ausreichende Testabdeckung sicherzustellen. Dies umfasst sowohl Unit-Tests als auch Integrationstests, um sicherzustellen, dass alle Aspekte einer Anwendung korrekt funktionieren. Hier macht es Sinn den Beitrag SonarQube zu erwähnen 😉
• Monitoring und Feedback: Im Zusammenhang mit CI/CD ist es wichtig, ein effektives Monitoring-System einzurichten, um Leistungsprobleme oder Fehler frühzeitig zu erkennen. Ebenso ist ein Feedback-System für Entwickler und Stakeholder entscheidend, um kontinuierlich voneinander zu lernen und Verbesserungen vorzunehmen. Hierzu schreibe ich in zukünftigen Beiträgen mehr. Bis es so weit ist, ist der Beitrag über Grafana erwähnenswert 😉
• Sicherheit: Bei der Implementierung von CI/CD ist es unerlässlich, Sicherheitspraktiken zu berücksichtigen. Dies umfasst die regelmäßige Überprüfung von Sicherheitspatches, die Durchführung von Sicherheitstests und die Einhaltung von Best Practices für sicheren Code.

Fazit

Continuous Integration und Continuous Deployment sind entscheidende Konzepte in der modernen Softwareentwicklung, die dazu beitragen, den Entwicklungsprozess zu beschleunigen, die Codequalität zu verbessern und die Zusammenarbeit zwischen Teams zu fördern. Durch die Einführung von CI/CD-Praktiken im Entwicklungsworkflow kann man Fehler frühzeitig erkennen, den Zeitaufwand für die Behebung von Problemen reduzieren und die Bereitstellung neuer Funktionen und Updates beschleunigen.

Indem man diese Faktoren berücksichtigt und CI/CD-Praktiken erfolgreich in einem Softwareentwicklungsprozess integriert, kann man von den Vorteilen der schnelleren Entwicklungszyklen, verbesserten Zusammenarbeit und von einer höheren Codequalität profitieren.

Der Beitrag CI/CD – Continuous Integration und Continuous Deployment erschien zuerst auf CEOsBay.

Was ist DevOps?

DevOps ist ein Kofferwort, das aus den Begriffen „Development“ (Entwicklung) und „Operations“ (Betrieb) zusammengesetzt ist. Es beschreibt eine Philosophie, Kultur und Praxis, die darauf abzielt, die Zusammenarbeit und Kommunikation zwischen Entwicklern (Dev) und IT-Experten im Betrieb (Ops) zu verbessern. Der Ansatz ermöglicht es, Software schneller und mit höherer Qualität zu entwickeln, bereitzustellen und zu überwachen.

Grundprinzipien von DevOps

1. Zusammenarbeit: DevOps legt Wert auf eine enge Zusammenarbeit zwischen den verschiedenen Teams, um Wissensaustausch, gegenseitiges Verständnis und gemeinsame Verantwortung zu fördern.
2. Automatisierung: Die Automatisierung von Prozessen spielt eine zentrale Rolle in DevOps, um manuelle Aufgaben zu reduzieren und um Fehler zu minimieren.
3. Continuous Integration (CI): CI ist das automatisierte Zusammenführen von Codeänderungen aus unterschiedlichen Entwicklungsarbeiten. Dadurch kann man frühzeitig mögliche Konflikte oder Fehler erkennen und beheben.
4. Continuous Delivery (CD): Hierbei handelt es sich um die fortlaufende Bereitstellung von Software in verschiedenen Umgebungen (Test (Siehe TDD und BDD)), Staging, Produktion) zur Validierung und schnellen Bereitstellung von Updates.
5. Feedback und Lernen: DevOps ermutigt Teams, kontinuierlich Feedback zu sammeln und daraus zu lernen, um stetige Verbesserungen in der Softwareentwicklung zu erzielen.

Vorteile von DevOps

1. Schnellere Auslieferung bzw. Markteinführung: Durch die verbesserte Zusammenarbeit und Automatisierung von Prozessen kann man Software schneller entwickeln und ausliefern, was zu einem Wettbewerbsvorteil führt.
2. Höhere Qualität: Man kann Fehler frühzeitig entdecken und beheben, wodurch man die Qualität der Software verbessert.
3. Reduzierte Kosten: Durch effizientere Prozesse und Automatisierung kann man die Kosten senken und Ressourcen optimal nutzen.
4. Erhöhte Flexibilität: Die enge Zusammenarbeit und ständige Verbesserung der Prozesse ermöglichen es Unternehmen, schneller auf Veränderungen zu reagieren und Innovationen voranzutreiben.

Nachteile von DevOps

Obwohl es zahlreiche Vorteile für Unternehmen und Entwicklerteams bietet, gibt es auch einige Nachteile, die man bei der Einführung und Umsetzung dieses Ansatzes berücksichtigen sollte:

1. Kulturelle Herausforderungen: Eine der größten Herausforderungen bei der Implementierung von DevOps ist der Wandel der Unternehmenskultur. Die Zusammenarbeit zwischen Entwicklern und IT-Experten im Betrieb erfordert eine Änderung von Denkmustern und Arbeitsweisen, was nicht immer einfach ist.
2. Anfangsinvestition: Um es erfolgreich umzusetzen, müssen Unternehmen oft in neue Tools, Technologien und Schulungen investieren. Dies kann insbesondere für kleinere Unternehmen eine finanzielle Belastung darstellen.
3. Komplexität: Die Einführung von DevOps kann zu erhöhter Komplexität führen, da man zusätzliche Prozesse und Tools in den Entwicklungs- und Betriebsablauf integrieren muss. Dies erfordert eine umfangreiche Planung und Koordination, um effizient und erfolgreich zu sein.
4. Widerstand im Team: Nicht alle Teammitglieder sind von Anfang an von den Vorteilen von DevOps überzeugt. Einige können skeptisch sein oder den Wandel ablehnen, was zu Konflikten und Spannungen innerhalb des Teams führen kann.
5. Sicherheitsrisiken: Trotz des DevSecOps-Ansatzes, bei dem man Sicherheit in den Entwicklungsprozess integriert, kann die Einführung von DevOps zu zusätzlichen Sicherheitsrisiken führen. Zum Beispiel kann die automatisierte Bereitstellung von Code unbeabsichtigte Sicherheitslücken oder Fehler aufweisen, die Angreifern ausnutzen könnten.
6. Kontinuierliche Anpassung: Da DevOps ein agiles Vorgehen erfordert, müssen sich Teams ständig an neue Technologien, Methoden und Prozesse anpassen. Dies kann anstrengend und zeitaufwändig sein und dazu führen, dass sich einige Mitarbeiter überfordert fühlen.

Um diese Nachteile zu minimieren, ist es wichtig, bei der Einführung von DevOps eine gut durchdachte Strategie zu verfolgen, die alle Aspekte des Prozesses berücksichtigt. Offene Kommunikation, Schulungen und das Sammeln von Feedback sind entscheidend, um ein erfolgreiches DevOps-Umfeld zu schaffen und die möglichen Nachteile zu bewältigen.

Best Practices für DevOps

1. Kultur der Zusammenarbeit fördern: Es ist entscheidend, ein Arbeitsumfeld zu schaffen, in dem Entwickler und IT-Experten im Betrieb offen kommunizieren und zusammenarbeiten können.
2. Tools und Technologien nutzen: Für eine erfolgreiche Implementierung von DevOps ist es wichtig, geeignete Tools und Technologien einzusetzen, um Prozesse zu automatisieren und die Zusammenarbeit zu erleichtern. Dazu zählen CI/CD-Tools wie Jenkins oder GitLab bzw. GitHub, Container-Technologien wie Docker und Kubernetes sowie Monitoring- und Logging-Tools wie Grafana und ELK Stack.
3. Infrastruktur als Code (IaC) einsetzen: Mit IaC können Entwickler und Betriebsteams die Infrastruktur ähnlich wie bei Softwareanwendungen entwickeln, verwalten und versionieren. Dadurch kann man die Konsistenz und Reproduzierbarkeit der Umgebungen gewährleisten. Beispiele für IaC-Tools sind Terraform, Ansible und Chef.
4. Monitoring und Feedback: Um kontinuierlich zu lernen und Verbesserungen voranzutreiben, sollten Unternehmen umfangreiches Monitoring einsetzen, um Probleme frühzeitig zu erkennen und Feedback in den Entwicklungsprozess einfließen zu lassen.
5. Sicherheit integrieren: Man sollte auch den Aspekt der Sicherheit berücksichtigen, indem Entwickler und Betriebsteams eng mit Sicherheitsexperten zusammenarbeiten. Der Ansatz „DevSecOps“ betont die Integration von Sicherheitsmaßnahmen in den gesamten Softwarelebenszyklus.
6. Experimentieren und Lernen: Man sollte DevOps-Teams immer wieder ermutigen, kontinuierlich neue Technologien, Prozesse und Methoden auszuprobieren, um aus Fehlern zu lernen und Innovationen voranzutreiben.

Fazit

DevOps ist eine transformative Strategie, die in der modernen Softwareentwicklung unerlässlich geworden ist. Durch die Zusammenarbeit zwischen Entwicklern und IT-Experten im Betrieb, die Automatisierung von Prozessen und den kontinuierlichen Feedback- und Lernprozess wird die Softwareentwicklung beschleunigt, die Qualität verbessert und die Flexibilität erhöht.

Die Einführung von DevOps erfordert jedoch Zeit und Engagement, um sowohl die Kultur als auch die notwendigen Technologien und Prozesse in einem Unternehmen zu etablieren. Eine erfolgreiche Implementierung von DevOps setzt voraus, dass Unternehmen bereit sind, sich kontinuierlich weiterzuentwickeln und ihre Teams mit den notwendigen Ressourcen und dem Wissen auszustatten. Der Einsatz von Best Practices und eine fortwährende Verbesserung der Prozesse sind Schlüsselfaktoren für den Erfolg von DevOps in der Softwareentwicklung.

Der Beitrag DevOps – Entwickeln, bereitstellen und verbessern erschien zuerst auf CEOsBay.

Kurze Zeitreise

Jenkins ist in erster Linie eine Entwicklung von Kohsuke Kawaguchi. Einem ehemaligen Mitarbeiter von Sun Microsystems, der es unter dem Namen Hudson entwickelt hat. Kawaguchi verließ das Unternehmen, nachdem Oracle es Ende Januar 2010 übernahm. Er behielt aber die Leitung bei Hudson und arbeitete nach eigenen Angaben auf freiberuflicher Basis weiter bei Oracle. Oracle hielt nach wie vor die Namensrechte an Hudson. Aus diesem Grund hat man das Projekt schließlich in Jenkins umbenannt. Die Namensgebung erfolgte laut der Entwickler aufgrund der äquivalenten Assoziation der beiden Wörter mit dem Beruf des Butlers.

Oracle trieb die Entwicklung von Hudson weiterhin voran. Deshalb spricht man heute von einem Fork (einer „Abspaltung“) in der Softwareentwicklung. Im Jahr 2016 wurde die Entwicklung von Hudson zugunsten von Jenkins eingestellt und der Eclipse Foundation gespendet. Die Entwicklung wird jetzt als Open-Source-Projekt unter der Leitung der CD Foundation, einer Organisation innerhalb der Linux Foundation, verwaltet.

Wofür Pipelines?

Im Grunde genommen automatisieren Pipelines Tests und Berichte zu isolierten Änderungen in einer größeren Codebasis in Echtzeit und erleichtern die Integration unterschiedlicher Codezweige in einen Hauptzweig. Man erkennt dadurch schnell Fehler in einer Codebasis, erstellt die Software, automatisiert das Testen der Builds, bereitet die Codebasis für die Bereitstellung (Auslieferung) vor und stellt schließlich Code in Containern und auf virtuellen Maschinen sowie Bare-Metal- und Cloud-Servern bereit. Es gibt auch kommerzielle Versionen von Jenkins, auf die ich in diesem Beitrag aber nicht weiter eingehe.

Continious Integration / Kontinuierliche Integration

Kontinuierliche Integration hat sich seit der Erfindung weiterentwickelt. Ursprünglich war es die Norm, dass Teams einen Build pro Tag veröffentlichten. Nun ist es die Regel, dass jedes Teammitglied täglich oder häufiger Aktualisierungen einreicht, die man als Commit bezeichnet (Siehe Git / GitHub). Dies erfolgt bei jeder wesentlichen Änderung eines Builds. Bei der richtigen Anwendung bietet Continuous Integration verschiedene Vorteile, wie zum Beispiel ständige Rückmeldungen zum Status der Software. Da man durch CI, Mängel frühzeitig in der Entwicklung erkennt, sind Fehler in der Regel kleiner, weniger komplex und leichter zu beheben.

Jenkins und CI/CD

Im Laufe der Zeit wurden Jenkins Continuous Delivery und Deployment hinzugefügt. Continuous Delivery bedeutet, dass das Erstellen und Packen von Code für die spätere Bereitstellung in Test-, Produktions-Staging- und Produktionsumgebungen automatisiert wird. Continuous Deployment automatisiert den letzten Schritt der Bereitstellung des Codes an seinem endgültigen Ziel.

In beiden Fällen reduziert die Automatisierung die Anzahl der auftretenden Fehler, da die richtigen Schritte und Best Practices in Jenkins kodiert sind. Jenkins beschreibt einen gewünschten Zustand und der Automatisierungsserver stellt sicher, dass dieser Zustand erreicht wird. Darüber hinaus macht diese Automatisierung die Bereitstellung schneller, da Vorgänge nicht mehr an personelle Beschränkungen gebunden sind. Schließlich reduziert es die Belastung des Entwicklungs- und Betriebsteams, indem es die Notwendigkeit von manuellen Rollouts mitten in der Nacht und am Wochenende beseitigt.

Jenkins und Microservices

Jenkins bewährt sich besonders in Microservices-Architekturen. Da es eines der Ziele von Microservices ist, Anwendungen und Dienste häufig zu aktualisieren, sollte man dafür sorgen, dass die Bandbreite die Releases nicht verzögert. Mehr und kleinere Dienste mit schnelleren Update-Intervallen lassen sich nur durch Automatisierung gut umsetzen – und dafür ist es wohl die richtige Wahl.

Jenkins X

Das Jenkins X-Projekt wurde 2018 mit dem Ziel gestartet, eine moderne, Cloud-native Version von Jenkins zu erschaffen. Das Projekt steht ebenfalls unter der Leitung der CD Foundation. Die Architektur, Technologie und Pipeline-Sprache unterscheiden sich grundsätzlich von Jenkins. Jenkins X ist für Kubernetes konzipiert und verwendet es in einer eigenen Implementierung. Andere Cloud-native Technologien, die Jenkins X verwendet, sind Helm und Tekton, auf die ich in gesonderten Beiträgen eingehen werde.

Wie funktioniert Jenkins?

Jenkins läuft auf einer Vielzahl von Betriebssystemen bzw. Plattformen. Darunter gibt es Windows, MacOS und Unix-Varianten. Am besten jedoch läuft es auf Linux. Es erfordert mindestens eine Java 8 VM oder höher und kann auf Oracle Java Runtime Environment oder Open Java Development Kit ausgeführt werden. Normalerweise läuft es als Java-Servlet innerhalb eines Jetty-Anwendungsservers. Es kann aber auch auf anderen Java-Anwendungsservern wie Apache Tomcat ausgeführt werden. Auch kann es in einem Docker-Container ausgeführt werden. Im Docker Hub-Online-Repository sind aus diesem Grund schreibgeschützte Jenkins-Images verfügbar.

Um Jenkins zu auszuführen, werden Pipelines erstellt. Eine Pipeline ist eine Reihe von Schritten, die der Jenkins-Server ausführt. Diese Schritte sind in einem Klartext-Jenkins-File gespeichert. Das Jenkins-File verwendet eine geschweifte Klammersyntax, die einer JSON gleicht. Schritte in der Pipeline werden als Befehle mit Parametern deklariert und in geschweiften Klammern gekapselt. Der Jenkins-Server liest dann die Jenkins-Datei und führt die Befehle aus, wobei der Code die Pipeline vom festgeschriebenen Quellcode zur Produktionslaufzeit weiterleitet. Ein Jenkins-File kann über eine grafische Benutzeroberfläche oder durch Code erstellt werden.

Plugins

Für Jenkins sind eine Reihe von Plugins verfügbar, damit es mit anderen Tools zusammenarbeiten kann. Mit Plugins lässt sich auch der Funktionsumfang der Software erweitern. Fertige bzw. bewährte Plugins können aus dem Online-Repository für Jenkins-PlugIns heruntergeladen und über die Jenkins-Webbenutzeroberfläche oder -CLI (Kommandozeile, Command Line Interface) geladen werden. Man kann aber auch eigene Plugins entwickeln.

Plugins helfen bei der Integration anderer Entwicklertools in die Jenkins-Umgebung, fügen der Web-UI neue Elemente hinzu. Dies dient im Allgemeinen der erleichterten Verwaltung und Benutzung. Ein wichtiges Einsatzgebiet von Plugins ist das Bereitstellen von Integrationspunkten für CI/CD-Quellen und -Ziele. Dazu gehören Software-Versionskontrollsysteme (SVCs) wie Git und Atlassian BitBucket, Container-Laufzeitsysteme – insbesondere Docker, sowie Hypervisoren wie VMware vSphere, Public-Cloud-Instanzen wie Google Cloud Platform und AWS und schließlich Private-Cloud-Systeme wie OpenStack. Es gibt auch Plugins, die eine Kommunikation mit Betriebssystemen über FTP, CIFS und SSH unterstützen.

Plugins verwenden ihren eigenen Satz von Java-Annotationen und Designmustern, die definieren, wie sie instanziiert werden. Die Plugin-Entwicklung nutzt außerdem die Maven-Bereitstellung für Jenkins.

Sicherheit

Bei der Sicherheit geht es vor allem darum den Server und die Benutzer zu schützen. Die Serversicherheit wird mehr oder weniger auf dieselbe Art und Weise erreicht, wie auf regulären Servern. Der Zugriff auf den Standort, beispielsweise eine VM oder einen Bare-Metal-Server, ist so konfiguriert, dass möglichst wenige Prozesse mit dem Server kommunizieren dürfen. Dies wird durch typische Serverbetriebssysteme und Netzwerksicherheitsfunktionen erreicht.

Darüber hinaus ist der Zugriff auf den Server über die Jenkins-Benutzeroberfläche mit den regulären Mechanismen, wie Multi-Faktor-Authentifizierung oder der Beschränkung der Anzahl von legitimierten Benutzern, geschützt.

Jenkins enthält außerdem Sicherheitsfunktionen für die interne Nutzerdatenbank. Man unterscheidet zwei Sicherheitsbereiche. Zum einen den Sicherheitsbereich und den Autorisierungsbereich. Im Sicherheitsbereich regeln Administratoren, wer Zugriff hat, und im Autorisierungsbereich bestimmen die Nutzer selbst, was man mit dem Zugriff anstellen kann.

Fazit

Ein großer Vorteil von Jenkins sind die Unmengen an verfügbaren Plugins. Diese tragen zu einer enormen Flexibilität bei. Auch die umfangreichen Skript- und deklarativen Sprachen, mit denen man stark benutzerdefinierte Pipelines erstellen kann, stellen einen großen Mehrwert dar. Da es weitestgehend neutral ist, passt es gut in die meisten Umgebungen, einschließlich in komplexe Hybrid- und Multi-Cloud-Systeme.

Da Jenkins schon etwas länger als vergleichbare Lösungen in diesem Bereich verwendet wird, gibt es umfangreiche Dokumentationen und zahlreiche Community-Ressourcen, an denen man sich bedienen kann. Diese Ressourcen erleichtern die Installation, Verwaltung und Fehlerbehebung ungemein.

Da die gesamte Lösung auf Java basiert, steht es auf einer soliden Basis, die man mit gängigen Designmustern und Frameworks erweitern kann. Auch wenn sich die Installation relativ einfach gestaltet, kann es relativ schwierig sein, komplexe Pipelines zu entwickeln, zu debuggen und zu warten.

Das Open-Source-System ist außerdem eine Single-Server-Architektur. Dies kann jedoch die Ressourcen auf einen einzigen Computer, eine virtuelle Maschine oder einen Container einschränken. Cluster werden nicht unterstützt. Diese Tatsache kann die Leistung enorm einschränkten. Es kann auch dazu führen, dass es zum Server-Sprawl kommt und man den Überblick über all die einzelnen Jenkins-Server verliert.

Der Beitrag Jenkins – Automatisierte Arbeitsabläufe beim Testing erschien zuerst auf CEOsBay.