Am 21.03.2017 um 14:26 schrieb Thomas Güttler guettliml@thomas-guettler.de: Wenn du willst kannst du auch noch etwas aus dem Nähkästchen plaudern :-) Wir setzten sowohl Jenkins als auch Gitlab und dessen CI ein. Letzteres für neuere Projekte, bei denen wir die Tests schon auf tox umgestellt haben (alle Tests benutzen pytest).

Die Tests über die Gitlab CI laufen in Docker-Images. Je nach tag in der .gitlab-ci.yml (oder so ähnlich) wird ein anderer Gitlab-Runner mit einem anderen Docker-Image verwendet. Um ein Projekt für die Gitlab CI zu konfigurieren, müssen wir eigentlich also nur dafür sorgen, dass die Tests unter tox laufen und eine .xml Datei zum Repo hinzufügen.

Da tox sich alle Python-Dependencies aus unserem eigenen devpi-Server holt, haben wir (sinngemäß) folgende Einträge in der tox.ini:

[tox] envlist = py27, py34, py35, py36 indexserver = default = {env:PIP_INDEX_URL:https://pypi.python.org/simple%7D ...

[testenv] setenv =

PYTHONPATH = {toxinidir}:{toxinidir}/mypackage

deps = -r{toxinidir}/requirements/dev.txt

commands = py.test -v --basetemp={envtmpdir} {toxinidir}/tests

(Sorry für die Formatierung, das iOS-Mailprogramm ist buggy und lässt mich das nicht korrigieren.)

Damit können wir den verwendeten Paketindex durch Setzen der Environment-Variable PIP_INDEX_URL je nach Build anpassen. Zum Beispiel wollen wir für die Builds des development-Branches einen anderen Paketindex verwenden, als für Builds des master-Branches. So müssen wir keine Alpha/Pre-Release-Pakete auf den Paketindex hochladen, der für den Code in Produktion im master-Branch da ist.

Am 22.03.2017 um 17:44 schrieb Thomas Güttler guettliml@thomas-guettler.de:

Per PIP_INDEX_URL habt für verschiedene pypi-Server, und einen anderen Paket-Stand. OK, interessant.

Macht das nicht viel Aufwand diese verschiedenen pypi-Server mit den passenden Paketen zu versorgen?

Mit Devpi kann man auf einem Server verschiedene Paketindexe haben, die von einander ableiten. Wir haben eine Paketindex für die Pakete der Produktionsumgebung (der auch aus der DMZ erreichbar ist) und einen Paketindex für die Development/Integration/Staging-Umgebung, der nur im lokalen Netz erreichbar ist. Der Dev-Index leitet vom Prod-Index ab, d.h. Er ist sozusagen ein Proxy: wenn Pakete nicht im Dev-Index sind, werden sie vom Prod-Index geholt. Aber man kann auf den Dev-Index neuere Paketversionen hochladen, die im Prod-Index nicht sichtbar sind. Außerdem können auf dem Dev-Index Paketversionen und deren Files überschrieben werden, während auf dem Prod-Index bei jeder Änderung eine neue Paketversion hochgeladen werden muss, er ist also nicht-volatil (Stichwort: Rollback).

In der Praxis wird also einfach eine neue Version eines Paktes zuerst auf den Dev-Index hochgeladen und - wenn alles funktioniert - mit einem Befehl auf den Prod-Index gepusht.

Zusätzlich kann jeder Entwickler noch einen eigenen Paketindex haben, aber das nur nebenbei.

Eine Frage zu "-r{toxinidir}/requirements/dev.txt": Sind die Paketversionen in dieser Datei gepinnt (also mit exakter Version zB ==a.b.c)?

In einer idealen Welt: ja ;)

In der Praxis sind wir leider erst dabei, das in allen Projekten Schritt für Schritt wirklich streng durchzusetzen. Momentan haben wir leider in vielen Projekten noch nur Versionsbeschränkungen (>=a.b,<c.d) in den Requirements-Dateien.

...

Falls ja, wie wird diese Datei aktualisiert?

Ich bin gerade dabei in unserem größten Projekt die Erzeugung der Requirements-Dateien aus Vorlagen mit pip-compile (pip-tools) einzuführen. Allein durch diesen Prozess sind schon etliche Dependency-Konflikte aufgefallen, die vorher unbemerkt blieben. Insbesondere in die Requirements fürs Development (Tests, Doc-Erzeugung usw.) schleichen sich schnell Dependencies ein, die wiederum andere Dependencies nach sich ziehen, die mit den Paketversionen, die für Produktionsumgebung gepinnt sind, im Konflikt stehen.

Es muss sich noch zeigen, ob der Weg mit pip-tools praktikabel ist, leider gibt es immer noch zu viele Pakete, die in ihrer setup.py irgendwelche Dependencies fest auf eine Version pinnen, obwohl dies eigentlich gar nicht nötig wäre, oder gar einfach ihre requirements.txt unverändert in die install_requires in der setup.py übernehmen. Die meisten Paketautoren sind sich wahrscheinlich gar nicht bewusst, dass sie damit bei Anwendungen, die ihre Pakete und noch andere Dependencies verwenden, die dies genauso machen, Versions-Konflikte heraufbeschwören.

Aber wenn man einmal eine Vorlage für die Requirements hat, aus der sich eine funktionierende Requirements-Datei erstellen lässt, kann man diese mit pip-compile leicht aktualisieren und merkt dann sofort, wenn eine neue Version eines Pakets Versionskonflikte mit einer anderen Dependency mit sich bringt.