Überall dort, wo Software selbst entwickelt oder auch nur gegenüber dem originalen Auslieferungszustand leicht verändert oder re-paketiert wird, benötigt man Systeme, den gesamten Build oder auch nur die Veränderung der Software reproduzierbar und deswegen automatisiert zu durchzuführen. Weil ein solcher Neuaufbau zu Test- und Verifikationszwecken inkrementell mit jeder isolierbaren Änderungen, auch wenn diese klein sein sollte, vorgenommen werden sollte, heißt der zugehörige Prozeß Continuous Integration (CI). Wenn Software auslieferungsfähig paketiert wird, wird dies um Continuous Delivery (CD) erweitert, wenn Software nach Änderungen automatisch installiert wird, heißt es Continuous Deployment (CD).
CI/CD ist eine klassische Schnittstellen-Funktion zwischen Development und Operations. Dennoch hat regelmäßig das Development mehr und stärkere Berührungspunkte mit dem System, daß „Software baut“ und verorten regelmäßig Operations diese Funktion im Verantwortungsbereich des Development. So werden die aus Sicht des Development nachrangigen Funktionen Paketierung und Deployment weniger stark berücksichtigt als aus Sicht eines Betriebs erforderlich. Eine gemeinsame Verantwortung für die diesen Prozeß unterstützende Systeme wird ebenfalls nur unzureichend ausgebaut.
Wir haben in verschiedenen Projekten Erfahrung mit Bitbucket, Gitlab und Jenkins gesammelt. Alle haben Stärken und Schwächen; eine Empfehlung für einzelne Produkte wollen wir hier nicht aussprechen, weil die Auswahl der CI/CD-Komponente so stark an das Gesamtsystem von Source Code Repository und Projektplanung gebunden ist, daß eine isolierte Betrachtung nicht zielführend ist.
Wir empfehlen jedoch aus langjähriger Beratungs- und Projekterfahrung, die prozessualen Anteile Paketierung, Auslieferung und Verifikation des Gesamtsystems nicht zu vernachlässigen.