Folge 51: Migrator der Schreckliche

Unsere WordPress-Migration lässt uns auch Wochen später nicht los!
Hmmmm… Manche behaupten, wir seien noch mitten drin! Aber lassen wir das…
Da konnten wir uns noch so gut vorbereiten, das ein oder andere Detail beißt dann doch recht fies (*cough*https-only*cough*). Da war der Respekt im Vorfeld ja nicht ganz unberechtigt!
Also long story short:
In Folge 51 geht es um Migrationsprojekte. Die beiden Mikrofon-Gazellen haben beide auch sowas, sagenwamal, schon mal gemacht.
Und – surprise, surprise – so richtig schmuuf ging das nie. (Warum sind sie dann überrascht? Man weiß es nicht!)
Wir verquasseln uns also mal wieder, in dem wir über das wie, warum und wieso einer Migration quatschen, genüsslich unsere Lieblingsfallstricke häkeln und uns an so etwas wie Best-Practices wagen. Denn mal los!

Links:

Bier:

  • Unser geschätzter Kollege Manfred hat uns schönes Bier mitgebracht:
  • Der Bene bringt dem Holger einen leckeren Bierlikör von der Mosel mit.

Datum der Aufnahme: 16.09.2018

3 Gedanken zu „Folge 51: Migrator der Schreckliche

  1. Liebes @Autoweird.fm Team

    Vielen Dank für diese interessante und amüsante Folge. Ich teile viele eurer Punkte, möchte aber ein paar steile/provokante Thesen ergänzen:

    tl;dr;
    0) Alles ist Migration
    1) Softwareentwicklung ist Migration
    2) Agile Projektentwicklung vs. Agile Produktentwicklung
    3) Migration von Projekt zu Produkt

    0) Jede kontinuierliche Änderung eines Prozesses ist Migration. Ob nun digital oder analog. Werden Papierformulare aktualisiert, dann haben Menschen dafür eine Migrationsstrategie. Werden analoge Prozesse digitalisiert, dann ist auch dies mit einer Migration verbunden. Und sei es, dass $Person weiß, dass es das alte Formular gab und die Zeile jetzt im neuen Webformular anders heißt, oder die Daten (noch) nicht im neuen System zu finden sind. Wenn ein Unternehmen nicht mehr migriert, dann wird es über kurz oder lang nicht mehr am Markt bestehen können, da sich die äußeren Rahmenbedingungen ständig ändern. Seien es geänderte Gesetze, oder Marktteilnehmer, oder Kundenverhalten.

    1) Migration ist IMHO der absolute Normalfall in einem iterativen Softwareentwicklungsprozess und insbesondere in einem agilen PRODUKTentwicklungsprozesses. Jede Änderung von Code/Daten/Business Logik stellt eine Migration einer vorherigen Version auf eine neue dar. Auch wenn alte Logik nicht angefasst wird, besteht die Migration darin, dass bestehende Logik um eine weitere, davon unabhängige, Logik erweitert wird.

    2) Der Unterschied zwischen PRODUKT und PROJEKT Entwicklung erfordert IMHO Umdenken bei Projekt-Managern, die Produkt-Owner werden sollen. Auch dem Management muss der Unterschied klar sein, dass sie im Falle einer kontinuierlichen Produktentwicklung auch kontinuierlich Geld und Zeit in die Wartung, Weiterentwicklung, Migration und den Betrieb stecken müssen. Ein agiles Projekt, welches in einen “Betriebsmodus” übergeht, und danach nicht kontinuierlich weiterentwickelt (migriert) wird, ist IMHO keine PRODUKTentwicklung, sondern ein agiles PROJEKT, welches “abgeschlossen” wurde. Damit nimmt man direkt in Kauf, dass es auch veraltet und irgendwann wieder mit großen Kosten durch ein neues Projekt ersetzt werden muss.

    3) Auch die Transition von einem PROJEKT in ein PRODUKT ist eine Migration. Vielleicht ist das sogar die schwierigste Migration, da viele Menschen es gewohnt zu sein scheinen, dass ein Projekt anfängt und fertig ist. Wenn Produktteammitglieder (z.B. POs, Scrummaster, DevSecOps,…) mit dem Wissen arbeiten, dass sie schnell Updates ihrer Software ausrollen können, sollen und müssen, dann entwickeln sie anders, als wenn sie auf diesen Prozess keinen Einfluss mehr haben.
    Beispiel: Wenn sich irgendeine Business Regeln alle Monat ändert, es aber ein kleiner Aufwand ist, die Software anzupassen und den neuen Prozess auszurollen, dann könnte man diese Prozessänderung so gestalten, dass sie nur von Produktentwicklern gemacht werden kann. Falls diese aber nach Abschluss des Projekts nicht mehr zur Verfügung stehen, dann braucht man eventuell eine Pflegemöglichkeit für den Anwender, der die Prozesse ändern kann, um die gleiche Flexibilität in den Prozessen gewährleisten zu können.

    Vielen Dank für euren Podcast und das Teilen von euren Erfahrungen. Fünf Sterne von mir!

    1. Zustimmung.
      Migration kann für den Kunden sichtbar sein – z.B. Migration auf neues Design-Theme, oder kann/sollte unsichtbar sein (Wechsel von Datenbank A nach Datenbank B).
      Im zweiten Fall sehe ich auch refactoring als “mini-migration” an. Denn der Source wird evtl. auf links gekrempelt, aber die Funktionalität sollte sich (hoffentlich mit test abgesichert) nicht ändern.

    2. Hi Till,

      erstmal vielen Dank für das Lob und dein Feedback.
      Deinen Punkten (Zero-based! 😍) kann ich auch nur zustimmen. So provokant sind die gar nicht 🙂
      Aaaaber: Bene und ich haben, als wir von “Migrationsprojekt” gesprochen haben, beide wohl implizit eine etwas engere Definition im Kopf gehabt.
      Ich versuche mal ein paar Eckpunkte zu formulieren, die für mich ein Migrationsprojekt ausmachen:
      Zunächst haben wir eine rein technische Migration im Kopf gehabt. Daß sich da möglicherweise (fachliche) Prozesse ändern ist aber durchaus richtig.
      Technische Migration ist oft Bestandteil eines Projekts (wir schauen halt qua Job eher Richtung Projekt). Das berühmte SQL Skript kurz vor Produktionsgang. Ein Migrationsprojekt ist dieser Bestandteil aber Hauptaufgabe und dann üblicherweise viel komplexer als es in “normalen” Projekten ist.
      Ein System läuft und ist “fertig”. Nun soll dies auf eine neue Plattform gebracht werden.

      Ich habe da immer ein spezielles Projekt im Kopf:
      Altes System, läuft super, aber der ursprüngliche Hersteller wartet es nicht mehr (und hat auch die Sourcen :()
      Der eingesetzte Application Server wird zu teuer
      Das System soll auf ein neuen AS umgezogen werden. Da aber schon älter müssen Anpassungen gemacht werden.
      Die Anpassungen waren dann größerer Natur und mittels Golden Master Tests wurde die Funktionsfähigkeit sichergestellt.
      Hier war für mich der Migrations-Aspekt die dominierende Triebfeder überhaupt dieses Projekt anzugehen.

      Vielleicht fällt mir noch ein bessere Definition ein. 🙂

      Bis dahin und liebe Grüße!

Schreibe einen Kommentar

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