Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.python > #4412
| Path | csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail |
|---|---|
| From | Thomas Güttler <guettliml@thomas-guettler.de> |
| Newsgroups | de.comp.lang.python |
| Subject | [Python-de] Continuous Integration: N git Repositories |
| Date | Tue, 19 Apr 2016 15:49:50 +0200 |
| Lines | 54 |
| Message-ID | <mailman.15.1461073798.30862.python-de@python.org> (permalink) |
| References | <5716377E.6040007@thomas-guettler.de> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=utf-8; format=flowed |
| Content-Transfer-Encoding | 8bit |
| X-Trace | news.uni-berlin.de lj1lZJ1ZmkNQMeYhCdH1XApbKBReK/z+rJUZqXJ+UKCg== |
| Return-Path | <guettliml@thomas-guettler.de> |
| X-Original-To | python-de@python.org |
| Delivered-To | python-de@mail.python.org |
| User-Agent | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
| 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 | <5716377E.6040007@thomas-guettler.de> |
| Xref | csiph.com de.comp.lang.python:4412 |
Show key headers only | View raw
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 -- Thomas Guettler http://www.thomas-guettler.de/
Back to de.comp.lang.python | Previous | Next | Find similar
[Python-de] Continuous Integration: N git Repositories Thomas Güttler <guettliml@thomas-guettler.de> - 2016-04-19 15:49 +0200
csiph-web