Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.python > #4456
| From | Marcel Hellkamp <marc@gsites.de> |
|---|---|
| Newsgroups | de.comp.lang.python |
| Subject | Re: [Python-de] Deploy-History |
| Date | 2016-05-11 16:22 +0200 |
| Message-ID | <mailman.597.1462976535.32212.python-de@python.org> (permalink) |
| References | (1 earlier) <1A0ED9D0-FBB6-4C87-91C1-EC7DD4E92B95@zopyx.com> <57330038.8090604@thomas-guettler.de> <5733018D.40700@gsites.de> <57330CF9.5020101@thomas-guettler.de> <57334014.6020701@gsites.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
Back to de.comp.lang.python | Previous | Next | Find similar
Re: [Python-de] Deploy-History Marcel Hellkamp <marc@gsites.de> - 2016-05-11 16:22 +0200
csiph-web