Continuous Lifecycle 2014 in Mannheim – Tag 2

Nach dem interessanten ersten Tag, über den Torsten Gerbig bereits berichtet hat, begann der zweite Tag der “continuous lifecycle 2014″ für mich mit einem sehr gelungenen Vortrag tum Thema “Effektives Konfigurations-Management mit Chef, Vagrant und Veewee”. Hintergrund der Vortragenden ist die Entwicklung eines Integrations-Tools, welches Third-Party-Systeme miteinander verbindet. Die große Herausforderung, die sie mit dem vorgestellten Toolset bewältigen, sind die automatisierten Tests ihres Produkts gegen eine Menge dieser Third-Party-Systeme, die auch in jeweils verschiedenen Versionen getestet werden müssen. Daraus ergeben sich mehrere hundert verschiedene Konfigurationen, für die jeweils virtuelle Maschinen bereitgestellt werden müssen. Die Tools wurden jeweils kurz vorgestellt, und anschließend wurde die Verwendung anhand eines vereinfachten Beispiels erläutert, zusammen mit einigen Learnings und guten Tipps für eigene Projekte. Insgesamt fand ich diesen Vortrag sehr informativ und gut aufbereitet. Es hat Spaß gemacht zuzuhören.

(more…)

Continuous Lifecycle 2014 in Mannheim – Tag 1

Die zweite Auflage der Continuous Lifecycle fand dieses Jahr im Cogress Center Rosengarten in Mannheim statt. Der Andrang war mit 350 Teilnehmern so groß, dass die Kapazitäten am Vorjahres-Austragungsort in Karlsruhe nicht ausreichten.

Die diesjährige Veranstaltung widmete sich Konzepten, Prozessen und Tools von Continuous Delivery, DevOps und Agile ALM und versuchte auch dem entsprechend eine Mischung aus diesen Themen zu bieten. Zur Wahl standen an beiden Veranstaltungstagen der Konferenz in allen Slots jeweils drei Themen, wobei mir die Auswahl teilweise wirklich schwer fiel, da einige Talks, die parallel stattfanden, sehr interessant klingende Inhalte hatten. (Wer mag sich zur Zeit schon gerne zwischen Themen wie “Docker” und “DevOps als Kultur” entscheiden?) (more…)

.Net News – Januar Summary

metro-visualstudio-128-link

Neues Jahr, neues Glück? Ich denke neues Jahr, mehr Produktivität. Als DotNet’ler ist man ja schon fast ein wenig verwöhnt wenn man die Anzahl an Aktualisierungen in den bestehenden Produkten anschaut. Schon im ersten Monat des neuen Kalenderjahres startet Microsoft … Weiterlesen

Komplexe Deployments mit Drupal

Ein Stichwort das man immer wieder hört wenn es um Drupal geht ist «Community». Das liegt einerseits am zugrundeliegenden Kern, welcher mit Rechte- und Nutzerverwaltung, Tagging sowie Kommentarintegration von Haus aus viel mitbringt, was man für Auftritte mit Community-Fokus benötigt. Es liegt auch an den zahlreichen Modulen der Drupal-Community, welche die jeweiligen interaktiven Individualfunktionen bereitstellen. Spannend wird es nun, wenn neue Funktionen im laufenden Betrieb dazukommen.

Ausgangslage

Drupal pflegt sehr viel seiner Konfiguration in der Datenbank. Dies bedeutet prinzipiell, dass man entweder Dateien und Datenbank bei grösseren Funktionsänderungen komplett ersetzt oder die Datenbank erhält und alle Änderungen im Backend händisch auf der Live-Instanz nachträgt. Das händische Nachtragen ist bei grösseren Änderungen keine realistische Lösung, selbst wenn die Fenster für Downtime gross genug sind, allein schon aufgrund der Fehleranfälligkeit. Bei einer Seite mit viel User Generated Content scheidet das Ersetzen der Datenbank fast immer aus, wenn man nicht SQL-Tabellen per Hand zusammenführen möchte.

Features

Das Modul Features hat sich dabei in unserer Projekterfahrung als unverzichtbar erwiesen, um solche Deployments mit Drupal zu lösen. Ganz allgemein nimmt es Datenstrukturen wie Inhaltstypen, Felder, Menüs aber auch allgemeine Konfigurationen wie Berechtigungen aus der Datenbank und gibt diese in Form eines Moduls aus. Somit sind diese portabel und können durch das Aktivieren des erstellten Moduls deployed werden  (siehe auch Bundling site settings using Features). Die Versionierung hilft zudem dabei Veränderungen des Features einzustufen (z.B. direkte Übersteuerung gegenüber einer Überprüfung). Features zeigt dabei auch den jeweiligen Unterschied der Datenbank zur Codebasis in einem einfach zu bedienenden Frontend, was das Sichten von Abweichungen erleichtert.

Kurzum, es schafft Vertrauen, dass Einstellungen und Datenstrukturen so sind wie definiert, ohne dass man auf jedem System jede Administrationsseite individuell kontrollieren muss. Änderungen werden sofort sichtbar und können entweder durch erneuten Export in den Code integriert werden oder bei einem Anwenderfehler auch problemlos wieder rückgängig gemacht werden.

Es unterstützt aber auch bei der Entwicklung, da es die unabhängige Entwicklung von Funktionen ermöglicht, ohne dass auf dem gleichen Entwicklungssystem gearbeitet werden muss oder eine Datenbank geteilt werden muss. In Verknüpfung mit Gits intelligentem Fast-Forward-Merging lässt sich so ein sauberes und nachvollziehbares Commit- und Merge-Protokoll erreichen, welches funktionalen Code inklusive der benötigten Konfigurationsparameter enthält.

Content?

Wo die Drupalwelt hinter gewissen Enterprise-Systemen weiterhin zurückbleibt ist die Portabilität von Inhalten. Mit den oben beschriebenen Möglichkeiten lässt sich die Struktur von Inhalten ideal transferieren, der jeweilige Inhalt ist aber nicht ohne grössere Umstände von einer Instanz auf die andere gebracht, ohne dass die Datenbank ersetzt wird. Es verbleiben einem hierbei folgende stabile Möglichkeiten (mit denen wir gute Erfahrungen gemacht haben):

  • Export und Import von einzelnen Nodes: Besonders hilfreich bei komplexen Inhalten, wie einem Webform-Formular, das nicht mehrfach erfasst werden soll. Die Ausgabe des Exporters lässt sich wiederum auch in das VCS überführen und sichert somit die Transparenz der aktuellen Fassung.
  • Export und Import von Taxonomien: Der Transfer von Taxonomien mit Hilfe von Taxonomy CSV sollte für die meisten Szenarien ausreichen. Übersetzungen in Verbindung mit Hierarchie können etwas Handarbeit benötigen.
  • Einlesen von strukturieren Inhalten: Mit Feeds lassen sich Quellen wie CVS und XML mit moderaten Aufwand einmalig oder automatisch in Drupal als Inhalte einlesen, welche danach wie andere Inhalte weiterverwendet werden können. Wenn Inhalte in solchen Formaten zur Verfügung gestellt werden können, ist dies eine ideale Alternative zur Beschäftigung eines Content-Migration-Teams.