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

Path	csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From	"Martin A. Brown" <martin@linux-ip.net>
Newsgroups	de.comp.lang.python
Subject	Re: [Python-de] Continuous Integration: N git Repositories
Date	Thu, 21 Apr 2016 11:12:24 -0700
Lines	107
Message-ID	<mailman.24.1461262355.23626.python-de@python.org> (permalink)
References	<5716377E.6040007@thomas-guettler.de> <20160419200816.294685fd@xingu.arnoldarts.de> <57178937.1050900@thomas-guettler.de> <alpine.LSU.2.11.1604200705360.18407@znpeba.jbaqresebt.arg> <5718E5F5.4030600@thomas-guettler.de> <alpine.LSU.2.11.1604211030121.18407@znpeba.jbaqresebt.arg>
Mime-Version	1.0
Content-Type	text/plain; charset=ISO-8859-15
Content-Transfer-Encoding	8BIT
X-Trace	news.uni-berlin.de +0PKyK7LbsYxUg1XbWZG7wjd8AUZhY5D2WwlfU6QIgeA==
Return-Path	<martin@linux-ip.net>
X-Original-To	python-de@python.org
Delivered-To	python-de@mail.python.org
X-X-Sender	mabrown@macron.wonderfrog.net
In-Reply-To	<5718E5F5.4030600@thomas-guettler.de>
X-Content-Filtered-By	Mailman/MimeDel 2.1.22
X-BeenThere	python-de@python.org
X-Mailman-Version	2.1.22
Precedence	list
List-Id	Die Deutsche Python Mailingliste <python-de.python.org>
List-Unsubscribe	<https://mail.python.org/mailman/options/python-de>, <mailto:python-de-request@python.org?subject=unsubscribe>
List-Archive	<http://mail.python.org/pipermail/python-de/>
List-Post	<mailto:python-de@python.org>
List-Help	<mailto:python-de-request@python.org?subject=help>
List-Subscribe	<https://mail.python.org/mailman/listinfo/python-de>, <mailto:python-de-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID	<alpine.LSU.2.11.1604211030121.18407@znpeba.jbaqresebt.arg>
X-Mailman-Original-References	<5716377E.6040007@thomas-guettler.de> <20160419200816.294685fd@xingu.arnoldarts.de> <57178937.1050900@thomas-guettler.de> <alpine.LSU.2.11.1604200705360.18407@znpeba.jbaqresebt.arg> <5718E5F5.4030600@thomas-guettler.de>
Xref	csiph.com de.comp.lang.python:4421

Show key headers only | View raw

Hallo und Gruß,

> ich vermute, dass du auch auf die Liste schreiben wolltest, aber 
> die Default-Konfig der Mailingliste mal wieder zugeschlagen hat. 
> Per Default geht das Reply nicht auf die Liste. Ich verstehe 
> nicht, warum das der Default ist. So ist deine Mail nur bei mir 
> angekommen. Das Reply schicke ich auf die Liste - Ich hoffe das 
> ist ok.

Oof!  Natürlich wollte ich auf die Liste schreiben.  Danke, Thomas!

(Fast 20 Jahren mit Mailinglisten und ich mache immer noch denselben 
Fehler.)

> Das ist ok, ich kann englisch lesen.
>
> Zitat von deinem Link:
>
>> I identify the Open Build Service (OBS), as one of the good solutions for
> continuous build.
>
> Was ist "continuous build"? Ich konnte dazu keine Definition im Netz finden.

Huh--eine Ûberraschung.  Siehe unten.

>> Und, jetzt, weiter auf Deine Frage.  Die Idee daß Du vorgeschlagen
>> hast, Thomas, scheint mir ganz nah an den Stärken des OBS.
>>
>> Jetzt versuche ich zu beschrieben wie ich dieses Problem mit OBS
>> lösen würde.
>>
>> Ausgangspunkt:  5 Kunden, jeder hat seine eigene Infrastruktur.
>>                 100 Paketen (mehr oder weniger)
>>                 Entwicklungshaus, einige Mitarbeiter.
>>                 Jenkins als CI server (jetzt auch mit 'artifacts')
>>
>> Was würde ich tun?  OBS hinzufügen.
>>
>> Wenn jedes Stück Software wirklich open source ist und nichts
>> geschützt werden muß, dann startete ich einfach mit dem öffentlichem
>> OBS.
>>
>>   * Für jede Kunde, würde ich ein OBS Projekt machen.
>>   * Unterstützten Platformmen in 'prjconf' einschalten.  z.B.
>>     für Kunde A, CentOS-7.1-x86_64, für Kunde B,
>>     OpenSUSE-13.2-x86_64
>>   * Ein einziges Paket [0] in das Projekt aufladen und sichern daß
>>     das OBS gute RPMs baut
>>   * Alle anderen Paketen aufladen und sichern daß alles gut läuft.
>>
>> Wenn die Software proprietär ist, dann kann man das OBS selbst
>> installieren (es gibt auch Appliance und VM).  Dieselbe Strategie
>> kann man folgen, aber man muß zuerst das ganze OBS mit den
>> gewünschten Distributions ausstatten.  Dann kann man ein Projekt pro
>> Kunde und so weiter machen.
>
> Ich würde die self-hosting Variante nehmen.

Ich auch.

>> Hoffentlich ist meine Antwort hilfreich,
>
> Ja es war hilfreich. Ich weiß nun, dass ich nicht alleine mit 
> meinem Anliegen bin.
>
> Eine Frage bleibt: Was ist Continous Build? Hast du den Begriff 
> "erfunden", oder von wo ist der?

Ich kann auch keine Definition finden, aber bei einer früheren Firma 
haben wir immer diesen Begriff benutzt.  Vermutlich haben wir es 
erfunden, aber meistens benutze ich nur übliche Begriffe.

Jedenfalls ist die Hauptsache die Anwendung von diesem immer 
vorhanden 'continuous' auf eine 'reproducible build'.  Daher, auch 
wenn es frei erfunden ist, 'continuous build'.  Vielleicht hätte ich 
'continuous delivery' in dem Text schreiben sollen.

> Welche Beugung?

(Ich meine nur daß ich oft Probleme mit den Beugungen von Adjektiven 
habe.)

> Wir gehen derzeit genau den anderen Weg: Wir setzen voll auf 
> virtualenv. Das hat den Vorteil das wir zig virtualenvs auf einer 
> Maschine laufen lassen können.

Natürlich!  Und, eine gute Lösung.

> Prinzipiell fasziniert mich der Begriff "immutable container".
>
> Ich stelle mir das so vor: Es wird ein Container gebaut, und 
> getestet. Wenn alle Tests ok sind, dann löst der neue Container 
> der alten ab. Dafür ist eine glasklare Trennung von Code und Daten 
> nötig, die bei uns im Moment noch nicht gegeben ist.

Man sieht jetzt dieses Wort 'immutable'...  Ich verstehe auch den 
gängigen Gebrauch von dem Container als API, genau wie Du 
beschreibst (habe aber noch keine Erfahrung damit).

Gruß,

-Martin

-- 
Martin A. Brown
http://linux-ip.net/

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

Thread

Re: [Python-de] Continuous Integration: N git Repositories "Martin A. Brown" <martin@linux-ip.net> - 2016-04-21 11:12 -0700

csiph-web