[Python-de] Deploy-History

[Thomas Güttler]

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/