CI/CD Pipeline steht für Continuous Integration/Continuous Delivery, also die fortlaufende Bereitstellung von Software und Infrastruktur.
CI/CD steht für Continuous Integration/Continuous Delivery oder sogar Continuous Deployment. Doch was bedeutet das? Es geht um die fortlaufende Bereitstellung von Software, zumindest klassischerweise. Dank DevOps verwendet man CI/CD Pipelines auch für Infrastruktur. Durch Infrastructure as Code, lässt sich Infrastruktur in Code beschreiben und in einem Code Managementsystem, wie Git einchecken; aus welchen typischerweise die Pipelines getriggert werden.
CI/CD Pipelines bestehen aus zwei den Bereichen Integration, Delivery und manchmal auch Deployment. Es ist also wichtig den Unterschied zu verstehen, um zu wissen was wir automatisieren.
Die beiden (oder sogar drei) Bereiche einer Pipeline
Unter Continuous Integration verstehen wir das regelmäßige integrieren von Code Änderungen in Systeme wie Git (GitLab, GitHub). Heutzutage verwenden Entwicklungsteams eine Vielzahl von Tools und Bibliotheken, sodass jede Änderung am Code integriert und getestet werden muss. Damit kann sichergestellt werden, dass Änderungen nicht die Codebasis beschädigen. Bei jeder Änderung läuft eine Pipeline los, um die Änderung zu integrieren. Das Verpacken und Testen von Code ist automatisiert und führt dazu, dass heutzutage die Testdichte zunimmt.
Continuous Delivery setzt nach der Integration der Änderung an und übernimmt das Bereitstellen der Applikation oder Infrastruktur. Das beschränkt sich allerdings darauf, dass Delivery Prozesse die Software in einem Repository bereitstellen. Soll die fertige Software auch noch deployed werden, sprechen wir von Continuous Deployment.
Wie funktioniert eine CI/CD Pipeline?
Damit eine Pipeline funktioniert, brauchen wir diverse Tools. Den Anfang machen Code Repositories. Am Markt finden Systeme, die auf Git basieren Verwendung. Auf Basis von Git gibt es inzwischen eine große Auswahl an Code Management Systemen, wie GitLab, GitHub oder Bitbucket. In diese Systeme checken Entwickler oder auch DevOps Engineers ihren Code ein. Üblicherweise wird empfohlen, dass der Code mindestens einmal pro Tag eingecheckt wird, aber es gibt gegen oben keine Grenze.
Nach dem der Entwickler seinen Code lokal getestet und dann eingecheckt hat, triggert der Commit die erste Phase der Pipeline. In der Build Phase wird der Code kompiliert, sodass er in danach getestet werden kann. Systeme führen hier diverse Unit Tests durch, um die Funktionsfähigkeit der Anwendung sicherzustellen. Selbstverständlich können in dieser Phase auch User Interface Tests, Security Tests oder diverse Code Analysen durchgeführt werden. Nachdem alle Tests durchgeführt sind, beginnt die Release Phase. Nun werden die dabei erstellten Artifakte in ein Software Repository hochgeladen. An diesem Punkt endet die CI/CD Pipeline.