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

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

Re: [Python-de] Continuous Integration: N git Repositories

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

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@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
> 

Back to de.comp.lang.python | Previous | Next | Find similar

Thread

Re: [Python-de] Continuous Integration: N git Repositories Arnold Krille <arnold@arnoldarts.de> - 2016-04-19 20:08 +0200

csiph-web