CI / CD als Service: 10 Tools für die kontinuierliche Integration und Bereitstellung in der Cloud

Die Cloud und die kontinuierliche Integration (CI) sind eine natürliche Übereinstimmung. Während die Cloud uns von der Schwierigkeit befreit, physische Server zu installieren und zu warten, automatisiert die kontinuierliche Integration einen Großteil der Schmerzen beim Erstellen, Testen und Bereitstellen unseres Codes. Wenn beide darauf abzielen, den Entwicklungsteams die Arbeit abzunehmen, ist es nur sinnvoll, sie zu kombinieren und mit einem Schritt noch mehr Plackerei zu vermeiden.

Es gibt viele kontinuierliche Integrationsdienste, die alle zumindest abstrakt das Gleiche tun. Sie beginnen mit einer Liste der Aufgaben wie Kompilieren oder Testen, die ausgeführt werden müssen, bevor die Welt das Genie Ihrer neuen Software schätzen kann. Wenn Sie Ihre Codezeilen festschreiben, arbeiten die Tools die Checkliste durch, bis sie auf eine Straßensperre stoßen. Wenn es keine Straßensperren gibt, sind alle glücklich.

Jeder kann die kontinuierliche Integration für jedes Softwareentwicklungsprojekt verwenden, aber die größten Vorteile genießen Teams, vorzugsweise große Teams, die an denselben ineinandergreifenden Codeblöcken arbeiten. Bei den gründlichsten Implementierungen der kontinuierlichen Integration wird der Code vor dem Testen und erneuten Testen erstellt und neu erstellt, um nach neuen Fehlern und Inkompatibilitäten zu suchen, die möglicherweise beim Einchecken des Codes durch verschiedene Teammitglieder entstanden sind. Continuous Integration Server synchronisieren die Arbeit aller Programmierer und helfen dem Team, Probleme zu erkennen. 

Einige Aufgabenlisten für den CI-Server enden mit den Tests, aber in letzter Zeit erweitern immer mehr Teams die Listen um die Bereitstellung des neuen Codes, ein Prozess, der manchmal als "kontinuierliche Bereitstellung" bezeichnet wird. Eine vollständig automatisierte Bereitstellung macht einige Leute nervös und sie fügen häufig einige manuelle Pausen hinzu. Wenn sie ein bisschen Rechenschaftspflicht und menschliche Sicherheit hinzufügen, können sie sich ein bisschen entspannen. Sie werden diesen hybriden Ansatz als "kontinuierliche Bereitstellung" bezeichnen, da er den Code an einen Staging- oder Testcluster liefert, in dem er darauf wartet, dass ein Mensch den endgültigen Schub für die Produktion macht. 

Wenn die kontinuierliche Integration im Serverraum im Flur großartig ist, kann sie in der Cloud noch besser sein, wo es große Möglichkeiten für eine schnellere Bereitstellung und höhere Effizienz gibt. Im besten Fall können die Clouds die Arbeit aufteilen und die Aufgaben parallel ausführen. Die Dienste beginnen mit einem großen Hardware-Pool und werden dann von vielen Teams gemeinsam genutzt. Solange nicht jeder gleichzeitig seinen Code pusht, werden die Builds und Tests viel schneller ausgeführt. Der Kauf des gleichen riesigen Hardware-Racks für die Momente, in denen die Entwickler alle Tests ausführen möchten, ist unerschwinglich. Wenn sich die Teams jedoch das Rack teilen, können sie alle die Geschwindigkeitsschübe genießen.

Es gibt jedoch Gefahren und Sorgen, und das größte Problem kann der Kontrollverlust sein. Alle Cloud-Dienste erfordern die Übergabe Ihres Codes an Dritte. Diese Entscheidung mag sich für einige befreiend anfühlen, für andere jedoch erschreckend. Alle Cloud-Dienste bemühen sich, die Sicherheit zu betonen, aber irgendwie fühlt es sich anders an, wenn sich der Code unter Ihrem eigenen Dach befindet.

Neben der breiten Unterstützung aller Hauptsprachen decken diese Dienste eine überraschende Anzahl der Nebensprachen und nicht nur einige wirklich seltsame und ungewöhnliche Sprachen ab. Dies ist mehr das Ergebnis guter architektonischer Entscheidungen am Anfang als jede heldenhafte Anstrengung der Entwickler. Die Aufgabenlisten werden fast immer als Befehle für eine Shell oder eine Befehlszeile codiert, sodass die Tools für die kontinuierliche Integration die Befehle so lange ausgeben, bis die Liste erschöpft ist oder eine unüberwindbare Straßensperre auftritt. Einige der Sprachen wie Java bieten komplexere Optionen, aber zum größten Teil können die Tools alles erreichen, was Sie mit einer Befehlszeile tun können. 

Hier sind 10 verschiedene Optionen für die kontinuierliche Integration in die Cloud.

CloudBees

CloudBees Core begann mit Jenkins, dem bekannten Open-Source-Projekt für die kontinuierliche Integration, und fügte dann Tests, Support und die Gewissheit hinzu, dass der Code nur ausgeführt wird. Das Unternehmen hat alle experimentellen Plugins herausgeholt, einige eigene hinzugefügt und dann die richtigen poliert, damit sie wie erwartet funktionieren, wenn Sie sie benötigen.

CloudBees beschäftigt immer noch 80 Prozent des Jenkins-Entwicklungsteams und trägt häufig Code zum Open Source-Projekt bei, sodass Sie sicher sein können, dass sie ein gutes Verständnis für diese dominante Plattform haben. Um die Arbeit zu beschleunigen, hat CloudBees außerdem eine umfassende Parallelisierung sowie Instrumentierung hinzugefügt, um Ihren Entwicklungsprozess zu verfolgen.

CloudBees bietet eine Vielzahl von Preispunkten, die von kostenlosen Stufen bis zu „Starter-Kits“ für ein ganzes Dienstjahr reichen. Das Unternehmen bietet Jenkins auch Unterstützung für alle, die Hilfe mit dem Tool benötigen, aber das Cloud-Computing nicht benötigen oder wollen.

AWS CodePipeline

Das Amazon-Tool für die kontinuierliche Integration und Bereitstellung, AWS CodePipeline, ist für die Bereitstellung von Code an einen AWS-Server optimiert und bietet dennoch offenere Möglichkeiten für Ihren Code und Ihre Daten. Das Basistool bietet eine schöne Auswahl vorkonfigurierter Build-Umgebungen für die wichtigsten Sprachen (Java, Python, Node.js, Ruby, Go, Android, .Net Core für Linux) und speichert das Ergebnis vor dem Senden in einem S3-Bucket Aus zu einem Server, um zu starten.

Es gibt eine überraschend große Anzahl von Schichten mit leicht unterschiedlichen Namen. CodeBuild greift nach Ihrem neuesten Genie von CodeCommit, wenn es von CodePipeline ausgelöst wird, und übergibt das Ergebnis dann an CodeDeploy. Wenn das zu viele Code-Dinge sind, als dass Sie sie konfigurieren könnten, können Sie direkt zu CodeStar springen, das eine weitere Automatisierungsebene bietet. Wenn es nur einen CodeBugEraserStar gäbe, der all unsere Fehler auch automatisch beseitigt. Es ist erwähnenswert, dass Sie technisch für keine dieser Code-Ebenen bezahlen. Amazon berechnet Ihnen nur die Rechen- und Speicherressourcen, die auf dem Weg verwendet werden. Es ist nicht gerade kostenlos, obwohl es sich so anfühlt.

Bitbucket-Pipelines

Atlassian, die Entwickler des beliebten Job Tracking Boards Jira und des Code-Repositorys Bitbucket, haben beschlossen, unseren Workflow durch die Erstellung von Bitbucket Pipelines, einem kontinuierlichen Integrationstool in der Bitbucket-Cloud, optimal zu nutzen. Die geheime Sauce ist mehr Integration, in diesem Fall in Form von Verbindungen zwischen dem Build-Mechanismus und den anderen Werkzeugen von Atlassian. Zumindest kosmetisch ist Pipelines nicht einmal eine separate Sache. Es ist nur eine weitere Menüoption für jedes Projekt in Bitbucket. Eine weitere Menüoption verweist auf Bereitstellungen, sodass Sie auswählen können, wo die Builds enden.

Die Verbindungen sind ein Segen und eine Einschränkung. Wenn Sie eine der Vorlagen auswählen, die bereits für die Hauptsprachen (Java, JavaScript, Python, PHP, .Net usw.) definiert sind, können Sie Ihren Code mit wenigen Klicks erstellen und bereitstellen. Wenn Sie sich jedoch von den Standards entfernen, werden Sie feststellen, dass die Optionen nicht vorhanden sind. Atlassian fördert einen Marktplatz für Apps, die eine Mischung aus Diagrammen und Webhooks zu anderen Diensten zu sein scheinen. Die Top-App in der Tabelle, während ich dies schreibe, verbindet Bitbucket mit Jenkins, vermutlich um etwas zu tun, das innerhalb der Wände nicht schnell erledigt werden kann.

Der Hauptvorteil von Pipelines ist die Geschwindigkeit. Atlassian hat die meisten wichtigen Pfade vom Code bis zur Ausführung von Bereitstellungen vorentwickelt, und Sie können für nur ein paar Dollar in die Fußstapfen des Unternehmens treten. Es ist schwierig, die Kosten für die Verwendung von Bitbucket zu vergleichen, da die Builds wie bei den meisten Modellen ohne Server in Minuten angeboten werden. Teams widmen jedoch häufig einen Cluster von Instanzen für die Verarbeitung von Jenkins-Builds. Selbst wenn Sie sie nachts und am Wochenende schließen, summieren sich die Stunden.

GitLab CI / CD

Einer der größten Konkurrenten von Atlassian ist GitLab, ein weiteres Unternehmen, das jeden Schritt des Prozesses zwischen Ihren Fingern und der Ausführung abwickeln möchte. Die Build-, Test- und Bereitstellungsmechanismen von GitLab sind ebenfalls direkt mit den Git-Repositorys verbunden, sodass sie beim Festschreiben ausgelöst werden können. Der Prozess basiert größtenteils auf Docker-Containern, und dieses Caching kann einige der Konfigurationsarbeiten, die für Jenkins-Builds durchgeführt werden müssen, erheblich vereinfachen.

Die Build-Aufgaben können auf jede Sprache abzielen, müssen jedoch von GitLab Runner ausgelöst werden, einem in Go geschriebenen Tool zur automatischen Skalierung, das für die meisten Plattformen bereit ist. Diese Flexibilität bedeutet, dass Sie jeden zufälligen Auftrag auf anderen Computern auslösen können. Dies kann bei ausgeklügelten Architekturen hilfreich sein, die mehr als nur Microservices bereitstellen.

Die Preise werden mit den verschiedenen Stufen gebündelt, um den Bedarf zu schätzen. Gold-Tier-Gruppen erhalten beispielsweise die besten Funktionen wie Sicherheits-Dashboards und 50.000 Minuten Aufbauzeit auf dem gemeinsam genutzten Computercluster. Die Verwendung Ihrer eigenen Computer für einen Teil des Prozesses oder für separate Instanzen in einer anderen Cloud ist kostenlos.

CircleCI

Viele der Tools für die kontinuierliche Integration konzentrieren sich auf Code, der in der Linux-Umgebung erstellt werden kann. CircleCI erstellt und liefert in der Linux-Welt, bietet aber auch ein Produkt, mit dem Android-Apps und alles, was aus Apples Xcode stammt (für iOS, MacOS, tvOS oder watchOS), erstellt werden können. Wenn Sie in einem Team arbeiten, das Apps für diese Plattformen erstellt, können Sie Ihren Code festschreiben und CircleCI die Testdisziplin für das unterschiedliche Genie Ihres Teams durchsetzen lassen.

Die Aufgabenlisten sind in YAML-Dateien aufgeführt. CircleCI verwendet Docker in all seiner vielschichtigen Pracht, um die Testumgebungen für den Code zu konfigurieren. Die Builds beginnen mit frischen Containern, ebenso alle Tests. Die Mac-Arbeit läuft auf virtuellen Maschinen mit einer ähnlich kurzen Lebensdauer. Dies vermeidet einige Probleme bei der Konfiguration, da in den sauberen Umgebungen keine Reste herumliegen. (Wenn Ihre Probleme also durch verweilendes digitales Treibgut verursacht werden, ist das Ihre Schuld.)

Die Preisgestaltung konzentriert sich darauf, wie viel CPU Ihre Builds verbrauchen. Die Anzahl der Benutzer und die Anzahl der Repositorys sind auf unendlich begrenzt. Die Anzahl der Bauminuten und Container, die dieses Gebäude ausführen, wird jedoch gemessen. Der erste Container ist kostenlos und Sie können einen Build darin ausführen. Wenn Sie mehr Parallelität oder mehr Durchsatz wünschen, kann CircleCI etwas Geld verdienen. Die Mac-Benutzer erhalten nicht das gleiche kostenlose Angebot, aber es gibt Einführungspläne für alle, die den Dienst testen.

Travis CI

Wenn Ihre Builds Code produzieren, der auf Windows-Boxen getestet werden muss, bietet Travis CI Ihnen einen einzigen Stopp. Das Unternehmen bietet seit einiger Zeit MacOS- und Linux-Optionen an, hat jedoch gerade die Windows-Option eingeführt, um die Erstellung von Code zu vereinfachen, der an noch mehr Stellen ausgeführt wird.

Die Aufgabenlisten sind auch in YAML geschrieben und die Jobs werden in sauberen virtuellen Maschinen mit einer ziemlich standardmäßigen Konfiguration ausgeführt. Linux-Code enthält einige Basisversionen von Ubuntu. Der Mac-Code wird in einer von zwölf Kombinationen aus OS X, Xcode und JDK ausgeführt. Der Windows-Code kann derzeit nur in einer Version von Windows Server (1803) gespeichert werden. Travis CI bietet eine lange Liste von 30 Sprachen und Build-Regeln, die vorkonfiguriert und praktisch einsatzbereit sind.

Die Preisgestaltung basiert darauf, wie viele gleichzeitige Jobs gleichzeitig ausgeführt werden können. Es gibt jedoch keine formalen Beschränkungen für die Anzahl der Minuten, die diese Builds in Anspruch nehmen können. Es ist, als ob Sie eine feste Anzahl dedizierter Instanzen für Ihre Arbeit erhalten und diese jederzeit bereit sind. Es gibt keine kostenlosen Optionen für proprietäre Arbeiten, aber Open Source-Projekte sind „immer kostenlos“. Dies ist möglicherweise die einfachste Möglichkeit, Travis CI auszuprobieren.

Azure-Pipelines

Wenn Sie sich fragen, ob das moderne Microsoft die Einstellung "Hier nicht erfunden" hat, sind Sie bei Azure Pipelines genau richtig. In der Verkaufsliteratur heißt es: "Jede Sprache, jede Plattform." Während dies mit ziemlicher Sicherheit eine Übertreibung ist und Azure den ENIAC-Programmierern wahrscheinlich nicht viel zu bieten hat, bietet es prominent Microsoft-, Linux- und MacOS-Pfade für Ihren Code. Die Apple-Ecke zielt nur auf MacOS-Builds ab, nicht auf iOS, tvOS oder watchOS, aber wir sollten nicht wählerisch werden. Dies ist ein Glas, das viel mehr als halb voll ist.

In der Zusammenfassung ähnelt das System den anderen. Es gibt Agenten, die Builds ausführen, um Artefakte zu erzeugen. Einige davon können selbst gehostet werden, wenn diese Option hilfreich ist. Der Stack umfasst Docker-Container vollständig und die Azure-Hardware kann sie für Sie ausführen. Alle diese Details können zusammen mit einem in eine Webseite integrierten visuellen Designer angeklickt oder mit YAML angegeben werden, wenn Sie lieber in der Befehlszeilenwelt leben möchten.

Die Preisgestaltung beinhaltet einen kostenlosen „Paralleljob“ mit 1800 Minuten Bauzeit. Wenn Sie mehr Parallelität oder mehr Zeit benötigen, beginnen Sie zu zahlen. Der Plan sieht eine großzügige kostenlose Stufe für Open Source-Projekte vor, was wiederum den Wunsch von Microsoft unterstreicht, an der allgemeinen Open Source-Community teilzunehmen. Aber wenn Microsoft durch den Erwerb von GitHub 7,5 Milliarden US-Dollar ausgeben wird, um einen Platz am Tisch zu kaufen, ist dies durchaus sinnvoll. Wo läuft all dieser Code? Azure Pipelines wird es gerne reibungslos auf Azure-Hardware übertragen.