OT: Deploy-History
Mal wieder off-topic, aber vermutlich haben viele auf dieser Liste ähnliche Anliegen. Per git-History sehe ich genau wann, wer und welche und Änderungen am Quelltext erfolgt sind. Super, bis jetzt alles gut. Nun wird der Code bei N Kunden unabhängig voneinander installiert. Hier fehlt mir bisher eine History. Ich sehe nicht sofort welche Änderungen, wann **installiert** wurden. Anwendungsfall: Der Kunde ruft an und meint, dass seit Dienstag alles langsamer ist. Ich will nun wissen welche Änderungen Montag oder Dienstag auf dem System eingespielt wurden. Wie löst ihr das? Umgebung: - Linux Serveranwendungen mit HTTP GUI und Rest Schnittstellen. - Ein Produkt (nennen wir es Ticketsystem) läuft bei N Kunden (mit N kleiner hundert). - Das Produkt besteht aus bis zu 10 Modulen (jeweils einzelne git-Repos). -- Thomas Guettler http://www.thomas-guettler.de/
Wenn Deine Kunden selber _irgendwas_ aus einem Repository installieren oder aktualisieren dann ist der Vorgehensweise aus meiner Sicht broken-by-design. Zu einer sauberen und reproduzierbaren und kontrollierbaren Release-Policy gehört eine saubere Paketierung und Versionierung. Wenn ein Kunden irgendeinen Stand von irgendwas in Kombination mit undefinierten Ständen von anderen Modulen laufen hat und in Eigenregie die Aktualisierung betreibt, dann liegt der schwarze Peter beim Kunden....also sorg für einen wohldefinierten Aktualisierungs- und Rollout-Mechanismus...was du hier beschreibst ist jedenfalls offensichtlich alles andere als ein geregelter Prozess. -aj On 11 May 2016, at 9:58, Thomas Güttler wrote:
Mal wieder off-topic, aber vermutlich haben viele auf dieser Liste ähnliche Anliegen.
Per git-History sehe ich genau wann, wer und welche und Änderungen am Quelltext erfolgt sind. Super, bis jetzt alles gut.
Nun wird der Code bei N Kunden unabhängig voneinander installiert. Hier fehlt mir bisher eine History. Ich sehe nicht sofort welche Änderungen, wann **installiert** wurden.
Anwendungsfall: Der Kunde ruft an und meint, dass seit Dienstag alles langsamer ist. Ich will nun wissen welche Änderungen Montag oder Dienstag auf dem System eingespielt wurden.
Wie löst ihr das?
Umgebung:
- Linux Serveranwendungen mit HTTP GUI und Rest Schnittstellen. - Ein Produkt (nennen wir es Ticketsystem) läuft bei N Kunden (mit N kleiner hundert). - Das Produkt besteht aus bis zu 10 Modulen (jeweils einzelne git-Repos).
-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Am 11.05.2016 um 10:53 schrieb Andreas Jung:
Wenn Deine Kunden selber _irgendwas_ aus einem Repository installieren oder aktualisieren dann ist der Vorgehensweise aus meiner Sicht broken-by-design.
Es gibt vor dem Deploy einen CI-Prozess. Bsp: foo-customer hat das core-Modul und 10 Plugins. Es wird im CI geklärt, dass diese für den Kunden foo-customer die Plugins alle zusammen harmonieren. Die 10 Versionsstände und die der sonstigen Libs sind "gepinnt". Das Ergebnis wird dann per Deploy-Prozess installiert. Bisher ist das ein Update (noch keine Wegwerf-Kontainer) Das Deploy wird nur durch uns, nie durch den Kunden gestartet.
Zu einer sauberen und reproduzierbaren und kontrollierbaren Release-Policy gehört eine saubere Paketierung und Versionierung. Wenn ein Kunden irgendeinen Stand von irgendwas in Kombination mit undefinierten Ständen von anderen Modulen laufen hat und in Eigenregie die Aktualisierung betreibt, dann liegt der schwarze Peter beim Kunden....also sorg für einen wohldefinierten Aktualisierungs- und Rollout-Mechanismus...was du hier beschreibst ist jedenfalls offensichtlich alles andere als ein geregelter Prozess.
Ich habe nur den Deploy-Prozess beschrieben, nicht das CI. Bitte erläutere was hier ungeregelt ist. Ich gehe davon aus, dass "Rollout" und "Deploy" hier synonym sind. Ja, du hast Recht. Die Info fehlte in der ersten Mail. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
Am 11.05.2016 um 11:49 schrieb Thomas Güttler:
Am 11.05.2016 um 10:53 schrieb Andreas Jung:
Wenn Deine Kunden selber _irgendwas_ aus einem Repository installieren oder aktualisieren dann ist der Vorgehensweise aus meiner Sicht broken-by-design.
Es gibt vor dem Deploy einen CI-Prozess.
Dann hast du doch deine Protokollierung. Oder werft ihr die build-logs einfach weg?
Am 11.05.2016 um 11:55 schrieb Marcel Hellkamp:
Am 11.05.2016 um 11:49 schrieb Thomas Güttler:
Am 11.05.2016 um 10:53 schrieb Andreas Jung:
Wenn Deine Kunden selber _irgendwas_ aus einem Repository installieren oder aktualisieren dann ist der Vorgehensweise aus meiner Sicht broken-by-design.
Es gibt vor dem Deploy einen CI-Prozess.
Dann hast du doch deine Protokollierung. Oder werft ihr die build-logs einfach weg?
Ja, wir haben die Build-Logs . Ja, ich könnte da etwas "basteln". Ich will aber nicht mehr "basteln". Insbesondere dann nicht, wenn es eine Sache ist, die eigentlich alle Softwareentwickler benötigen. Ich basteln gerne wenn eine individuelle Lösung benötigt wird. Das ist hier nicht der Fall. Früher haben sich echte Helden nur den selbstprogrammierten Editor genutzt. Ja, darauf habe ich keine Lust. Ich will "from pet to cattle". Die Frage war an die Liste gerichtet: Wie habt ihr das gelöst? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
Am 11.05.2016 um 12:44 schrieb Thomas Güttler:
Am 11.05.2016 um 11:55 schrieb Marcel Hellkamp:
Am 11.05.2016 um 11:49 schrieb Thomas Güttler:
Am 11.05.2016 um 10:53 schrieb Andreas Jung:
Wenn Deine Kunden selber _irgendwas_ aus einem Repository installieren oder aktualisieren dann ist der Vorgehensweise aus meiner Sicht broken-by-design.
Es gibt vor dem Deploy einen CI-Prozess.
Dann hast du doch deine Protokollierung. Oder werft ihr die build-logs einfach weg?
Ja, wir haben die Build-Logs . Ja, ich könnte da etwas "basteln".
Ich will aber nicht mehr "basteln". Insbesondere dann nicht, wenn es eine Sache ist, die eigentlich alle Softwareentwickler benötigen.
Ich basteln gerne wenn eine individuelle Lösung benötigt wird. Das ist hier nicht der Fall.
Jeder eurer Kunden hat (scheinbar) eine individuelle, aus einem CI-System heraus gefallenes Bundle und das definiert sich laut deinem Beispiel nicht nur durch eine Versionsnummer, sondern durch die einzelnen Versionen aller enthaltenen Module. Im schlimmsten Fall bekommt jeder Kunde einen völlig unterschiedlichen Stack, je nach dem welche Module enthalten sind. Außerdem werden Updates ebenfalls individuell, und nicht für alle Kunden gleichzeitig angestoßen. Soweit korrekt? Klingt für mich ziemlich individuell. Logisch gesehen sind die einzigen, die "vor fünf Tagen" in eine konkrete Version (eher Versionsliste) übersetzen könnten, das CI-System, oder der Mitarbeiter der das Upgrade für den Kunden durchgeführt hat. Einer von beiden sollte das also protokollieren, damit der Support nach lesen kann, welcher Kunde wann welches Versions-Bundle bekommen hat. Entweder das, oder ihr schreibt die Liste der Modul-Versionen mit in die Software und lasst den Kunden vorlesen, was auf der "Hilfe" Seite aufgelistet ist. Das wäre aber sicher nicht besonders Kundenfreundlich. Mir ist nicht ganz klar, was daran jetzt so schwer sein oder übermäßiges "basteln" erfordern sollte. Das kundenspezifische "pinning" findet doch laut deinem Beispiel bereits statt und ist automatisiert. Nun muss man die Infos nur irgendwo hin schreiben wo der Support sie finden kann. Würde ich so ein System mit Hausmitteln auf bauen, hätte ich ein GIT Repository mit einem Branch pro Kunde. Darin liegt die kundenspezifische Konfiguration, und eben auch diese 'pinning' Informationen, also die Versionslisten aller Komponenten die der Kunde bekommen soll. Im einfachsten Fall eben eine requirements.txt, um den Python Bezug in dieser Liste mal wieder her zu stellen. Das CI-System würde nun nach einem erfolgreichen Build mit neueren Versionen die requirements.txt aktualisieren und einen commit erzeugen. Ende der Geschichte. Schon ist alles hübsch nachvollziehbar protokolliert und wen Kunde X sagt das seine Installation seit Y Tagen kaputt ist, reicht ein `git log -p` um nach zu sehen was sich wann geändert hatte. lg
Am 11.05.2016 um 16:22 schrieb Marcel Hellkamp:
Am 11.05.2016 um 12:44 schrieb Thomas Güttler:
Am 11.05.2016 um 11:55 schrieb Marcel Hellkamp:
Am 11.05.2016 um 11:49 schrieb Thomas Güttler:
Am 11.05.2016 um 10:53 schrieb Andreas Jung:
Wenn Deine Kunden selber _irgendwas_ aus einem Repository installieren oder aktualisieren dann ist der Vorgehensweise aus meiner Sicht broken-by-design.
Es gibt vor dem Deploy einen CI-Prozess.
Dann hast du doch deine Protokollierung. Oder werft ihr die build-logs einfach weg?
Ja, wir haben die Build-Logs . Ja, ich könnte da etwas "basteln".
Ich will aber nicht mehr "basteln". Insbesondere dann nicht, wenn es eine Sache ist, die eigentlich alle Softwareentwickler benötigen.
Ich basteln gerne wenn eine individuelle Lösung benötigt wird. Das ist hier nicht der Fall.
Jeder eurer Kunden hat (scheinbar) eine individuelle, aus einem CI-System heraus gefallenes Bundle und das definiert sich laut deinem Beispiel nicht nur durch eine Versionsnummer, sondern durch die einzelnen Versionen aller enthaltenen Module. Im schlimmsten Fall bekommt jeder Kunde einen völlig unterschiedlichen Stack, je nach dem welche Module enthalten sind. Außerdem werden Updates ebenfalls individuell, und nicht für alle Kunden gleichzeitig angestoßen. Soweit korrekt? Klingt für mich ziemlich individuell.
Ja, so ist das. Wir haben N komplett voneinander unabhängige Systeme. In der Regel laufen die auch im Rechenzentrum des Kunden. Der Begriff "Bundle" gefällt mir ganz gut. Pro Kunde haben wir ein git-Repo, dass eigentlich super klein ist. Darin stehen die Versionsnummern der Pakete, die der letzte CI-Lauf als OK angesehen hat und ein die konkrete Konfig. Aber in dem Repo gibt es so gut wie keinen Code. Das ganze ist aber trotzdem ein per pip installierbares Python-Paket.
Logisch gesehen sind die einzigen, die "vor fünf Tagen" in eine konkrete Version (eher Versionsliste) übersetzen könnten, das CI-System, oder der Mitarbeiter der das Upgrade für den Kunden durchgeführt hat. Einer von beiden sollte das also protokollieren, damit der Support nach lesen kann, welcher Kunde wann welches Versions-Bundle bekommen hat.
Im CI-Protokoll wäre das durch etwas basteln auffindbar. Ich frage mich aber gerade: Will ich das? Den ähnlichen Ablauf haben doch sehr viele andere DevOps (ich wollte erst "Entwickler" schreiben, aber das hat mit entwickeln nicht mehr viel zu tun). Bei uns ist es ein kleines Team, das beides macht: Dev und Op.
Mir ist nicht ganz klar, was daran jetzt so schwer sein oder übermäßiges "basteln" erfordern sollte. Das kundenspezifische "pinning" findet doch laut deinem Beispiel bereits statt und ist automatisiert. Nun muss man die Infos nur irgendwo hin schreiben wo der Support sie finden kann.
Ja, du hast Recht. Es ist nicht schwer, mit dem Aufwand von ein paar Stunden wäre mein Wunsch für uns umsetzbar. Aber: Ich würde lieber ein bestehende open source Lösung einsetzen. Ich könnte auch unseren Code als open source verfügbar machen .... aber ist eben alter legacy Code, den ich lieber in die Tonne werfen würde :-)
Würde ich so ein System mit Hausmitteln auf bauen, hätte ich ein GIT Repository mit einem Branch pro Kunde. Darin liegt die kundenspezifische Konfiguration, und eben auch diese 'pinning' Informationen, also die Versionslisten aller Komponenten die der Kunde bekommen soll. Im einfachsten Fall eben eine requirements.txt, um den Python Bezug in dieser Liste mal wieder her zu stellen. Das CI-System würde nun nach einem erfolgreichen Build mit neueren Versionen die requirements.txt aktualisieren und einen commit erzeugen. Ende der Geschichte. Schon ist alles hübsch nachvollziehbar protokolliert und wen Kunde X sagt das seine Installation seit Y Tagen kaputt ist, reicht ein `git log -p` um nach zu sehen was sich wann geändert hatte.
Die Projekte der Kunden sind recht unterschiedlich es gibt kaum Dopplungen, darum haben wir nicht git-branches, sondern eigene Repos (wie gesagt bestehen die nur aus Config und den fixierten Abhängigkeiten). Wie gesagt: CI ist geklärt - Continous Deploy mit History ist nun die Herausforderung. Zurück zur eigentlichen Frage: Wie macht ihr das, wie machen das andere? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
participants (3)
-
Andreas Jung -
Marcel Hellkamp -
Thomas Güttler