python tox, Erstellen von rpm virtualenv, als Teil der Ci-Pipeline, unsicher, wo im Workflow

8

Ich untersuche, wie Python-Anwendungen auch eine CI-Pipeline verwenden können, aber ich bin mir nicht sicher, wie ich den Standardarbeitsablauf erstellen soll.

Jenkins wird verwendet, um den ursprünglichen Repository-Klon zu erstellen, und initiiert dann tox. Im Grunde ist dies, wo maven, und / oder msbuild, Abhängigkeits-Pakete bekommen und bauen würden ... welches Tox über Pip tut, also alles gut hier.

Aber jetzt, für den verwirrenden Teil, ist der letzte Teil der Pipeline das Erstellen und Hochladen von Paketen. Entwickler würden wahrscheinlich erstellte Pakete in ein lokales Pip-Repository hochladen, ABER dann möglicherweise auch ein Bereitstellungspaket erstellen. In diesem Fall müsste es ein RPM sein, der ein virtualenv der Anwendung enthält. Ich habe einen manuell gemacht mit rpmvenev, aber unabhängig davon, wie es gemacht wurde, wie ein solcher Schritt zu einer Tox-Konfiguration hinzugefügt werden? In dem Fall, wenn rpmvenv, es erstellt seine eigene virtualenv, ein eigenständiges Kommando sozusagen.

    
TechZilla 09.04.2016, 18:30
quelle

1 Antwort

1

Ich gehe gerne mit der Unix-Philosophie für dieses Problem. Habe ein Werkzeug, das eine Sache unglaublich gut macht, dann komponiere andere Werkzeuge zusammen. Tox ist so konzipiert, dass Sie Ihre Tests in einer Reihe verschiedener Python-Umgebungen ausführen können, um sie dann zum Erstellen einer deb / rpm / etc für Sie zu verwenden. Ich denke, es ist ein bisschen ein Missbrauch dieses Tools. Es ist wahrscheinlich einfacher, tox zu verwenden, nur um alle Ihre Tests durchzuführen, dann abhängig von den Ergebnissen haben Sie einen weiteren Schritt in Ihrer Pipeline mit dem Erstellen eines Pakets für das, was gerade getestet wurde.

Jenkins 2.x, das zum Zeitpunkt des Schreibens relativ neu ist, scheint beim Bau von Pipelines viel besser zu sein. BuildBot durchläuft eine ordentliche Menge an Entwicklung und macht es bereits ziemlich einfach, eine gute Pipeline dafür zu bauen.

Was wir bei meiner Arbeit gemacht haben, ist

  • Buildbot in AWS, der Push-Benachrichtigungen von Github auf PRs erhält
  • Damit wird ein Andock-Container gestartet, der den aktuellen Code einliest und Tox (py.test, flake8 sowie Winkelmesser- und Jasmin-Tests) ausführt
  • Wenn der Tox-Schritt wieder sauber ist, starte einen anderen Andock-Container, um ein Deb-Paket zu erstellen
  • Schieben Sie das Deb-Paket auf S3 und lassen Sie sich Salt damit befassen, diesen Rechnern mitzuteilen, dass sie
    • aktualisieren sollen

Dieses deb-Paket ist auch nur als Build-Artefakt verfügbar, ähnlich wie Jenkins 1.x. Sobald wir bereit sind, ins Staging zu gehen, nehmen wir einfach das Paket und befördern es manuell zum Debian-Repo-Staging. Dito, um es zu prod zu rollen.

Werkzeuge, die ich für all das nützlich gefunden habe:

  • Buildbot , weil es in Python einfacher für uns ist, aber Jenkins würde genauso gut funktionieren. Unabhängig davon ist dies der Controller für die gesamte Pipeline
  • Docker, da jeder Build vollständig von jedem anderen Build isoliert sein sollte
  • Tox, der glorreiche Testläufer, der all diese Details behandelt
  • fpm erstellt das Paket. RPM, DEB, tar.gz, was auch immer. Sehr konfigurierbar und einfach zu Skript.
  • Aptly macht es einfach, Debian-Repositories zu verwalten und insbesondere auf S3 zu schieben.
Paul 04.05.2016, 23:28
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Was ist der empfohlene Weg, um in der Produktion verkleinerte Versionen anzufordern, aber bei der Verwendung von browserify in der Entwicklung zu debuggen?