1. Buildout

    Patrick Gerken

    Freelancer

    • http://do3.cc
    • http://www.twitter.com/do3cc
  2. Was ist Buildout

    Buildout ist ein Tool zum Bauen von Python Anwendungen
  3. Was macht Buildout 1

    Definieren, welche Eggs installiert werden sollen.

    O RLY

    gifsforum.com

  4. Was macht Buildout 2

    Exakt definieren, was in welcher Version von wo geholt werden soll.
    Mein Egg benötigt weitere Eggs. Buildout löst die Abhängigkeiten auf. Ich kann, wenn ich will, genau definieren, welche Versionen ich haben möchte.
  5. Was macht Buildout 3

    C-Extensions
      [buildout]
      parts = foo
      [foo]
      recipe = zc.recipe.cmmi
      url = ftp://xmlsoft.org/libxml2/libxml2-git-snapshot.tar.gz
            
    Ich muss C-Klassen kompilieren. Buildout kommt mit CMMI Recipes (configure && make && make install) um sie zu bauen. Es gibt ein Buildout um reproduzierbar alle Python Versionen zu bauen.
  6. Was macht Buildout 4

    DRY

      [buildout]
      parts = haproxy
              nginx
              flask
      nginx_port = 8080
      haproxy_port = 8090
      flask_port = 5000
      ...
            
    Ich kann mit spezialierten "Recipes" oder generischen Template "Recipes" Konfigurationen für nginx, meinen supervisor, meine paster configuration oder meine config.py kreieren. Ports und Hostnamen trage ich an einer Stelle ein und alle Dateien enthalten die neuen Versionen.
  7. Was macht Buildout 5

    Grosses Ökosystem
    Rund um Plone gibt es Ökosystem das die Pluginarchtektur von Buildout nutzt, um sie zu erweitern.
  8. Ökosystem 1

    z3c.checkversions

    Sind meine Versionen noch aktuell?

    Wenn ich alle Versionen auf eine spezifische Version "gepinnt" habe, ist meine Installation anhand des Buildouts weitgehend reproduzierbar. Wenn ich neuere Versionen möchte bin ich aufgeschmissen. Ausser ich verwende z3c.checkversions. Damit kann ich relativ einfach für alle dependencies prüfen, ob es neuere Versionen gibt.
  9. Ökosystem 2

    mr.developer

    Arbeite mit der bleeding edge, dem trunk oder master.

    Ohne dabei auszubluten

    Mit mr.developer bin ich in der Lage für einzelne Eggs meine Source repositories anzugeben und entweder über die Buildout Konfiguration, oder ein Kommandozeilentool einzelne Source Checkouts zu aktivieren, oder zu deaktivieren. Wenn man sich darauf einigt, kann man über die richtige Verwaltung Releases planen. Erst wenn alle Source Checkouts im Buildout deaktiviert wurden, das heisst es wurden neue fertige Eggs dafür gebaut und deren Version eingetragen, wird ein neues Release deployed.
  10. Ökosystem 3

    zest.releaser

    Release in style

    Der zest.releaser ist eigentlich für Eggs gedacht. Er hilft, saubere Releases zu machen. Er vereinfacht es, Changenotes zu vervollständigen, Versionen zu aktualisieren, Zeitstempel für die Change Notes zu setzen, die richtige Version in Code Repo zu taggen, und bereitet den trunk/master für die nächste Version vor. Mit zest.releaser kann man aber beliebige Code repositories releasen, Hauptsache es gibt irgendwo eine Datei mit Versionsinfos und eine Datei für die Changes. Nur auf Pypi kommt man damit nicht. Mit den beiden Konventionen kann man relativ einfach fertige Pakete von Buildouts schnüren. Für ein gutes Gefühl bei einem sauberen Deployment.
  11. Technik

      [buildout]
      parts = fabric
      [fabric]
      recipe = zc.recipe.egg
      eggs = fabric
              
    Buildout alleine macht gar nicht so viel. Es liefert intern viele API Methoden für die "Recipes", aber Buildout an sich ist nur ein ConfigParser System mit Variablen und einigen globalen Parametern für die anderen Recipes. Die Funktionalität kommt mit den "Recipes" von denen Buildout selbst einige mitbringt. Das Beispiel auf diesem Slide ist installiert ein Egg.
  12. Reproduzierbarkeit

      [buildout]
      parts = fabric
      allow-picked-versions = false
      versions = versions
      [fabric]
      recipe = zc.recipe.egg
      eggs = Fabric
      [versions]
      Fabric = 1.5.1
      distribute = 0.6.34
      paramiko = 1.9.0
      pycrypto = 2.6
      zc.recipe.egg = 1.3.2
              
    Dieses Buildout ist schon ein wenig strenger. Alles ist genau gepinnt, per Parameter wird gesagt, das nix ungepinnt gebaut werden darf. So eine Buildout lege ich meinem Code Repository ein, und ich kann ziemlich sicher sein, das jemand das System so testen kann.
  13. Modularität

    Wenn das System komplexer wird, verteilen wir die Konfiguration eben auf mehrere Dateien. In base definieren wir das Grundsystem, in versions pinnen wir die richtigen Versionen, KGS ist ein link auf eine URL unter der wir (hoffentlich) ein "Known Good Set" an Versionspinnings für das Basissystem erhalten. Wir wollen ja nicht alles selbst machen. Darunter sind die Anpassungen an die jeweiligen Umgebungen. Debug mode für Entwicklung und Tests, die passenden Ports und Resource URLs für die Produktion und Backup und Maintenance Scripte.
  14. Eine Auswahl an wichtigen Recipes

  15. Vielen Dank!

    Wer hat noch Fragen?