[Python-de] Continuous Integration: N git Repositories

[Sven R. Kunze]

Hi Arnold,

genau den Mechanismus des automatischen Releasens, den du erwähnt hast, 
haben wir implementiert, um ein kontinuierliches Deployment zu erlauben. 
Bei einem erfolgreichem Build wird ein Release (git tag etc.) erzeugt.

Continuous Integration -> Continuous Releasing -> Continuous Deployment

Läuft seit Jahren bei uns so und wir sind sehr zufrieden damit: für N 
Firmen mit jeweils M verschiedenen Modulen.

Neulich haben wir sogar ein völlig unbeteiligtes Problem mit diesem 
Vorgehen gelöst, wobei es hier nur als Krücke dient bis die wirkliche 
Lösung bereitsteht. Der Grund hierfür ist, dass sich die Entwickler voll 
und ganz aufs Entwickeln konzentrieren können und sich nicht mehr um 
Probleme wie Release-Management, vergessenes Aktualisieren von 
Abhängigkeiten, etc. kümmern müssen. Voll automatisch. :)

Sven


On 19.04.2016 20:08, Arnold Krille wrote:
> Hi,
>
> ich hab zwar in Deiner Mail keine wirkliche Frage gelesen, will aber
> trotzdem mal antworten. Das wir Dein Problem verstanden haben (und auch
> selber vor dem Problem standen) erkennst Du daran, das wir Dir Lösungen
> präsentieren, die sich seit Jahren(!) täglich(!) bewähren (Continous
> halt:).
>
> Achja, wir haben auch nicht ein Produkt für N Kunden, sondern ein
> Produkt, das aus N Komponenten besteht.
>
> Neben den erwähnten Anhängigkeiten in Jenkins, die man mit dem
> richtigen Plugin dann auch schön als Pipelines betrachten kann, nutzen
> wir auch die zeitlichen Trigger von jenkins. Selbst wenn sich nichts
> ändert, wird einmal täglich das Gesamtprodukt gebaut und getestet.
>
> Ideal wäre dann noch (haben wir in dieser Firma nicht), wenn der
> jenkins für jeden erfolgreichen build/test Lauf ein tag in git pusht
> ("jenkins_build_ID_successful"). Und auf dem master-branch ein tag
> vorwärts bewegt um den letzten stabilen Build zu markieren. Damit kann
> man dann immer den stabilen Stand deployen…
>
> - Arnold
>
> On Tue, 19 Apr 2016 15:49:50 +0200 Thomas Güttler
> <guettliml at thomas-guettler.de> wrote:
>> Die meisten Texte über Continuous Integration machen es sich aus
>> meiner Sicht zu einfach.
>>
>> Beispiel: Gegen ist das git Repository foo. Wenn es Änderungen darin
>> gibt, dann werden alle Tests ausgeführt, wenn die erfolgreich sind,
>> dann wird die Versionsnummer von foo um eins erhöht.
>>
>> Obiges funktioniert sehr gut für Bibliotheken, aber nicht gut für ein
>> Projekt.
>>
>> Projekt
>> -------
>>
>> Für mich ist ein Projekt hauptsächlich Konfiguration. Es enthält so
>> wenig Quelltext wie möglich.
>>
>> Ein Projekt ist der firmenspezifische Einsatz eines Produkts. Es ist
>> eine Art Container mit Abhängigkeiten
>>
>>    Bsp: modwork_foo mit requirements.txt
>>
>> Produkt
>> -------
>>
>> Reales Beispiel: Wir haben die Produkte modarch (Archiv), modwork
>> (Workflow), modcs (SAP-Contentserver), ...
>>
>> Ein Produkt kann N optionale Plugins verwenden.
>>
>> Ein Produkt benötigt zwingend ein Projekt als Container.
>>
>> Continuous Integration auf Projektebene
>> ---------------------------------------
>>
>> Wenn in git-Repo "foo" Änderungen sind, dann starte die Test für
>> "foo".....
>>
>> Wie gesagt das klappt nicht für CI auf Projektebene. Das git-Repo des
>> Projekts ist super klein. Hier sind so gut wie nie Änderungen. Also
>> würde das CI nie gestartet werden.
>>
>> Ich will im CI also nicht prüfen ob das Produkt "modwork"
>> funktioniert, sondern ich will prüfen ob das firmenspezifische
>> Projekt "modwork_foo" funktioniert. Dafür ist aber Quelltext aus
>> vielen Repos nötig:
>>
>>    - modwork_foo
>>    - modwork
>>    - modwork_isu (optionales Plugin)
>>    - modtools (Bibliothek, die von N Produkten verwendet wird)
>>
>>
>> ... könnt ihr das Problem verstehen?
>>
>> Das ganze betrifft vermutlich nur Entwickler die ein Produkt für N
>> Firmen verwalten.
>>
>>
>> Gruß,
>>     Thomas
>>
>
>
> _______________________________________________
> python-de maillist  -  python-de at python.org
> https://mail.python.org/mailman/listinfo/python-de