Continuous Integration

Sieben Mal daneben: Warum Continuous Delivery manchmal scheitert

Kontinuierliches Liefern (Continuous Delivery) und Infrastructure as Code sind Mainstream, oder? Zumindest behaupten viele, es zu praktizieren. Wer es nicht macht, ist draußen (neudeutsch: out) – oder zumindest ganz weit drin im Zimmer. Konsequent zu Ende betrachtet müssten wir also eine enorme Verbesserung der Liefergeschwindigkeit in unserer IT-Welt sehen – und zwar nicht nur bei kleinen Unternehmen und Projekten.

Roadmap einer spannenden Reise: Voraussetzungen für Continuous Deployment in Unternehmen

In Unternehmen existiert häufig eine umfangreiche Anwendungslandschaft. Dennoch besteht meist der Wunsch oder Bedarf, regelmäßig neue Versionen der Produkte produktiv zu setzen, um entweder neue Features auszuliefern oder Sicherheitslücken zu schließen. Welche Voraussetzungen für Continuous Deployment erfüllt sein müssen, wird anhand einer Roadmap in diesem Artikel vorgestellt. Dabei werden die Herausforderungen von Verfügbarkeits-, Sicherheits- und Qualitätsanforderungen angesprochen. Spezielles Augenmerk richten wir auf den Aspekt verteilter Verantwortlichkeiten, unabhängig von einer erfolgreichen Etablierung einer DevOps-Kultur.

DevOps: Vollständige Automatisierung ist nicht zwingend die Lösung

Mit dem Siegeszug von DevOps in der Softwareentwicklung gehen einige grundlegende Veränderungen einher. IT und Development rücken näher zusammen, um schneller hochwertige Software liefern zu können. Viele Prozesse – auch im Testing – sollten dafür automatisiert werden. Warum das jedoch nur bedingt machbar beziehungsweise sinnvoll ist, erklärt Jan Wolter, General Manager EU bei Applause.

An- und Ausschalter: Continuous Delivery mit Feature-Toggles

Seit einigen Jahren kommen lineare Vorgehensweisen wie die des Wasserfallmodells kaum noch zur Anwendung. Sie wurden durch agile Methoden wie Scrum oder Kanban ersetzt. Dadurch ist unser Arbeitsalltag in einem Softwareentwicklungsteam angenehmer und effizienter geworden. Im Zuge dessen haben auch Praktiken wie Continuous Integration (CI) und Continuous Delivery (CD) Einzug in unseren Arbeitsalltag gehalten. Durch CI-Server wie Jenkins, GitHubCI oder TravisCI werden lästige und ineffiziente Tätigkeiten wie das immer wiederkehrende Integrieren weitestgehend automatisiert.

An- und Ausschalter: Continuous Delivery mit Feature-Toggles

Seit einigen Jahren kommen lineare Vorgehensweisen wie die des Wasserfallmodells kaum noch zur Anwendung. Sie wurden durch agile Methoden wie Scrum oder Kanban ersetzt. Dadurch ist unser Arbeitsalltag in einem Softwareentwicklungsteam angenehmer und effizienter geworden. Im Zuge dessen haben auch Praktiken wie Continuous Integration (CI) und Continuous Delivery (CD) Einzug in unseren Arbeitsalltag gehalten. Durch CI-Server wie Jenkins, GitHubCI oder TravisCI werden lästige und ineffiziente Tätigkeiten wie das immer wiederkehrende Integrieren weitestgehend automatisiert.

Domino statt Puzzle: CI/CD richtig umsetzen

Schneller, besser, zuverlässiger ist heute eine Kernanforderung an die Softwareentwicklung. Continuous Integration und Continuous Delivery versprechen, alle Aspekte gleichermaßen zu adressieren und dass man dabei keinerlei Einbußen hinnehmen muss. Der Weg dahin ist allerdings steinig und hat weitreichende Folgen für das gesamte Unternehmen. Julian Fish von Micro Focus erklärt die weitreichenden Stolperfallen und Fragestellungen, denen sich Unternehmen bei der Implementierung stellen müssen.

Themenkomplex Security: „Sicherheit ist eine dauerhaufte Aufgabe, die immer Teil des Entwicklungsprozesses sein sollte“

Die moderne IT-Welt ist ein gefährliches Pflaster. Von der Entwicklung über das Deployment bis hin zur Nutzung fertiger Anwendungen gibt es quasi an jeder Ecke potentielle Schwachstellen. Kein Wunder also, dass „Security“ ein zentraler Bereich der Softwareentwicklung ist. Im Interview spricht Lech Sandecki, Verantwortlicher für die Sicherheits- und Public-Cloud-Produkte bei Canonical, über die aktuelle Sicherheitslage in der IT.

Sieben Mal daneben: Warum Continuous Delivery manchmal scheitert

Kontinuierliches Liefern (Continuous Delivery) und Infrastructure as Code sind Mainstream, oder? Zumindest behaupten viele, es zu praktizieren. Wer es nicht macht, ist draußen (neudeutsch: out) – oder zumindest ganz weit drin im Zimmer. Konsequent zu Ende betrachtet müssten wir also eine enorme Verbesserung der Liefergeschwindigkeit in unserer IT-Welt sehen – und zwar nicht nur bei kleinen Unternehmen und Projekten.

Voraussetzungen für Continuous Deployment in Unternehmen

In Unternehmen existiert häufig eine umfangreiche Anwendungslandschaft. Dennoch besteht meist der Wunsch oder Bedarf, regelmäßig neue Versionen der Produkte produktiv zu setzen, um entweder neue Features auszuliefern oder Sicherheitslücken zu schließen. Welche Voraussetzungen für Continuous Deployment erfüllt sein müssen, wird anhand einer Roadmap in diesem Artikel vorgestellt. Dabei werden die Herausforderungen von Verfügbarkeits-, Sicherheits- und Qualitätsanforderungen angesprochen. Spezielles Augenmerk richten wir auf den Aspekt verteilter Verantwortlichkeiten, unabhängig von einer erfolgreichen Etablierung einer DevOps-Kultur.

Unter der Lupe: Kubernetes und seine CI/CD-Generationen und Systeme

Der neue Kubernetes-Cluster ist eingerichtet, die Softwarearchitektur ist ganz modern auf Basis von Microservices geplant, jetzt fehlt nur noch eine Continuous Integration oder Continuous Delivery (CI/CD) Pipeline. Diese ist schnell mit dem Jenkins gebaut, der schließlich schon seit Jahren einen guten Dienst verrichtet. Alles nur noch eine Kleinigkeit, oder? Aber ist das eigentlich eine gute Idee?

„Man wird heute nicht gefeuert, weil man CI/CD praktiziert, sondern weil man es nicht praktiziert“

Die Continuous Delivery Foundation (CDF) wurde im März diesen Jahres ins Leben gerufen, um ein Ökosystem für Continuous-Delivery-Lösungen und -Praktiken zu etablieren. Sacha Labourey, CEO und Co-Founder von CloudBees, gibt im Interview Auskunft über die letzten Entwicklungen und klärt, was es mit der Evolution von CI/CD zu Software Delivery Management (SDM) auf sich hat.

Kubernetes und seine CI/CD-Generationen

Der neue Kubernetes Cluster ist eingerichtet, die Softwarearchitektur ist ganz modern auf Basis von Microservices geplant, jetzt fehlt nur noch eine Continuous Integration oder Continuous Delivery (CI/CD) Pipeline. Diese ist schnell mit dem Jenkins gebaut, der schließlich schon seit Jahren einen guten Dienst verrichtet. Alles nur noch eine Kleinigkeit, oder? Aber ist das eigentlich eine gute Idee?