Der Deployment Day der IPC 2012

Der Deployment-Automat
Kommentare

Gutes Deployment zeichnet sich durch wenige Eigenschaften aus: Es muss schnell gehen und möglichst fehlerfrei sein. Und noch besser ist es, wenn es bei allen Kunden auf Anhieb funktioniert. Wie man Kundenwünsche schnell erfüllt, den Release-Zyklus beschleunigt und so langfristig die Auftraggeber begeistert, zeigten die Speaker auf dem Deployment Day der IPC 2012 in Mainz.

Am einfachsten lässt sich dies über Automatisierung regeln, doch dazu kommen wir später. Denn zunächst umriss Arne Blankerts (thePHP.cc) ein breites Spektrum von Deployment-Möglichkeiten:

  • PHP-Packaging mit Pear, Pyrus oder Composer
  • Gitpush
  • OS-Level-Packaging mir rpm oder yum
  • Auslieferung als Phar oder tarball

Am Anfang steht die Frage: „Was möchtest du erreichen? Den Code unter die Leute bringen, oder nur die App verfügbar machen?“ Doch bevor wir dies tun, müssen wir sicher gehen, dass die Anwendung einwandfrei funktioniert. Und das geht am besten über Continuous Integration. Hier könnte Phing die Lösung für Eure Probleme sein.

Phing steht für „PHing Is Not GNU make“ und ist ein PHP-Build-System auf der Basis von Apache Ant. Oliver Mueller (TEQneers) erklärte uns in seiner Session „Phingified CI and Deployment Strategies“, wie sich so ein Build-Prozess mitsamt Unit-Testing, Kompression, Dokumentation, Packaging bis hin zum Deployment automatisieren lässt, sodass Versionierung ein Leichtes wird.

Oliver Mueller (TEQneers) zeigt den IPC-Gästen, wie sie mit Phing ihre Qualitätsstandards automatisch sichern.
I hate repeating stuff

Dank Phing müssen die mühseligen Einzelschritte vor dem Deployment nicht mehr von Hand ausgeführt werden. Dies hat auch den Vorteil, dass neue Mitarbeiter sich diesen Prozess nicht mehr antrainieren müssen. Wenn erst einmal die build.xml mit den nötigen Targets und Filesets gefüttert wurde, kann man sich über phing -l ganz genau zeigen lassen, was bei dem Build-Prozess geschehen wird. Der ganze Build-Prozess lässt sich dann schlichtweg über ein Aufrufen von phing starten (sofern die defaults gesetzt wurden). Dies begünstigt, dass man sehr oft und nach nur wenigen Änderungen releast. Und sollte anschließend ein Problem im produktiven Einsatz auftreten, lassen sich die Ursachen erheblich leichter identifizieren als nach größeren Updates.

Auch beim Server-Aufsetzen die Fäden selbst in die Hand nehmen

Manchmal reicht es nicht, nur eine PHP-Anwendung an die Kunden oder die Öffentlichkeit auszuliefern. Manchmal muss die komplette Umgebung stimmen. Dass man auch ganze Server-Landschaften orchestrieren kann oder die Feature-Sets auf sämtlichen Entwickler-Maschinen vollautomatisch synchron halten kann, zeigten Hans-Christian Otto (crosscan) und Joshua Thijssen (NoxLogic) in ihren Vorträgen zu Puppet

Joshua Thijssen (NoxLogic) führt die Zuschauer auf der IPC12 ein in die Welt von Puppet

In DevOps Teams ist Puppet schon an der Tagesordnung, und Thijssen ist sich ganz sicher, dass es in den kommenden zwei bis drei Jahren auch in den restlichen Entwicklerkreisen zum Guten Ton gehören wird, Versionskontrolle auf Ebene der gesamten Infrastruktur zu betreiben. Und genau dies lässt sich mit Puppet bewerkstelligen.

Puppet ist ein Tool, das anhand von Manifesten mit Clients kommuniziert, die die in den Manifesten festgelegten Bedingungen zu erfüllen haben. Und diese können so ziemlich alles beinhalten:

  • Ist Paket X installiert?
  • Läuft Prozess Y gerade?
  • Startet Dienst Z automatisch?

Die Manifeste von Puppet werden in einer Domänenspezifischen Sprache geschrieben, die syntaktisch gewöhnungsbedürftig ist. Aber dies lässt sich mit dem Eclipse-Plug-in Gepetto beherrschen. Was einem auch viel Arbeit abnehmen kann, ist die Suche nach bestehenden Klassen, die als Module bezeichnet werden und in Repositories wie GitHub oder example42 zu finden sind. Und ist diese Hürde überwunden und das erste Manifest fertiggestellt, kann es an die Feinheiten gehen:

Jeder Client schickt dem Puppet-Master seine „Facts“, also eine Liste von Eigenschaften über das System (Betriebessystem-Version, Prozessor-Architektur und -Takt, etc.). Auf diese Facts muss der Master passend reagieren können. Überdies legen wir fest, welches Toolset für Clients mit Windows-Umgebungen eingerichtet werden soll, und wie es ausschaut, wenn der Client mit Cent-OS aufwartet. Im Idealfall, wenn wir alles richtig gemacht haben, ist das Ergebnis nach jedem Durchlauf dasselbe. Puppet erweist sich somit als idempotent.

Über Tools wie Vagrant lässt sich so ein fertiger Server in Oracles VirtualBox vorbereiten und später auf einen echten Server überspielen. Und über Mcollector kann man auf den mit Puppet gewarteten Servern die Puppet-Dienste oder andere Prozesse aus der Ferne starten oder Facts einlesen. Otto warnt aber vor den Sicherheitsrisiken: Mit derartig mächtigen Tools muss man sehr behutsam umgehen und stets prüfen, ob die Verbindungen wasserdicht sind. Ansonsten sind die Fäden schnell in den Händen eines anderen.

Der Deployment Day auf der IPC in Mainz stand im Zeichen der Automatisierung: „Nichts müssen wir mehr selbst machen, außer Manifeste zu formulieren“. Wenn das unsere Großmutter wüsste…

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -