Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.python > #4456

Re: [Python-de] Deploy-History

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>

Show all headers | View raw


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


Thread

Re: [Python-de] Deploy-History Marcel Hellkamp <marc@gsites.de> - 2016-05-11 16:22 +0200

csiph-web