Continuous Delivery – Nur etwas für Web 2.0 Firmen?

2 Kommentare

Auf den ersten Blick möchte man meinen, dass Continuous Delivery etwas für Web 2.0 Firmen ist. Dort liegt es ja auf der Hand, dass man schnell und häufig Software liefern möchte, da es oft ein Wettrennen um das neueste und hippste Feature gibt und Kunden sich sehr schnell neu orientieren können. Auch klar ist, das Web 2.0 Firmen es sich nicht leisten können, Ihre Plattformen länger vom Netz zu nehmen, da Ihr Geschäftsmodell von der Präsenz per se abhängt und daher Zero Downtime Deployment als eine Ausprägung von Continuous Delivery sehr wichtig ist. Soweit so gut.

These: Continuous Delivery ist für fast alle Unternehmenstypen eine wettbewerbsrelevante Fähigkeit.

Betrachten wir zum Zwecke der Herleitung zunächst einge Trends in Volkswirtschaften des 21. Jahrhunderts:

  • Kürzere Produktzyklen – In vielen Branchen verkürzen sich die Produktzyklen drastisch. Paradebeispiel sind dabei für jedermann wahrnehmbar mobile elektronische Geräte.
  • Optimierte Geschäftsprozesse – Verdrängung findet unter anderen in reiferen Märkten auch durch bessere Geschäftsprozesse statt. Ein Gutes Beispiel ist Amazon bezogen auf den Versandhandel.
  • Abhängigkeit von IT -Durch die immer tiefere Durchdringung des Geschäfts mit IT, um effektiver und automatisierter zu sein, ist die Abhängigkeit von funktionierender und robuster IT deutlich gestiegen.
  • Globaler Wettbewerb – Die Globalisierung wird für die vorgenannten Trends zum „Brandbeschleuniger“, da jedes Unternehmen mit den Besten global konkurrieren muss.

Und nun ein Blick auf Continuous Delivery:

Auf den ersten Blick bedeutet Continuous Delivery die Automatisierung des Lieferprozesses der Software in alle relvanten Umgebungen inkl. Produktionsumgebung. Auf den zweiten Blick erfordert diese Automatisierung (damit ich mich das auch traue) einen sehr hohen Reifegrad einer Vielzahl von Disziplinen, wie Architektur (gute Modularisierung), Testautomatisierung (Unit-, Itegrations-, Akzeptanz- und Performancetests), Software Craftmanship (Clean Code, etc.), Requirement Engineering (Abnahmekriterien als Teil des Requirements, Schnitt der Requirements), Entwicklungsprozesse, etc. Continuous Delivery ist also ein fundamentaler Qualitätstreiber für den gesamten Entwicklungsprozess.

Selbst wenn es nicht das Ziel ist schnell und häufig zu liefern, erreicht man so doch deutliche Verbesserung, was Produktivität, Qualität und Passgenauigkeit der Software angeht.

Und nun der „Merge“:

Um IT als Untersützung bzgl. der oben genannten globalen Trends erfolgreich zu betreiben, benötigen wir Qualität, Produktivität und oft auch eine höhere Geschwindigkeit. Alles Faktoren, die sich durch die Umsetzung von Continuous Delivery auch in klassischen Unternehmen verbessern.

 

Was meint Ihr?

Thomas

 

Thomas Scherm

30 Jahre IT. Begonnen mit Fortran, Assembler, Modula-2 und Pascal, dann Java. Erst in der klassischen Projektwelt, seit 2006 überzeugt von Agile. Ehemaliger Entwickler, Architekt, Enterprise Architekt. Berater, Projektmanager und CIO.

Seit 2011 für das Team und die Kunden in München und Umgebung verantwortlich.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Artikel von Thomas Scherm

Agile Management

Continuous Delivery – Haben Sie Agilität im Blut?

Weitere Inhalte zu Agile Management

Agile Management

Planlos agil

Agile Management

legacy.org => agile.org (Teil 3)

Kommentare

  • Christoph

    Richtig, und da stimme ich auch weitestgehend mit dir überein: Continous Delivery ist aus meiner Sicht eines der wichtigsten Ziele, die es seitens Management zu erreichen gilt. In kleinen Teams, die agil (ob es nun Scrum oder ein Derivat ist) arbeiten ist ein kurzer Time-To-Production-Zyklus Gold und Geld wert.
    Aber: sobald die Masse der Entwickler, Tester (generell Mitarbeiter) eine kritische Menge übersteigt, sollte jedem klar sein, dass CD realistischerweise nur jenseits der „Einschwingphase“ erreicht werden kann. Während dieser Phase kommen täglich/wöchentlich neue Artifacts hinzu (bzw. fallen weg), deren Konfiguration, Paketierung und Deployment (noch) keinem festen Schema folgen („Pack das Jar mal dahin.“, „Die Config lassen wir erstmal im Code.“, „XYZ machen wir später.“). Nach dieser „Einschwingphase, die von Projekt zu Projekt variiert, kann der Weg von einer CI hin zu einer echten CD verfolgt werden. Aber das braucht Zeit und ein lang laufendes Projekt, sowie eine stabile Umgebung.

    • Thomas Scherm

      Hi Christoph,

      Dein „aber“ ist sicherlich ein potenzielles Problem. Um das Problem zu vermeiden und auch ein gutes Projektsetting hinzubekommen, würde ich immer vorschlagen, mit einem agilen Team mit maximal 7 – 8 leuten in EINEM Raum zu beginnen und erst nach Einschwingen das Team auszubauen bzw. in mehrere Teams zu erweitern (z.B. Scrum of Scrum). So hat das Ramp Up Team die Chance, die Pflöcke an der richtigen Stellen, auch für CD, einzuschlagen.

      Grüße

      Thomas

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.