Hallo,
Ich habe gelesen, dass Jenkins2 Pipelines unterstützt. Siehe https://jenkins.io/doc/pipeline/
Ich frage mich gerade: Will man das?
Bisher versuchen wir die Konfig in Jenkins möglichst unkompliziert zu machen.
Jenkins ruft ein Script auf, und zeigt ggf das Ergebnis der Tests.
Die Tests laufen in der Regel auf Remote-Hosts. Um auf Remote-Hosts Tests auszuführen nutzen wir nicht die Mittel vom Jenkins, sondern ein Script, dass dann mit Fabric oder Salt arbeitet.
Bin ich nun zu alt oder zu ignorant wenn ich mir sage: "Mich interessieren diese Pipelines überhaupt nicht"?
Laut obigem Link kann man damit neben CI auch CD (Continous Delivery) machen. OK, dass machen wir bisher auch schon mit Jenkins. Die Fabric/Salt Scripte sind idempotent. Sie können also zum Erstellen von Systemen genauso genommen werden wie zum Aktualisieren von Systemen (wir arbeiten bisher ohne Container).
Wie seht ihr das?
Gruß, Thomas
On 3 May 2016, at 10:04, Thomas Güttler wrote:
Bin ich nun zu alt oder zu ignorant wenn ich mir sage: "Mich interessieren diese Pipelines überhaupt nicht"?
Wahrscheinlich - mein Auto hat einen Tempomat und ich verwende ihn nichts. Ich verstehe den Sinn Deines Postings nichts. a) hat nichts mit Python zu tun und b) macht dir i.A. keine Software die Vorgabe bestimmte neue Features zu verwenden.
-aj
Am 03.05.2016 um 10:17 schrieb Andreas Jung:
On 3 May 2016, at 10:04, Thomas Güttler wrote:
Bin ich nun zu alt oder zu ignorant wenn ich mir sage: "Mich interessieren diese Pipelines überhaupt nicht"?
Wahrscheinlich - mein Auto hat einen Tempomat und ich verwende ihn nichts. Ich verstehe den Sinn Deines Postings nichts. a) hat nichts mit Python zu tun und b) macht dir i.A. keine Software die Vorgabe bestimmte neue Features zu verwenden.
Meine Intention ist es, mich mit anderen Python-Software-Entwicklern über dieses Thema zu unterhalten.
Was ist war die Intention deiner Mail?
Gruß, Thomas
On Tue, 3 May 2016 10:04:43 +0200 Thomas Güttler guettliml@thomas-guettler.de wrote:
Ich habe gelesen, dass Jenkins2 Pipelines unterstützt. Siehe https://jenkins.io/doc/pipeline/ Ich frage mich gerade: Will man das?
Ja, manchmal.
Bisher versuchen wir die Konfig in Jenkins möglichst unkompliziert zu machen.
Das ist gut.
Jenkins ruft ein Script auf, und zeigt ggf das Ergebnis der Tests.
Das ist ein workaround für einen jenkins-Nachteil, den travis und gitlab richtig machen: Dort sind die build/CI-Anweisungen direkt in skripten in dem jeweiligen repo abgelegt. Bei jenkins muss ich selber einen Eintrag im Job machen, der das skript aufruft.
Und muss damit eine Folge von Jobs in jenkins grafisch konfigurieren und kann es nur in jenkins "speichern" und nicht versionieren. Wohingegen travis und gitlab die Definition für einzelne Jobs oder eben ganze Pipelines (mit Parallelität) alles in config-Dateien direkt im Repo haben wollen.
Mit gitlab kann ich also die Art meiner Pipeline a) branch-abhängig machen (ginge mit jenkins auch) und b) neue Pipelines in einem story-branch testen und mit dem normal git-workflow meiner Firma in 'Produktion' bringen. Bei jenkins gibt es an der Stelle nur hopp-oder-top oder eben ganz viel optionalen code. Und Änderungen an der pipeline sind dennoch meist gleichzeitig für alle branches, die diese Pipeline durchlaufen.
Die Tests laufen in der Regel auf Remote-Hosts. Um auf Remote-Hosts Tests auszuführen nutzen wir nicht die Mittel vom Jenkins, sondern ein Script, dass dann mit Fabric oder Salt arbeitet.
Jenkins kann auch als 'job' ein skript auf einer remote-Maschine per ssh ausführen, es braucht keinen jenkins-slave.
Bin ich nun zu alt oder zu ignorant wenn ich mir sage: "Mich interessieren diese Pipelines überhaupt nicht"?
Die Pipelines in jenkins gingen schon immer, denn schon immer konnte ein Job einen nächsten Triggern. Aber die kombinierte Ansicht dafür gab es bisher nur als Plugin. Und nun ist es vielleicht etwas besser integriert…
Aber ob es Dich "interessiert" kannst nur Du selber feststellen. Ich vermute ja, das Ihr abstrakte Pipelines schon länger nutzt, nur eben nicht als konkrete Pipelines eines bestimmten jenkins-Plugins.
- Arnold
Am 03.05.2016 um 21:15 schrieb Arnold Krille:
On Tue, 3 May 2016 10:04:43 +0200 Thomas Güttler guettliml@thomas-guettler.de wrote:
Ich habe gelesen, dass Jenkins2 Pipelines unterstützt. Siehe https://jenkins.io/doc/pipeline/ Ich frage mich gerade: Will man das?
Ja, manchmal.
Bisher versuchen wir die Konfig in Jenkins möglichst unkompliziert zu machen.
Das ist gut.
Jenkins ruft ein Script auf, und zeigt ggf das Ergebnis der Tests.
Das ist ein workaround für einen jenkins-Nachteil, den travis und gitlab richtig machen: Dort sind die build/CI-Anweisungen direkt in skripten in dem jeweiligen repo abgelegt. Bei jenkins muss ich selber einen Eintrag im Job machen, der das skript aufruft.
Und muss damit eine Folge von Jobs in jenkins grafisch konfigurieren und kann es nur in jenkins "speichern" und nicht versionieren.
Ja, stimmt. Das ist was mir an Jenkins nicht gefällt. Wenn ich N Projekte habe, die alle fast gleich sind, dann verwalte ich diesen Zoo lieber mit Tools mit denen ich als Entwickler vertraut bin. Also mit git und Texteditor.
Danke für den Hinweis zu gitlab. Ich bin mit jenkins nicht verheiratet :-)
... andererseits ist ein Wechsel nicht so leicht zu machen. Der Aufwand des Wechsels muss ja begründbar sein....
Gruß, Thomas
Hallo zusammen,
Am 03.05.2016 um 10:04 schrieb Thomas Güttler guettliml@thomas-guettler.de: Ich habe gelesen, dass Jenkins2 Pipelines unterstützt. Siehe https://jenkins.io/doc/pipeline/
Ich frage mich gerade: Will man das?
Ich habe dieses Feature mit Neugierde aufgenommen und finde es spannend, aber gleichzeitig die Möglichkeiten aktuell noch einigermaßen limitiert.
Ich sehe aktuell keinen wichtigen Grund vorhandene Jobs auf Pipelines umzubauen. Mir fehlt besonders die Möglichkeit Multikonfigurationsprojekte abzubilden, um so gegen verschiedene Python-Versionen zu testen. Aktuell nutze ich dafür das Plugin von ShiningPanda.
Eine Möglichkeit ist hier vermutlich einen bereits existierendes Multikonfigurationssprojekt aufzurufen. Die Möglichkeit vorhandene Projekte einzubinden ist in meinen Augen eine der Stärken der Pipeline. Dadurch muss nicht alles neu geschrieben werden, auf bewährtes kann ich zurückgreifen.
Was ich als eine sehr große Stärke der Pipelines empfinde ist die Darstellung. Ich habe einen lang laufenden Job, der Dokumentation in verschiedenen Sprachen und Formaten erstellt, testweise mit Pipelines umgesetzt. Wer auf die Dokumentation wartet, kann sofort sehen an welcher Stelle gerade der Job beschäftigt ist - oder eventuell abgebrochen ist - und wie lange er vermutlich noch bis zum Ende benötigt. Jenkins hatte vorher bereits eine Ansicht der Builddauer unter „Trends“, aber dort sah man weder einzelne Schritte, noch die Gesamtdauer, wenn ich einen Jobverbund hatte.
Interessant finde ich auch, dass man vorhandene Builds wiederholen kann. Ist mir das vorher nur nie aufgefallen oder existierte diese Möglichkeit im Kern wirklich nicht?
Bisher versuchen wir die Konfig in Jenkins möglichst unkompliziert zu machen.
Jenkins ruft ein Script auf, und zeigt ggf das Ergebnis der Tests.
Ich denke das ist eine gute Idee. Verschiedene Schritte existieren bei uns als Scripte, so dass jeder Entwickler einfach die Tests laufen lassen oder Pakete für Deployments erstellen kann.
Eine weitere Limitierung der Pipelines ist übrigens, dass man keine Test-Ergebnisse und Coverage darstellen lassen kann. Das ist für mich bisher der Grund gewesen bei Jenkins zu bleiben und nicht zu Gitlab CI oder ähnlichem zu wechseln.
Bin ich nun zu alt oder zu ignorant wenn ich mir sage: "Mich interessieren diese Pipelines überhaupt nicht“?
Nein, ich denke hier hängt es stark vom Anwendungsfall ab. Wie Arnold geschrieben hat nutzt ihr im Prinzip schon Pipelines - nur eben nicht mit den Mitteln von Jenkins.
Gruß
Niko
participants (4)
-
Andreas Jung -
Arnold Krille -
Niko Wenselowski -
Thomas Güttler