Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

Agiliät und Continuous Delivery
Agiliät und Continuous Delivery
Agiliät und Continuous Delivery
Ebook57 pages33 minutes

Agiliät und Continuous Delivery

Rating: 0 out of 5 stars

()

Read preview

About this ebook

Build Management zusammen mit den etablierten Konzepten rund um Continuous Integration wurde unlängst um neue Ideen ergänzt, die unter dem
Namen Continuous Delivery zusammengefasst werden. Continuous Delivery beginnt dort, wo Continuous Integration endet. Das erste Kapitel erläutert zunächst die Parallelen in
der Entstehung von CI und CD und beschreibt, inwieweit CD als mögliche Weiterführung von CI gesehen werden kann. Im zweiten Kapitel folgt die Betrachtung
von Techniken, die es ermöglichen, eine Softwarearchitektur so aufzubauen, dass sie das Versprechen von CD Realität werden lässt. Das dritte Kapitel
beschäftigt sich letztlich mit CD in der Praxis und beleuchtet die Vor- und Nachteile der auf Continuous Delivery beruhenden architektonischen Entscheidungen.
LanguageDeutsch
Release dateNov 11, 2013
ISBN9783868024906
Agiliät und Continuous Delivery

Related to Agiliät und Continuous Delivery

Titles in the series (100)

View More

Related ebooks

Software Development & Engineering For You

View More

Related articles

Reviews for Agiliät und Continuous Delivery

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    Agiliät und Continuous Delivery - Steffen Schluff

    Steffen Schluff, Axel Fontaine,

    René Lengwinat, Michael Fait, Marc Hofer

    Agilität und Continuous Delivery

    ISBN: 978-3-86802-490-6

    © 2013 entwickler.press

    Ein Imprint der Software & Support Media GmbH

    1 Continuous Delivery

    Entstehung, aktueller Stand und Ausblick

    Das Thema Build Management zusammen mit den etablierten Konzepten rund um Continuous Integration wurde unlängst um neue Ideen ergänzt, die unter dem Namen Continuous Delivery zusammengefasst werden.

    Continuous Delivery (CD) wird dabei häufig als Weiterentwicklung von Continuous Integration (CI) bezeichnet, wobei insbesondere die Idee einer Deployment Pipeline dabei helfen soll, den entscheidenden Schritt von CI zu CD zu machen.

    Das folgende Kapitel erläutert die Parallelen in der Entstehung von CI und CD, beschreibt, inwieweit CD als mögliche Weiterführung von CI gesehen werden kann und zeigt abschließend, welche Tools zurzeit verfügbar sind, um diese neuen Ideen umsetzbar zu machen.

    Ausgangspunkt Continuous Integration

    Eines der ältesten Probleme in der Softwareentwicklung ist die Tatsache, dass bei der Zusammenarbeit mehrerer Entwickler unvermeidbar so genannte Integrationsfehler entstehen. Je später diese Fehler entdeckt werden, umso aufwendiger und damit teurer ist deren Beseitigung. Obwohl über dieses Thema schon zuvor ausführlich publiziert worden war [1], ist es hauptsächlich Martin Fowlers Onlineartikel „Continuous Integration" [2] aus dem Jahre 2000, der den bis dato gültigen De-facto-Standard in diesem Bereich darstellt.

    Es waren vor allem die folgenden drei Faktoren, die rückblickend für den nachhaltigen Erfolg von Fowlers Ansatz verantwortlich sind:

    Continuous Integration ist ein sehr eingängiger Begriff, der nicht nur den technischen Sachverhalt gut zusammenfasst sondern auch als „Buzzword" taugt. Letzteres ist vor allem dann bedeutsam, wenn um Mittel und Ressourcen geworben wird.

    Fowler benennt detailliert konkrete „Key Practices", die als Orientierungshilfe beim Einsatz von CI dienen, wie zum Beispiel „Automate the Build oder „Make Your Build Self-Testing. Somit existiert eine Referenz anhand derer man zeigen kann, dass man tatsächlich CI verwendet und sich nicht nur mit einem Modewort schmückt.

    Begleitend zu dem Artikel waren einsetzbare Tools erhältlich, sodass die dargestellten Konzepte auch sofort in der Praxis angewendet werden konnten. Genauer gesagt hatte die Firma ThoughtWorks zu dem damaligen Zeitpunkt den Quellcode von CruiseControl [3], einem frei verfügbaren Open-Source-CI-Server, bereitgestellt.

    Abbildung 1.1 zeigt den schematischen Aufbau eines typischen CI-Systems, bestehend aus dem Server selbst sowie weiteren Bestandteilen.

    Abbildung 1.1: Schematischer Aufbau eines CI-Systems

    Der abgebildete Kreislauf startet, wenn das Entwicklerteam Änderungen an einem Projekt durchführt und diese an das Version Control System (VCS) übergibt. Der CI-Server, der in bestimmten Zeitabständen das VCS prüft, stößt im Falle einer Änderung einen so genannten CI Build an. Hierbei wird mittels eines Build-Tools wie Maven oder Ant der aktuelle Projektstand kompiliert und üblicherweise auch automatisiert getestet. Abschließend wird der Build durch den CI-Server als erfolgreich oder fehlgeschlagen klassifiziert und das Entwicklerteam entsprechend

    Enjoying the preview?
    Page 1 of 1