Direkt zum Inhalt | Direkt zur Navigation

solving complex IT problems!

Benutzerspezifische Werkzeuge

Sie sind hier: Startseite / Blog / Continuous Integration / Continuous Delivery (CI/CD)

Continuous Integration / Continuous Delivery (CI/CD)

Continuous Delivery kann großen Unternehmen helfen, schlank, agil und innovativ zu werden. Durch zuverlässige Releases mit geringem Risiko ermöglicht Continuous Delivery die kontinuierliche Anpassung der Software an das Feedback der Benutzer, Marktverschiebungen und Änderungen der Geschäftsstrategie. Test, Support, Entwicklung und Betrieb arbeiten als ein Team zusammen, um den Prozess zu automatisieren und zu optimieren: Build → Test → Release → Deploy.

Migration von Jenkins zu GitLab CI/CD

Unsere Erfahrung ist, dass Migrationen häufig sehr lange hinausgeschoben werden da sie keinen unmittelbaren Vorteil versprechen. Wenn die verwendeten Werkzeuge jedoch in die Jahre kommen und nicht mehr wirklich zu den neuen Anforderungen passen, häufen sich technische Schulden an, die ebenfalls die Weiterentwicklung gefährden.

Vorteile

Die Vorteile von GitLab CI/CD gegenüber Jenkins sind:

Nahtlose Integration
Das in GitLab integrierte CI/CD bietet einen vollständigen DevOps-Workflow, der sich nahtlos in das GitLab-Ökosystem einfügt.
Bessere Sichtbarkeit
Die bessere Integration führt auch zu mehr Transparenz über Pipelines und Projekte hinweg, sodass Teams fokusiert bleiben können.
Niedrigere Betriebskosten
Jenkins erfordert erhebliche Aufwände in Wartung und Konfiguration. GitLab hingegen bietet Code-Review und CI/CD in einer einzelnen Anwendungen.

Erste Schritte

Migrationen von Jenkins zu GitLab müssen jedoch nicht beängstigend sein. Viele Projekte wurden bereits von Jenkins zu GitLab CI/CD gewechselt, und es stehen etliche Hilfsmittel bereit um den Übergang zu erleichtern, z.B.:

  • Jenkins-Dateien in GitLab CI/CD ausführen

    Eine kurzfristige Lösung, die Teams bei der Migration von Jenkins auf GitLab CI/CD verwenden können, ist die Verwendung von Docker, um eine Jenkins-Datei in GitLab CI/CD auszuführen, während nach und nach die Syntax aktualisiert wird. Dies behebt zwar nicht die externen Abhängigkeiten, bietet jedoch bereits eine bessere Integration in das GitLab-Projekt.

  • Auto DevOps verwenden

    Möglicherweise kann Auto DevOps zum Erstellen, Testen und Bereitstellen Eurer Anwendungen verwendet werden, ohne dass eine spezielle Konfiguration erforderlich ist. Eine der aufwändigeren Aufgaben der Jenkins-Migration kann das Konvertieren der Pipelines von Groovy zu YAML sein; Auto DevOps bietet jedoch vordefinierte CI/CD-Konfigurationen, die in vielen Fällen eine passende Standard-Pipeline erstellen. Auto DevOps bietet weitere Funktionen wie Sicherheits-, Leistungs- und Codequalitätstests. Schließlich könnt Ihr einfach die Vorlagen ändern wenn Ihr weitere Anpassungen benötigt.

Best Practices

  • Fangt klein an!

    Die oben angegebenen Erste Schritte erlauben Euch, inkrementelle Änderungen vorzunehmen. So könnt Ihr kontinuierlich Fortschritte in Eurem Migrationsprojekt erzielen.

  • Nutzt die Werkzeuge effektiv!

    Mit Docker und Auto DevOps stehen Euch Werkzeuge zur Verfügung, die den Übergang vereinfachen.

  • Kommuniziert transparent und verständlich!

    Haltet das Team über den Migrationsprozess auf dem Laufenden und teilt den Projektfortschritt mit. Strebt auch klare Jobnamen an und gestaltet Eure Konfiguration so, dass sie einen möglichst guten Überblick gibt. Schreibt ggf. Kommentare für Variablen und schwer verständlichen Code.

Lasst Euch beraten

Ich berate Euch gerne und erstelle ein passgenaues Angebot für die Migration Eurer Jenkins-Pipeline zu GitLab CI/CD.

Veit Schiele

Veit Schiele
Telefon: +49 30 22430082

Ich rufe Euch auch gerne an!

Jetzt anfragen

Cusy DevOps­-Toolchain as a Service in der iX extra 04/2020

Cusy DevOps­-Toolchain as a Service in der iX extra 04/2020

iX extra 04/2020

Cusy wird im Extra Hosting für Entwickler der Zeitschrift iX 04/2020 besprochen. Insebsondere werden in diesem Heft zwei Entwicklertrends hervorgehoben: Microservices und DevOps. Dies sind auch Schwerpunkte unserer Arbeit, über die wir immer wieder berichten, z.B. in unserem Blog:

Beim Beispiel einer DevOps-Toolchain bezieht sich der iX-Artikel dann auch direkt auf uns:

Entwickleraufgabe Softwaretool
Projektmanagement Jira-Software
Dokumentenmanagement Confluence
Versionsverwaltung Gitblit
Code-Review Gerrit
Testen/Deployment Jenkins
Log-Management und -Analyse Sentry
Helpdesk Jira Service Desk
Webanalyse Matomo

Auch am Ende des Artikels wird Cusy noch einmal mit einem Alleinstellungsmerkmal erwähnt – die DevOps-Tools lassen sich leicht integrieren und verfügen über eine einheitliche Benutzerverwaltung:

Ganz auf Entwicklerwerk­zeuge hat sich Cusy spezialisiert. Alle Tools lassen sich einzeln als virtuelle Maschinen buchen, kön­nen aber über ein integriertes LDAP-­Directory zusammenarbei­ten.

Cusy 2016 Jahresrückblick

DevOps als API

Anfang des Jahres sind wir unserer Vision ein gutes Stück näher gekommen. Wir nutzen eine API, mit der automatisiert VMs erstellt, konfiguriert und gelöscht werden können. Damit erhalten unsere Kunden die Möglichkeit, ihre Infrastruktur zu programmieren. Einzelne Systeme oder ganze Cluster können mit der API auf programmatischem Wege und jederzeit reproduzierbar bereitgestellt werden. Mehr über unsere Devops-Vision erfahren Sie in Die Vision von Cusy – DevOps als API.

Die Schnittstelle zwischen Dev und Ops kippt

IT-Compliance

Da vermutlich auch Privacy Shield kein sicherer Hafen werden wird, gehen wir davon aus, dass immer mehr Unternehmen sich nach einem verlässlichen IT-Partner in Deutschland umsehen werden. Unsere Kunden sind auf zukünftige Herausforderungen, die vor allem aus der neuen Datenschutzgrundverordnung erwachsen, gut vorbereitet. Wir können Unternehmen, die ihre IT-Compliance verbessern wollen, tatkräftig unterstützen.

Fördermitgliedschaften

Digitale Gesellschaft

Mitte des Jahres sind wir Fördermitglied der Digitalen Gesellschaft geworden.

Die Digitale Gesellschaft ist ein gemeinnütziger Verein, der sich für Grundrechte und Verbraucherschutz im digitalen Raum einsetzt. Der Verein möchte die offene digitale Gesellschaft erhalten und fördern. Er kämpft gegen den Rückbau von Freiheitsrechten im Netz und engagiert sich für einen freien Wissenszugang, für mehr Transparenz und Partizipation sowie für eine kreative Entfaltung digitaler Potenziale.

Bessere Datenschutzmaßnahmen

Härtung

Nachdem Cusy von Anfang an sehr viel Wert auf technische und organisatorische Datenschutzmaßnahmen für den Betrieb im Rechenzentrum legt, haben wir Mitte des Jahres nun auch mit unseren Maßnahmen für die Absicherung der Admin-Workstations die Sicherheit deutlich erhöht. Unsere Richtlinien und Checklisten hierfür veröffentlichten wir auf unserer Website.

Transparenzbericht

Kurz vor dem erstem Geburtstag der Cusy GmbH am 29. September, veröffentlichten wir unseren ersten Transparenzbericht.

Continuous Everything

Auf der Cusy-Plattform können unsere Kunden nun auch mit Jenkins ihre Anwendung automatisiert installieren und aktualisieren. Damit sind wir einer Continuous Everything-Plattform sehr viel näher gekommen. Selbstverständlich beraten wir unsere Kunden gerne, wie sie dies technisch auf der Cusy-Plattform realisieren können.

Alternative zur Google Search Appliance

Da die Google Search Appliance ihr End of Life erreicht hat, haben wir uns nach Alternativen umgeschaut. Momentan testen wir einen Software-Stack u.a. mit Elasticsearch, Security für Authentifizierung, Autorisierung und Verschlüsselung sowie Watcher für Benachrichtigungen.

Im ersten Quartal 2017 werden wir unseren Kunden eine zuverlässige und leistungsstarke Alternative nach dem deutschen Datenschutz bereitstellen können.

Die Vision von Cusy: DevOps als API

DevOps: Die Hälfte des Weges ist geschafft

Nach Studien, über die Heise Developer kürzlich berichtete, arbeitet bereits die Hälfte der deutschen Entwickler nach dem DevOps-Prinzip. Als Befürworter von DevOps könnte man sich also zufrieden zurücklehnen und feststellen: die Hälfte des Weges ist bereits geschafft.

Doch dies ist nur die halbe Wahrheit. Wenn man sich anschaut, wie DevOps in vielen Unternehmen umgesetzt wird, so sieht man, dass ein Großteil der Pro-DevOps-Unternehmen bei der Umsetzung erst die Hälfte des Weges zurückgelegt hat. Zwar übernehmen Entwickler in DevOps-Teams mittlerweile Verantwortung für den Code auch im Betrieb, aber umgekehrt übernehmen noch nicht alle Sysadmins Verantwortung für die Infrastruktur auch in der Entwicklung. Häufig betreiben Entwickler-Teams immer noch eine eigene Infrastruktur für die Entwicklung, sodass die positiven Effekte des DevOps-Prinzips teilweise verfliegen.

Dass es sich bei DevOps um eine Veränderung der Kultur handelt und nicht bloß um die Nutzung einiger innovativer Werkzeuge, hat sich immer noch nicht überall herumgesprochen. Selbst viele Studien, in denen lediglich die Nutzung von bestimmten Werkzeugen wie Docker oder Puppet abgefragt wird, zeichnen ein falsches Bild von DevOps.

DevOps ist keine Werkzeugkiste, sondern eine Neuverteilung von Verantwortung im Unternehmen. In klassischen IT-Abteilungen ist die Verantwortung für die Bereiche Entwicklung/Testing und Produktion folgendermaßen verteilt.

Nicht selten befinden sich Development und Operations sogar in unterschiedlichen Abteilungen eines Unternehmens. In der DevOps-Kultur kippt die vertikale Trennung zwischen Entwicklung und Betrieb und es entsteht eine horizontale Schnittstelle.

Die Schnittstelle zwischen Dev und Ops kippt

Die Anwendungsentwickler übernehmen die Verantwortung für ihre Anwendung, unabhängig davon, ob diese sich in der Entwicklung oder in der Produktion befindet. Umgekehrt übernehmen die Systemverwalter aber auch die Verantwortung für die gesamte Infrastruktur von der Entwicklungsumgebung bis hin zur Produktivumgebung.

Der mit DevOps eintretende Paradigmenwechsel ist also im Wesentlichen einer, der die Verteilung von Verantwortung verändert und nicht einer, der nur neue Werkzeuge wie Puppet und Chef bereitstellt.

Cusy ist das Ops in DevOps

DevOps is the philosophy of unifying Development and Operations at the culture, practice, and tool levels, to achieve accelerated and more frequent deployment of changes to Production.

– Rob England www.itskeptic.org

Cusy erleichtert den Wechsel von der klassischen IT-Organisation zu agilen DevOps-Strukturen. Cusy übernimmt als Dienstleister die Verantwortung für die gesamte Infrastruktur: von Entwicklung über die Testumgebung bis hin zum Produktivsystem. Cusy ist das Ops in DevOps und entlastet Unternehmen von der Aufgabe, ihre Infrastruktur selbst zu pflegen. Cusy stellt Unternehmen dabei nicht nur die technische Infrastruktur zur Verfügung, sondern die komplette Entwicklungs- und Betriebsumgebung einschließlich aller benötigten Werkzeuge.

Anwendungsentwickler können sich dank Cusy bereits heute voll und ganz auf ihre Entwicklung konzentrieren. Sie müssen sich nicht um die Wartung und Pflege der notwendigen Entwicklungswerkzeuge wie Projektmanagement, Dokumentenmanagement, Versionsverwaltung kümmern.

Darüberhinaus stellt die Cusy-Plattform auch Werkzeuge für das Testen und die Produktion bereit wie Continuous Integration und eine Log-Management & Analyse bereit.

Und schließlich bietet Cusy auch Werkzeuge für Marketing und Support wie Webanalyse und Helpdesk.

In naher Zukunft wird Cusy neben allen erforderlichen Werkzeugen auch VMs für den Betrieb von Anwendungen bereitstellen, mit denen dann ein einfaches Continuous Delivery mit Jenkins ist. Hierfür wird Cusy die bereits vorhandene API zum Erstellen, Ändern und Löschen von VMs auch seinen Kunden direkt bereitstellen. Damit wäre die Vision von Cusy Wirklichkeit geworden: DevOps als API.