Continuous Integration: N git Repositories
Die meisten Texte über Continuous Integration machen es sich aus meiner Sicht zu einfach.
Beispiel: Gegen ist das git Repository foo. Wenn es Änderungen darin gibt, dann werden alle Tests ausgeführt, wenn die erfolgreich sind, dann wird die Versionsnummer von foo um eins erhöht.
Obiges funktioniert sehr gut für Bibliotheken, aber nicht gut für ein Projekt.
Projekt -------
Für mich ist ein Projekt hauptsächlich Konfiguration. Es enthält so wenig Quelltext wie möglich.
Ein Projekt ist der firmenspezifische Einsatz eines Produkts. Es ist eine Art Container mit Abhängigkeiten
Bsp: modwork_foo mit requirements.txt
Produkt -------
Reales Beispiel: Wir haben die Produkte modarch (Archiv), modwork (Workflow), modcs (SAP-Contentserver), ...
Ein Produkt kann N optionale Plugins verwenden.
Ein Produkt benötigt zwingend ein Projekt als Container.
Continuous Integration auf Projektebene ---------------------------------------
Wenn in git-Repo "foo" Änderungen sind, dann starte die Test für "foo".....
Wie gesagt das klappt nicht für CI auf Projektebene. Das git-Repo des Projekts ist super klein. Hier sind so gut wie nie Änderungen. Also würde das CI nie gestartet werden.
Ich will im CI also nicht prüfen ob das Produkt "modwork" funktioniert, sondern ich will prüfen ob das firmenspezifische Projekt "modwork_foo" funktioniert. Dafür ist aber Quelltext aus vielen Repos nötig:
- modwork_foo - modwork - modwork_isu (optionales Plugin) - modtools (Bibliothek, die von N Produkten verwendet wird)
... könnt ihr das Problem verstehen?
Das ganze betrifft vermutlich nur Entwickler die ein Produkt für N Firmen verwalten.
Gruß, Thomas
In Jenkins (wie in den meisten modernen CI Systemen) lassen sich Abhängigkeiten definieren. Du kannst den Job für "modwork_foo" so konfigurieren, das er automatisch startet sobald eine der Abhängigkeiten neu gebaut wurden, auch wenn sich bei "modwork_foo" selbst nichts geändert hat. Damit ließe sich dein Szenario problemlos abbilden.
Am 19.04.2016 um 15:49 schrieb Thomas Güttler:
Die meisten Texte über Continuous Integration machen es sich aus meiner Sicht zu einfach.
Hi,
ich hab zwar in Deiner Mail keine wirkliche Frage gelesen, will aber trotzdem mal antworten. Das wir Dein Problem verstanden haben (und auch selber vor dem Problem standen) erkennst Du daran, das wir Dir Lösungen präsentieren, die sich seit Jahren(!) täglich(!) bewähren (Continous halt:).
Achja, wir haben auch nicht ein Produkt für N Kunden, sondern ein Produkt, das aus N Komponenten besteht.
Neben den erwähnten Anhängigkeiten in Jenkins, die man mit dem richtigen Plugin dann auch schön als Pipelines betrachten kann, nutzen wir auch die zeitlichen Trigger von jenkins. Selbst wenn sich nichts ändert, wird einmal täglich das Gesamtprodukt gebaut und getestet.
Ideal wäre dann noch (haben wir in dieser Firma nicht), wenn der jenkins für jeden erfolgreichen build/test Lauf ein tag in git pusht ("jenkins_build_ID_successful"). Und auf dem master-branch ein tag vorwärts bewegt um den letzten stabilen Build zu markieren. Damit kann man dann immer den stabilen Stand deployen…
- Arnold
On Tue, 19 Apr 2016 15:49:50 +0200 Thomas Güttler guettliml@thomas-guettler.de wrote:
Die meisten Texte über Continuous Integration machen es sich aus meiner Sicht zu einfach.
Beispiel: Gegen ist das git Repository foo. Wenn es Änderungen darin gibt, dann werden alle Tests ausgeführt, wenn die erfolgreich sind, dann wird die Versionsnummer von foo um eins erhöht.
Obiges funktioniert sehr gut für Bibliotheken, aber nicht gut für ein Projekt.
Projekt
Für mich ist ein Projekt hauptsächlich Konfiguration. Es enthält so wenig Quelltext wie möglich.
Ein Projekt ist der firmenspezifische Einsatz eines Produkts. Es ist eine Art Container mit Abhängigkeiten
Bsp: modwork_foo mit requirements.txt
Produkt
Reales Beispiel: Wir haben die Produkte modarch (Archiv), modwork (Workflow), modcs (SAP-Contentserver), ...
Ein Produkt kann N optionale Plugins verwenden.
Ein Produkt benötigt zwingend ein Projekt als Container.
Continuous Integration auf Projektebene
Wenn in git-Repo "foo" Änderungen sind, dann starte die Test für "foo".....
Wie gesagt das klappt nicht für CI auf Projektebene. Das git-Repo des Projekts ist super klein. Hier sind so gut wie nie Änderungen. Also würde das CI nie gestartet werden.
Ich will im CI also nicht prüfen ob das Produkt "modwork" funktioniert, sondern ich will prüfen ob das firmenspezifische Projekt "modwork_foo" funktioniert. Dafür ist aber Quelltext aus vielen Repos nötig:
- modwork_foo
- modwork
- modwork_isu (optionales Plugin)
- modtools (Bibliothek, die von N Produkten verwendet wird)
... könnt ihr das Problem verstehen?
Das ganze betrifft vermutlich nur Entwickler die ein Produkt für N Firmen verwalten.
Gruß, Thomas
Hi Arnold,
genau den Mechanismus des automatischen Releasens, den du erwähnt hast, haben wir implementiert, um ein kontinuierliches Deployment zu erlauben. Bei einem erfolgreichem Build wird ein Release (git tag etc.) erzeugt.
Continuous Integration -> Continuous Releasing -> Continuous Deployment
Läuft seit Jahren bei uns so und wir sind sehr zufrieden damit: für N Firmen mit jeweils M verschiedenen Modulen.
Neulich haben wir sogar ein völlig unbeteiligtes Problem mit diesem Vorgehen gelöst, wobei es hier nur als Krücke dient bis die wirkliche Lösung bereitsteht. Der Grund hierfür ist, dass sich die Entwickler voll und ganz aufs Entwickeln konzentrieren können und sich nicht mehr um Probleme wie Release-Management, vergessenes Aktualisieren von Abhängigkeiten, etc. kümmern müssen. Voll automatisch. :)
Sven
On 19.04.2016 20:08, Arnold Krille wrote:
Hi,
ich hab zwar in Deiner Mail keine wirkliche Frage gelesen, will aber trotzdem mal antworten. Das wir Dein Problem verstanden haben (und auch selber vor dem Problem standen) erkennst Du daran, das wir Dir Lösungen präsentieren, die sich seit Jahren(!) täglich(!) bewähren (Continous halt:).
Achja, wir haben auch nicht ein Produkt für N Kunden, sondern ein Produkt, das aus N Komponenten besteht.
Neben den erwähnten Anhängigkeiten in Jenkins, die man mit dem richtigen Plugin dann auch schön als Pipelines betrachten kann, nutzen wir auch die zeitlichen Trigger von jenkins. Selbst wenn sich nichts ändert, wird einmal täglich das Gesamtprodukt gebaut und getestet.
Ideal wäre dann noch (haben wir in dieser Firma nicht), wenn der jenkins für jeden erfolgreichen build/test Lauf ein tag in git pusht ("jenkins_build_ID_successful"). Und auf dem master-branch ein tag vorwärts bewegt um den letzten stabilen Build zu markieren. Damit kann man dann immer den stabilen Stand deployen…
- Arnold
On Tue, 19 Apr 2016 15:49:50 +0200 Thomas Güttler guettliml@thomas-guettler.de wrote:
Die meisten Texte über Continuous Integration machen es sich aus meiner Sicht zu einfach.
Beispiel: Gegen ist das git Repository foo. Wenn es Änderungen darin gibt, dann werden alle Tests ausgeführt, wenn die erfolgreich sind, dann wird die Versionsnummer von foo um eins erhöht.
Obiges funktioniert sehr gut für Bibliotheken, aber nicht gut für ein Projekt.
Projekt
Für mich ist ein Projekt hauptsächlich Konfiguration. Es enthält so wenig Quelltext wie möglich.
Ein Projekt ist der firmenspezifische Einsatz eines Produkts. Es ist eine Art Container mit Abhängigkeiten
Bsp: modwork_foo mit requirements.txt
Produkt
Reales Beispiel: Wir haben die Produkte modarch (Archiv), modwork (Workflow), modcs (SAP-Contentserver), ...
Ein Produkt kann N optionale Plugins verwenden.
Ein Produkt benötigt zwingend ein Projekt als Container.
Continuous Integration auf Projektebene
Wenn in git-Repo "foo" Änderungen sind, dann starte die Test für "foo".....
Wie gesagt das klappt nicht für CI auf Projektebene. Das git-Repo des Projekts ist super klein. Hier sind so gut wie nie Änderungen. Also würde das CI nie gestartet werden.
Ich will im CI also nicht prüfen ob das Produkt "modwork" funktioniert, sondern ich will prüfen ob das firmenspezifische Projekt "modwork_foo" funktioniert. Dafür ist aber Quelltext aus vielen Repos nötig:
- modwork_foo
- modwork
- modwork_isu (optionales Plugin)
- modtools (Bibliothek, die von N Produkten verwendet wird)
... könnt ihr das Problem verstehen?
Das ganze betrifft vermutlich nur Entwickler die ein Produkt für N Firmen verwalten.
Gruß, Thomas
python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Am 19.04.2016 um 20:08 schrieb Arnold Krille:
Hi,
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.
Wie Sven geschrieben hat (wir arbeiten zusammen) funktioniert das auch schon bei uns.
Alles prima? Nein. Es ist zum Heulen, dass das in jeder Firma immer wieder erneut erfunden und erneut implementiert wird.
Ich hätte gerne ein paar Verbesserungen an dem Setup. Aber es ist im Moment schon eine Bastellösung.
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.
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.
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.
Bei uns gibt es rund 5 Repos bei denen es täglich Änderungen gibt und rund 30 Repos mit wenig Änderungen.
Wir leben das sehr agil: Alles Repos, die von uns sind, werden ständig mit dem neusten Stand integriert.
Eine andere Lösung wäre es immer nur das zu integrieren, was man explizit hoch-zieht. ... Ja, das könnte man machen. Das nervt aber tierisch ständig für N Firmen die Abhängigkeiten zu aktualisieren.
Jetzt zum Anliegen: Ich würde gerne unsere "Bastellösung" durch ein gängiges Verfahren ersetzen.
Was soll gemacht werden?
CI eines Projekts
1. Nehme den letzten Stand des Projekts, bei dem alle Tests erfolgreich waren. 2. Aktualisiere in der Abhängigkeitsliste alle Pakete. Es sollte jedoch möglich sein einzelne Pakete auf eine Version zu "pinnen". 3. Setzte eine Testinstallation des Projekts auf - also mit dem aktualisierten Paketliste. 4. Führe alle Tests aller Pakete aus. 5. Falls alles ok, dann diesen Stand als stabil markieren und die konkrete Paketliste festhalten.
... Unittests sind eben so beliebt weil alles so einfach ist (es wird eine kleine klar definierte "Welt" getestet). Integrationstests sind eine ganz andere Sache ...
Gruß, Thomas
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:
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.)
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:
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
Am 21.04.2016 um 16:38 schrieb Thomas Güttler:
Per Default geht das Reply nicht auf die Liste. Ich verstehe nicht, warum das der Default ist.
Weil andersherum bei einem Fehler die Auswirkungen mehr Leute betreffen würden?
Es gibt Gründe dafür und Gründe dagegen. Ich mag es so, wie es ist, andere nicht.
Ich habe mir angewöhnt, bei Antworten auf Mailinglisten in Thunderbird immer Ctrl+Shift+L zu drücken, das öffnet eine Antwort an die Liste. Andere MUAs haben ähnliche Tastaturkombos oder Befehle.
Chris
Hallo und Gruß,
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.
Oof! Natürlich wollte ich auf die Liste schreiben. Danke, Thomas!
(Fast 20 Jahren mit Mailinglisten und ich mache immer noch denselben Fehler.)
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.
Huh--eine Ûberraschung. Siehe unten.
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.
Ich auch.
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?
Ich kann auch keine Definition finden, aber bei einer früheren Firma haben wir immer diesen Begriff benutzt. Vermutlich haben wir es erfunden, aber meistens benutze ich nur übliche Begriffe.
Jedenfalls ist die Hauptsache die Anwendung von diesem immer vorhanden 'continuous' auf eine 'reproducible build'. Daher, auch wenn es frei erfunden ist, 'continuous build'. Vielleicht hätte ich 'continuous delivery' in dem Text schreiben sollen.
Welche Beugung?
(Ich meine nur daß ich oft Probleme mit den Beugungen von Adjektiven habe.)
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.
Natürlich! Und, eine gute Lösung.
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.
Man sieht jetzt dieses Wort 'immutable'... Ich verstehe auch den gängigen Gebrauch von dem Container als API, genau wie Du beschreibst (habe aber noch keine Erfahrung damit).
Gruß,
-Martin
On 21.04.2016 20:12, Martin A. Brown wrote:
Hallo und Gruß,
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.
Oof! Natürlich wollte ich auf die Liste schreiben. Danke, Thomas!
(Fast 20 Jahren mit Mailinglisten und ich mache immer noch denselben Fehler.)
Da bist du nicht der einzige.
Aus diesem Grund würde ich eben nicht wie Christopher auf bei Behaltung des Status Quo pochen. Auf einer Mailingliste will man zu 99,9% der Liste antworten, nicht der Einzelperson. Wenn an einer Kreuzung ständig dieselbe Art an Unfällen vermehrt vorkommt, dann sind nicht die Menschen daran Schuld, sondern die Kreuzung sollte angepasst werden. Man kann Menschen nicht ändern.
vG Sven
Hallo,
On 2016-04-23 22:09, Sven R. Kunze wrote:
Aus diesem Grund würde ich eben nicht wie Christopher auf bei Behaltung des Status Quo pochen. Auf einer Mailingliste will man zu 99,9% der Liste antworten, nicht der Einzelperson. Wenn an einer Kreuzung ständig dieselbe Art an Unfällen vermehrt vorkommt, dann sind nicht die Menschen daran Schuld, sondern die Kreuzung sollte angepasst werden. Man kann Menschen nicht ändern.
wie Christopher gesagt hat, gibt es Gründe für und gegen die aktuelle Konfiguration. Dafür spricht zum Beispiel, dass man nicht so leicht eine private Antwort versehentlich an die Liste schickt. Das ist mir bei einer anderen Liste einmal passiert und es war mir recht unangenehm.
Wenn der Default ist, mit "Reply" nur an den Absender zu antworten, kann man bei einem Versehen immer noch die Mail an die Liste "hinterherschicken". Wenn man aber eine private Mail versehentlich an die Liste schickt, kann man sie nicht mehr zurückholen.
Von daher wäre ich sehr für die Beibehaltung der aktuellen Einstellung.
Einige Mail-Clients haben übrigens einen Extra-Befehl, um an die Liste zu antworten, auch wenn die Antwort per Default an den Absender gehen würde. In den Listenmails muss dazu ein Header gesetzt sein, was bei dieser Liste der Fall ist.
Viele Grüße Stefan
On 24.04.2016 20:06, Stefan Schwarzer wrote:
Hallo,
wie Christopher gesagt hat, gibt es Gründe für und gegen die aktuelle Konfiguration. Dafür spricht zum Beispiel, dass man nicht so leicht eine private Antwort versehentlich an die Liste schickt. Das ist mir bei einer anderen Liste einmal passiert und es war mir recht unangenehm.
Dass das unangenehm ist, kann ich mir sehr gut vorstellen.
Wenn der Default ist, mit "Reply" nur an den Absender zu antworten, kann man bei einem Versehen immer noch die Mail an die Liste "hinterherschicken". Wenn man aber eine private Mail versehentlich an die Liste schickt, kann man sie nicht mehr zurückholen.
Von daher wäre ich sehr für die Beibehaltung der aktuellen Einstellung.
Mein Post sollte auch nicht als Kritik verstanden werden, sondern eher als Hinweis, dass Menschen leider immer wieder dieselben Fehler machen werden.
Allerdings kann man sich schon vorstellen, dass es schwerer wiegt, eine private Nachricht öffentlich zu posten. Von daher habe ich kein Problem mit dieser Einstellung.
Einige Mail-Clients haben übrigens einen Extra-Befehl, um an die Liste zu antworten, auch wenn die Antwort per Default an den Absender gehen würde. In den Listenmails muss dazu ein Header gesetzt sein, was bei dieser Liste der Fall ist.
Mein Client verhält sich relativ intelligent und ersetzt den "Reply"-Button recht häufig durch "Reply List".
Eigentlich wollte ich mir auch die Shortcuts mal einprägen, aber dann bevorzuge ich doch die GUI und klicke den richtigen Button an.
vG Sven
On 2016-04-25 15:43, Sven R. Kunze wrote:
On 24.04.2016 20:06, Stefan Schwarzer wrote:
Wenn der Default ist, mit "Reply" nur an den Absender zu antworten, kann man bei einem Versehen immer noch die Mail an die Liste "hinterherschicken". Wenn man aber eine private Mail versehentlich an die Liste schickt, kann man sie nicht mehr zurückholen.
Von daher wäre ich sehr für die Beibehaltung der aktuellen Einstellung.
Mein Post sollte auch nicht als Kritik verstanden werden, sondern eher als Hinweis, dass Menschen leider immer wieder dieselben Fehler machen werden.
Sorry, dann habe ich dich missverstanden.
Allerdings kann man sich schon vorstellen, dass es schwerer wiegt, eine private Nachricht öffentlich zu posten. Von daher habe ich kein Problem mit dieser Einstellung.
Einige Mail-Clients haben übrigens einen Extra-Befehl, um an die Liste zu antworten, auch wenn die Antwort per Default an den Absender gehen würde. In den Listenmails muss dazu ein Header gesetzt sein, was bei dieser Liste der Fall ist.
Mein Client verhält sich relativ intelligent und ersetzt den "Reply"-Button recht häufig durch "Reply List".
Mein Thunderbird zeigt bei Listenmails "Reply" _und_ "Reply List" an. Im Fall der genannten Liste ging bei "Reply" die Mail leider dennoch an die Liste. :-/ Das ist nicht direkt falsch, wenn man "Reply" versteht als "Antworte an die Reply-To-Adresse", aber wenn man etwas unaufmerksam ist, sieht das "Reply" neben "Reply List" eben wie der Gegensatz (= private Mail) aus.
Oh je, ich sehe gerade, dass Thunderbird sogar als Tooltip bei "Reply" "Reply to the sender of this message" anzeigt, auch wenn die Reply-Adresse die Listen-Adresse ist. Das lädt natürlich geradezu zu einer Fehlbedienung ein.
Viele Grüße Stefan
participants (7)
-
Arnold Krille -
Christopher Arndt -
Marcel Hellkamp -
Martin A. Brown -
Stefan Schwarzer -
Sven R. Kunze -
Thomas Güttler