[Python-de] Continuous Integration: N git Repositories

[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.)

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.

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,

-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.)

-- 
Martin A. Brown
http://linux-ip.net/