[Python-de] Continuous Integration: N git Repositories

Do Apr 21 10:38:45 EDT 2016

Hallo Martin,

ich vermute, dass du auch auf die Liste schreiben wolltest,
aber die Default-Konfig der Mailingliste mal wieder zugeschlagen hat.
Per Default geht das Reply nicht auf die Liste. Ich verstehe nicht,
warum das der Default ist. So ist deine Mail nur bei mir angekommen.
Das Reply schicke ich auf die Liste - Ich hoffe das ist ok.

Am 20.04.2016 um 18:20 schrieb Martin A. Brown:
>
> Hallo,
>
>>> ich hab zwar in Deiner Mail keine wirkliche Frage gelesen, will aber
>>> trotzdem mal antworten.
>>
>> Ja, Arnold, richtig gesehen. Ich hatte gar keine Frage gestellt.
>> Ich wollte als Einführung kurz die Begriffe klären.
>
> Ich finde Deine Frage die richtige Frage, und ich stimme mit Dir
> überein:
>
>     Es ist zum Heulen, dass das in jeder Firma immer wieder erneut
>     erfunden und erneut implementiert wird.
>
> (So muß es immer sein, wenn das richtige Gerät fehlt.)
>
> Ich schlage einen anderen Weg und Werkzeug vor.  Wenigstens, darf
> man 'Continuous Build' benutzen wenn Linux das Zielplatform ist.
> (Ich kenne mich mit Windows nicht aus.)
>
> Kurz:
>
> Hast Du von dem OBS, Open Build Service gehört?  Ich empfehle es:
>
>    http://openbuildservice.org/
>
>> Ich hätte gerne ein paar Verbesserungen an dem Setup. Aber es ist
>> im Moment schon eine Bastellösung.
>
> Wenn man (irgend)eine Software sehr genau anschaut sieht man daß es
> alles gebasteltes Zeug ist.  Wunderschönes gebasteltes Zeug!
>
> Aber im Ernst, muß ich zugeben:  Eine Bastellösung führt in Richtung
> Komplexität und Komplexität ist unser Erzfeind hier.
>
>> Ich bin kein Freund von komplexer Konfig in Jenkins. Kommt eine
>> neue Firma dazu, was dann? Eine Web-GUI ist ja ganz nett, aber
>> copy+paste von Jenkins-Konfig ist ähnlich wie copy+paste von
>> Quelltext. Das kann man machen, aber langfristig wird es
>> Kuddelmuddel.
>
> Jeder Konfig neigt stets in die Verwickelung.
>
>> Was ist an dem CI eines Projekts (Definition des Begriffs siehe
>> erste Mail) anders als am CI einer Bibliothek?
>>
>> Ein Projekt ist eigentlich nicht viel. Etwas Konfig und eine Liste
>> von Abhängigkeiten.
>
> Genau.
>
>> Ich stelle mir das so vor: Im CI des Projekts werden alle
>> Abhängigkeiten auf den aktuellsten Stand gebracht. Wenn dann die
>> Tests alle erfolgreich sind, dann wird der aktuelle Stand der
>> Abhängigkeiten festgezurrt und als stabil gekennzeichnet.
>>
>> Und dafür kenne ich im Moment kein Tool.
>
> Es ist wahrscheinlich daß man OBS auf solcher Weise benutzen könnte.
>
>> Bei uns gibt es rund 5 Repos bei denen es täglich Änderungen gibt
>> und rund 30 Repos mit wenig Änderungen.
>
> <snip>
>
> Vor einer Woche habe ich eine Einführung in OBS geschrieben.  Meine
> Absicht war den Anstoß und Hintergrund des OBS zu beschreiben und
> den Kern des Systems darzustellen.  Zweitens wollte ich einen
> Unterschied zwischen Continuous Integration und Continuous Build
> erklären.
>
>    http://linux-ip.net/continuous-build-with-the-open-build-service.html
>
> (Leider ist diese nur auf Englisch geschrieben.)
>

Das ist ok, ich kann englisch lesen.

Zitat von deinem Link:

 > I identify the Open Build Service (OBS), as one of the good solutions for continuous build.

Was ist "continuous build"? Ich konnte dazu keine Definition im Netz finden.

> Und, jetzt, weiter auf Deine Frage.  Die Idee daß Du vorgeschlagen
> hast, Thomas, scheint mir ganz nah an den Stärken des OBS.
>
> Jetzt versuche ich zu beschrieben wie ich dieses Problem mit OBS
> lösen würde.
>
> Ausgangspunkt:  5 Kunden, jeder hat seine eigene Infrastruktur.
>                  100 Paketen (mehr oder weniger)
>                  Entwicklungshaus, einige Mitarbeiter.
>                  Jenkins als CI server (jetzt auch mit 'artifacts')
>
> Was würde ich tun?  OBS hinzufügen.
>
> Wenn jedes Stück Software wirklich open source ist und nichts
> geschützt werden muß, dann startete ich einfach mit dem öffentlichem
> OBS.
>
>    * Für jede Kunde, würde ich ein OBS Projekt machen.
>    * Unterstützten Platformmen in 'prjconf' einschalten.  z.B.
>      für Kunde A, CentOS-7.1-x86_64, für Kunde B,
>      OpenSUSE-13.2-x86_64
>    * Ein einziges Paket [0] in das Projekt aufladen und sichern daß
>      das OBS gute RPMs baut
>    * Alle anderen Paketen aufladen und sichern daß alles gut läuft.
>
> Wenn die Software proprietär ist, dann kann man das OBS selbst
> installieren (es gibt auch Appliance und VM).  Dieselbe Strategie
> kann man folgen, aber man muß zuerst das ganze OBS mit den
> gewünschten Distributions ausstatten.  Dann kann man ein Projekt pro
> Kunde und so weiter machen.

Ich würde die self-hosting Variante nehmen.

> Bei einer früheren Firma, haben wir das gemacht.  Unsere eigenen
> 200+ Paketen brauchten ungefähr 350 öffentliche Abhängigkeiten.
> Wie kommt man zurecht mit so einer Menge von Software?  Nur mit
> Automatisierung.
>
> Unsere Lösung:
>
>    * OBS selbst installieren (ein einziger zweckbestimmter Rechner,
>      und einige zusätzliche fürs Bauen: "workers").
>    * Mit rsync, die Distribution kopieren lassen (täglich, unter
>      unserer Kontrolle); genannt "upstream distributions"
>    * Ein Projekt für alle andere öffentliche Abhängigkeiten;
>      A) ein Paket wird nicht von 'upstream' geliefert; B) wir
>      brauchten eine neuere Version; bei uns 'third-party' genannt
>    * Ein Projekt machen für jeden Geschäftszweck (in Deiner Lage
>      würde ich Ein Projekt pro Kunde machen)
>
> Ich habe zwei zusätzliche Gedanken.
>
> Erstens, ist es ganz richtig die gebauten Pakete festhalten zu
> wollen.  Mit dem OBS gibt es einige Mechanismen die hier dienen
> könnten, aber ich persönlich habe keine Erfahrung damit.  Unsere
> Lösung war ein bißchen komplexer, aber gut für die Entwickler.  Wir
> hatten ein Projekt für alle aktuellen Entwicklungsarbeit.
> Natürlich war dieses Projekt war oft beim Bauen.  Wenn ein Paket
> (oder eine Gruppe von Paketen) für Veröffentlichung bereit war,
> kopierten wir diejenigen in ein strenger kontrolliertes Projekt.
> So könnten wir die endgültige Paketen besser feststellen.
>
> Zweitens, kann man OBS mit VCS Quellen benutzen.  In OBS Sprache
> meint man 'source services'.  Diese Art von Konfiguration gleicht
> dem CI System wie Jenkins und Travis.
>
> Vielleicht ist diese Antwort nicht genau was Du erwarten hättest,
> denn diese ist keine Python-spezifische Antwort.
>
> Jedenfalls, sehe ich einen Unterschied zwischen continuous
> integration und continuous build.  Ich sehe das erfolgreiche Ablauf
> von Bauen und Testen in ein CI-System (e.g. Jenkins) als die
> Endstation von Entwicklung.  Anstatt diese 'build artifacts' zu
> benutzen, würde ich das ganze Bauproblem auf ein continuous build
> (e.g. OBS) schieben.
>
> Hoffentlich ist meine Antwort hilfreich,

Ja es war hilfreich. Ich weiß nun, dass ich nicht alleine mit
meinem Anliegen bin.

Eine Frage bleibt: Was ist Continous Build? Hast du den Begriff "erfunden",
oder von wo ist der?

> -Martin
>
>   [0] In meiner Erfahrung sind die Paketen nicht immer nur Python.
>       Meiner Meinung nach ist es gut, alle Software mit demselben
>       Package Management Tool (apt, dnf, zypper) zu beherrschen.
>       Daher, baue ich mein Python Paketen meistens in RPMs (und nun
>       .debs).  z.B.:
>
>         python setup.py bdist_rpm
>
> (Und, Entschuldigungen, wenn ich da oben irgendwo die Beugungen
> verwechselt habe.)

Welche Beugung?

Wir gehen derzeit genau den anderen Weg: Wir setzen voll auf virtualenv.
Das hat den Vorteil das wir zig virtualenvs auf einer Maschine laufen lassen können.

Prinzipiell fasziniert mich der Begriff "immutable container".

Ich stelle mir das so vor: Es wird ein Container gebaut, und getestet. Wenn
alle Tests ok sind, dann löst der neue Container der alten ab.
Dafür ist eine glasklare Trennung von Code und Daten nötig, die bei uns
im Moment noch nicht gegeben ist.

Gruß,
   Thomas

-- 
Thomas Guettler http://www.thomas-guettler.de/