© Liashko/Shutterstock.com
Entwickler Magazin
Von Continuous Integration zu Continuous Delivery mittels DevOps

Kettenreaktion

Continuous Integration unterstützt insbesondere die Prozesse in der agilen Softwareentwicklung und ist zu einem wichtigen De-facto-Standard in den letzten Jahren geworden. Die konsequente Weiterentwicklung von Continuous Integration zu Continuous Delivery ist der nächste wichtige Verbesserungsschritt.

René Schröder


Continuous Integration findet zu großen Teilen in den Developerteams selbst statt, denn hier wird zeitnah das Feedback der Continuous-Integration-Systeme benötigt. Continuous Delivery erfordert nicht nur eine Weiterentwicklung des Continuous-Integration-Prozesses, es erfordert darüber hinaus eine Weiterentwicklung in der Zusammenarbeit von Developern und Operations. Diese Zusammenarbeit von Developern und Operations im Continuous-Delivery-Prozess ermöglicht es, Software noch zuverlässiger und schneller zu entwickeln und zur Verfügung zu stellen. Traditionell arbeiten diese beiden Bereiche nicht immer gut zusammen, oft ist die Kommunikation unzureichend, ebenso sind die Interessen gegenläufig, verschärft durch die häufigen Produktzyklen der agilen Softwareentwicklung. Der DevOps-Ansatz ist ein Versuch, diese Konkurrenzsituation aufzulösen.

DevOps

DevOps ist eine Zusammensetzung aus der Bezeichnung Softwareentwickler (Developer) und dem IT-Betrieb (Operations). Die Kombination von beiden zu den gemeinsamen DevOps steht hier symbolisch für den Zusammenschluss beider Bereiche. Traditionell werden diese beiden Bereiche sehr getrennt wahrgenommen. Außerdem fühlen sich die beiden Bereiche eher selten zusammengehörig. Aufgrund dieser Trennung und der daraus mangelnden Kommunikation entstehen sehr oft Missverständnisse, da Anforderungen einfach interpretiert werden. Diese Interpretationen bergen die Gefahr, schlicht falsch zu sein.

Anreize Softwareentwickler

Ein Entwicklungsteam, das nach dem Scrum-Prozess arbeitet, hat mehr als im Wasserfallmodell die Möglichkeit, sich durch entsprechend hochwertige Software und Features gegenüber den Stakeholdern zu profilieren. Durch die kurzen Sprints und Releases sind neue Funktionen schnell verfügbar und stellen einen Mehrwert für den Nutzer und die Stakeholder dar. Durch die im Scrum-Prozess definierten Sprint Reviews, an denen auch oft Stakeholder teilnehmen, wird dieser Mehrwert sofort sichtbar, anerkannt und abgenommen. Dieser Effekt der Anerkennung addiert sich von Sprint zu Sprint, von Featurepräsentation zu Featurepräsentation. Oft war es den Entwicklern nicht wichtig, ob und wann die neuen Features ins Produktivsystem kamen, da das nicht ihre Aufgabe im üblichen – nicht DevOps- – Ansatz war.

Anreize Betrieb

Die Aufgabe vom Betrieb kann grob wie folgt definiert werden: Die Softwarereleases, die von der Entwicklung kommen, müssen auf den entsprechenden Produktivumgebungen den Endnutzern zur Verfügung gestellt werden. Hierz...

Entwickler Magazin
Von Continuous Integration zu Continuous Delivery mittels DevOps

Kettenreaktion

Continuous Integration unterstützt insbesondere die Prozesse in der agilen Softwareentwicklung und ist zu einem wichtigen De-facto-Standard in den letzten Jahren geworden. Die konsequente Weiterentwicklung von Continuous Integration zu Continuous Delivery ist der nächste wichtige Verbesserungsschritt.

René Schröder


Continuous Integration findet zu großen Teilen in den Developerteams selbst statt, denn hier wird zeitnah das Feedback der Continuous-Integration-Systeme benötigt. Continuous Delivery erfordert nicht nur eine Weiterentwicklung des Continuous-Integration-Prozesses, es erfordert darüber hinaus eine Weiterentwicklung in der Zusammenarbeit von Developern und Operations. Diese Zusammenarbeit von Developern und Operations im Continuous-Delivery-Prozess ermöglicht es, Software noch zuverlässiger und schneller zu entwickeln und zur Verfügung zu stellen. Traditionell arbeiten diese beiden Bereiche nicht immer gut zusammen, oft ist die Kommunikation unzureichend, ebenso sind die Interessen gegenläufig, verschärft durch die häufigen Produktzyklen der agilen Softwareentwicklung. Der DevOps-Ansatz ist ein Versuch, diese Konkurrenzsituation aufzulösen.

DevOps

DevOps ist eine Zusammensetzung aus der Bezeichnung Softwareentwickler (Developer) und dem IT-Betrieb (Operations). Die Kombination von beiden zu den gemeinsamen DevOps steht hier symbolisch für den Zusammenschluss beider Bereiche. Traditionell werden diese beiden Bereiche sehr getrennt wahrgenommen. Außerdem fühlen sich die beiden Bereiche eher selten zusammengehörig. Aufgrund dieser Trennung und der daraus mangelnden Kommunikation entstehen sehr oft Missverständnisse, da Anforderungen einfach interpretiert werden. Diese Interpretationen bergen die Gefahr, schlicht falsch zu sein.

Anreize Softwareentwickler

Ein Entwicklungsteam, das nach dem Scrum-Prozess arbeitet, hat mehr als im Wasserfallmodell die Möglichkeit, sich durch entsprechend hochwertige Software und Features gegenüber den Stakeholdern zu profilieren. Durch die kurzen Sprints und Releases sind neue Funktionen schnell verfügbar und stellen einen Mehrwert für den Nutzer und die Stakeholder dar. Durch die im Scrum-Prozess definierten Sprint Reviews, an denen auch oft Stakeholder teilnehmen, wird dieser Mehrwert sofort sichtbar, anerkannt und abgenommen. Dieser Effekt der Anerkennung addiert sich von Sprint zu Sprint, von Featurepräsentation zu Featurepräsentation. Oft war es den Entwicklern nicht wichtig, ob und wann die neuen Features ins Produktivsystem kamen, da das nicht ihre Aufgabe im üblichen – nicht DevOps- – Ansatz war.

Anreize Betrieb

Die Aufgabe vom Betrieb kann grob wie folgt definiert werden: Die Softwarereleases, die von der Entwicklung kommen, müssen auf den entsprechenden Produktivumgebungen den Endnutzern zur Verfügung gestellt werden. Hierz...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang