Verhindern DVCSs eine kontinuierliche Integration?

34

Angenommen, es gibt ein Team von zehn agilen Entwicklern. Jeden Tag wählen sie eine Aufgabe aus dem Forum aus und schreiben mehrere Änderungen daran fest, bis (am Ende des Tages) sie die Aufgabe erledigt haben. Alle Entwickler checken direkt gegen Trunk ein (im Google-Stil ist jedes Commit ein Release-Kandidat, verwendet Feature-Toggles usw.).

Wenn sie ein zentrales CVS wie SVN verwenden, integriert und testet der Build-Server ihre Änderungen bei jedem Commit der anderen neun Entwickler. Der Build-Server wird fast den ganzen Tag ununterbrochen laufen.

Wenn Sie jedoch ein DCVS-ähnliches Git verwenden, kann der Entwickler warten, bis Sie die Aufgabe abgeschlossen haben, bevor Sie alle lokalen Commits zusammen in das zentrale Repository übertragen. Ihre Änderungen werden erst am Ende des Tages integriert.

In diesem Szenario integriert sich das SVN-Team kontinuierlich häufiger und entdeckt Integrationsprobleme viel schneller als das Git-Team.

Bedeutet dies, dass DVCS für fortlaufende Teams weniger geeignet sind als ältere zentralisierte Tools? Wie kommt ihr um dieses Problem mit verzögertem Push herum?

Richard Dingwall
quelle
15
Werden sich die Leute mindestens einmal verpflichten, bevor sie die Aufgabe erledigen, wenn sie SVN verwenden? Und werden die Leute nur einmal am Tag pushen, wenn sie ein DVCS benutzen? Ihre Argumentation geht davon aus, dass beides nicht zutrifft, aber mein Eindruck deutet auf etwas anderes hin.
3
Sehr gute frage
Michael Brown
1
@delnan: Nehmen wir an, beide Teams verpflichten sich mehrmals am Tag, aber die Jungs von der GIT bringen diese Verpflichtungen erst zusammen, wenn die Aufgabe erledigt ist.
Richard Dingwall
2
Ich denke, Sie schauen auf das falsche Ende der Pipe, Sie bekommen Probleme, nicht wenn Sie nicht bis zum Ende drücken, sondern wenn Sie während der Entwicklung nicht regelmäßig ziehen
jk.
2
Ich habe das Gegenteil gesehen: Entwickler, die ein zentrales Quellcodeverwaltungssystem wie TFS verwenden, führen selten Commit-Vorgänge durch, da sich ihr Code dabei auf alle auswirkt. Sie retten ihre Arbeit vorübergehend in Monsterregalen, und wenn sie fertig sind, wird alles in einem Monster-Commit erledigt.
Kyralessa

Antworten:

26

Haftungsausschluss: Ich arbeite für Atlassian

DVCS entmutigt die kontinuierliche Integration nicht, solange der Entwickler regelmäßig Remotezugriffe auf seine eigene Niederlassung durchführt und der CI-Server so eingerichtet ist, dass er die bekannten aktiven Niederlassungen erstellt.

Traditionell gibt es zwei Probleme mit DVCS und CI:

  • Unsicherheit des Integrationsstatus - Wenn der Entwickler nicht regelmäßig eine Zusammenführung von Master und Build durchführt, wissen Sie nicht, wie der Status der kombinierten Änderungen lautet. Wenn der Entwickler dies manuell ausführen muss, wird dies wahrscheinlich nicht oft genug durchgeführt, um Probleme früh genug zu erkennen.
  • Duplizieren und Verschieben der Build-Konfiguration - Wenn die Build-Konfiguration von einem 'Master'-Build kopiert werden muss, um einen Zweig-Build zu erstellen, kann die Konfiguration für den Zweig schnell nicht mehr mit dem Build synchronisiert werden, von dem er kopiert wurde.

In Bamboo haben wir die Möglichkeit eingeführt, dass der Build-Server neue Zweige erkennt, wenn sie von Entwicklern erstellt werden, und Builds für den Zweig automatisch basierend auf der Build-Konfiguration für Master einrichtet die Veränderung widerspiegeln).

Wir haben auch eine Funktion namens Merge Strategies, mit der Sie entweder die Verzweigung mit Änderungen vom Master aktualisieren können, bevor die Verzweigungserstellung ausgeführt wird, oder die Änderungen in einer erfolgreichen Erstellungsverzweigung automatisch zum Master übertragen können, um sicherzustellen, dass Änderungen zwischen Verzweigungen so schnell wie möglich gemeinsam getestet werden .

Wenn Sie mehr darüber erfahren möchten, lesen Sie auf jeden Fall meinen Blog-Beitrag "Feature-Verzweigungen durch kontinuierliche Integration effektiv machen".

jdumay
quelle
14

Mein kleines Team wechselte vor ein oder zwei Jahren zu einem DVCS, und der Rest meiner Firma folgte vor ein paar Monaten. Durch meine Erfahrung:

  • Leute, die ein zentrales VCS verwenden, neigen immer noch dazu, Commits zurückzuhalten, wenn sie ein großes Projekt durchführen. Dies ist kein DVCS-spezifisches Problem. Sie haben Änderungssätze, die mehrere Tage warten, bevor sie ein Commit ausführen. Der große Unterschied besteht darin, dass die Behebung eines Fehlers oder eines Absturzes des Computers erheblich mehr Aufwand erfordert.
  • Wir verwenden einen Festschreibungsworkflow, bei dem jeder Entwickler an seinem eigenen Zweig arbeitet und nur die Person, die ihren Code überprüft hat, ihre Änderungen in den Kopf einbinden darf. Dadurch wird die Wahrscheinlichkeit verringert, dass ein Commit Probleme verursacht, sodass die Benutzer wirklich darauf achten, wenn der Build-Server eine Fehlermeldung ausgibt. Das bedeutet auch, dass andere Entwickler weiter an ihren eigenen Filialen arbeiten können, bis der Kopf repariert ist.
  • Bei einem DVCS verbringen die Benutzer in der Regel mehr Zeit mit dem Programmieren, bevor sie ihren Code mit dem Kopf zusammenführen. Daher führt dies tendenziell zu einer geringfügigen Verzögerung der Kontinuität des Builds. Der Unterschied ist jedoch nicht signifikant genug, um den Vorteilen des DVCS entgegenzuwirken.
StriplingWarrior
quelle
Der Build-Server erstellt alle benannten Zweige, sodass jeder Committer seinen eigenen Build-Server-Job hat.
Wird der Code-Prüfer in diesem Szenario nicht zu einem ernsthaften Engpass?
Andres F.
@ ThorbjørnRavnAndersen: Nein, der Build-Server erstellt nur den "head" - oder "default" -Zweig und die Release-Zweige. So kann sich jeder Benutzer auf seinen eigenen Zweig festlegen, ohne befürchten zu müssen, dass der Build unterbrochen wird. Es ist denkbar, dass wir einen Build-Server einrichten, um die Filialen aller zu erstellen, aber in einigen Fällen möchte ich einige meiner Arbeiten ausführen, da ich genau weiß, dass meine eigene Filiale dadurch unbrauchbar wird. Ich stelle sicher, dass mein Zweig stabil ist, bevor ich eine Codeüberprüfung durchführe und zusammenführe. Es ist mir nur wichtig, dass die Hauptzweige, die alle anderen verwenden, stabil sind.
StriplingWarrior
@AndresF .: Nein, es ist für uns kein ernsthafter Engpass geworden. Zum einen haben wir mehrere Personen, die Code-Überprüfungen durchführen können, sodass jeder Entwickler in der Regel mindestens einen Prüfer finden kann, der zu einem bestimmten Zeitpunkt für eine Überprüfung zur Verfügung steht. Das Schöne an einem DVCS ist auch, dass Sie, selbst wenn Sie nicht sofort zusammenführen können, mit der Arbeit an etwas anderem beginnen können und andere Entwickler Ihre Änderungen in ihren Zweigen zusammenführen können, wenn diese von Ihren Änderungen für ihre Arbeit abhängen. Sobald Ihr Code überprüft wurde, gibt es einen bestimmten Änderungssatzknoten, in den der Überprüfer einbinden kann.
StriplingWarrior
13

Ich habe kürzlich bei ungefähr 19 Projekten beobachtet, die Mercurial über SubVersion verwendeten (ich war ein Subversion-Freak ): Entwickler wurden zu echten Individualisten, indem sie an ihrer eigenen Branche arbeiteten und sich erst nach mehreren Tagen oder Wochen integrierten. Dies verursachte ernsthafte Integrationsprobleme und -bedenken.

Ein weiteres Problem ist der Continuous Integration Server. Probleme (z. B. fehlgeschlagener Test) wurden nur dann gemeldet, wenn die Synchronisierung der Commits mit dem Server durchgeführt wurde.

Es scheint , dass Martin Fowler über sie schrieb auf seiner Website.

Das heißt, einige der Projekte, die ich erwähne, haben mindestens einmal am Tag eine Synchronisierung durchgeführt, um die Probleme zu reduzieren. So Ihre Frage zu beantworten, ich glaube , dass DVCS kann die kontinuierliche Integration entmutigen und Individualismus erhöhen. DVCS ist jedoch nicht die direkte Ursache.

Der Entwickler ist weiterhin für das von ihm verwendete VCS verantwortlich.

Gemeinschaft
quelle
Haben besagte Projekte ein gemeinsames Ziel betont oder mussten die Entwickler an bestimmten, nicht zusammenhängenden Zielen arbeiten?
Wir können nicht auf 19 Projekte verallgemeinern. Als wir jedoch mit Integrationsproblemen konfrontiert waren, lag dies auch daran, dass einige Grundsätze wie die Trennung von Interessen nicht eingehalten wurden. Was ich sage, ist, dass DVCS den Individualismus fördert und die Vorteile einer kontinuierlichen Integration verringert. Wenn die Entwickler jedoch gut geschult sind, kann das Problem verringert oder beseitigt werden.
In diesem Fall würde ich vorschlagen, dass Sie auch fortlaufende Lieferungen oder zumindest häufige Kundenlieferungen durchführen, sodass die Frist für die Zusammenführung viel kürzer ist. Hast du das in diesen Projekten gemacht?
Natürlich benutzen wir Scrum
1
Ich habe nach Ihrer Definition für kontinuierliche Zustellung gesucht (kann immer noch nichts Anständiges finden, ich würde mich
10

Die Idee, auf die Sie Ihre Argumentation stützen, ist, leise ausgedrückt, sehr wackelig. Es ist Sache des Teams / Managements / Prozesses, dass der Entwickler warten kann, bis er die Aufgabe erledigt hat .

Wenn Sie dies auf die eine oder andere Weise tun, "warten" oder "sich beeilen", gemeinsam genutzte Amtsleitung oder isolierte Zweigstelle, wird dies als Verzweigungsstrategie bezeichnet. Wenn Sie online verfügbare Informationen studieren , werden Sie feststellen, dass die Auswahl einer bestimmten Strategie im Grunde nichts damit zu tun hat VCS wird zentralisiert oder verteilt.

Angenommen, für verteilte VCS wie Mercurial finden Sie leicht gute Empfehlungen für häufige Zusammenführungen :

Erstens oft zusammenführen! Dies erleichtert das Zusammenführen für alle und Sie können Konflikte (die häufig auf inkompatiblen Entwurfsentscheidungen beruhen) früher erkennen ...

Wenn man Empfehlungen wie oben studiert, kann man leicht herausfinden, dass diese Überlegungen ansprechen, die nichts mit der Verbreitung von Mercurial zu tun haben.

Betrachten wir nun die Situation auf der Seite des zentralisierten VSC Subversion. Wenn man Online-Informationen studiert, findet man unter den beliebtesten Strategien einen so genannten stabilen und einen instabilen Stamm , die sich gegensätzlich auf die Häufigkeit der Zusammenführungen auswirken. Sie sehen, die Leute wählen die eine oder andere Art, Dinge zu tun, ohne auch nur darauf zu achten, dass VCS zentralisiert ist.

  • Ich habe stark verzögerte Zusammenführungen mit zentralem VCS gesehen (sogar durch Lame-Management gefördert), sowie häufige Zusammenführungen mit DVCS, wenn Team / Management einfach dachten, dass dies der richtige Weg ist. Ich habe gesehen, dass es niemanden interessiert, ob VCS auf die eine oder andere Weise verteilt oder zentralisiert ist.

Angesichts der obigen Ausführungen scheint es die richtige Antwort auf die Frage zu sein, ob DVCS die kontinuierliche Integration behindert. wäre Mu .

Das Verteilen oder Nichtverteilen von VCS hat keinen wesentlichen Einfluss darauf.

Mücke
quelle
1
+1 Ich stimme Ihnen zu, dass das Management der Schlüssel zur Lösung des Problems ist. Allerdings müssen wir zugeben , dass es etwas in DVCS , die kontinuierliche Integration schreckt. Tatsächlich fördert eines der Hauptmerkmale von DCVS dieses Verhalten.
1
@ Pierre303 vielleicht - irgendwie fühle ich mich auch so, aber das ist so ziemlich eine Theorie. Wie ich schrieb, habe ich gesehen, wie sich das Team wie verrückt in DVCS integriert hat, und andererseits war das "isolierteste" Projekt, in dem ich jemals gearbeitet habe (und das war ein Albtraum), das zentralisierte VCS. So viel für die Gefühle, so viel für die Theorie ...
gnat
Ich gebe zu, das ist nur eine empirische Beobachtung, aber es gibt eine große Anzahl von Projekten, und es ist wahrscheinlich eine große Tendenz in Bezug auf "Fähigkeiten" involviert.
10

Meine Erfahrung ist genau das Gegenteil , Teams, die svn verwenden, würden tagelang nicht pushen, da der Code, an dem sie arbeiten, dazu führen würde, dass der Trunk nicht für alle anderen kompiliert wird , ohne Zeit für das manuelle Zusammenführen zu verschwenden. Gegen Ende des Sprints würden sich dann alle verpflichten, der Wahnsinn würde verschmelzen, die Dinge würden überschrieben und verloren und müssten geborgen werden. Das CI-System würde sich ROT färben und die Finger zeigen.

Hatte noch nie dieses Problem mit Git / Gitorious.

Mit Git können Sie nach Belieben Änderungen anderer Personen abrufen und zusammenführen, nicht weil jemand anderes etwas überprüft hat und Sie einchecken möchten, aber Sie müssen 20 Minuten manuell zusammenführen.

Mit Git können Sie auch die Commits aller anderen abrufen, Ihren Code einbinden und dann eine funktionierende Version an alle anderen weitergeben, damit sie nicht erraten müssen, was sie aufgrund der von Ihnen vorgenommenen Änderungen zusammenführen müssen.

Etwas wie Gitorious als Vermittler für Codeüberprüfungen über Zusammenführungsanforderungen zu haben, macht das Verwalten vieler Filialen und vieler Mitwirkender sehr schmerzlos.

Das Einrichten von Jenkins / Hudson zum Verfolgen aller aktiven Zweige in einem Git-Repository ist ebenfalls sehr einfach. Wir haben mit CI mehr Traktion und häufigeres Feedback über den Status der Repositorys erhalten, als wir von SVN zu Git gewechselt sind.


quelle
warum sollten sie sich direkt an trunk binden? Ich denke das war dein Problem.
gbjbaanb
1
@gbjbaanb, weil dies die traditionelle idiomatische CVS-Arbeitsweise ist, weil dies die traditionelle zentralisierte Repo-Sprache ist. SVN-Benutzer sind normalerweise ehemalige CVS-Benutzer, und das Verzweigen und Zusammenführen in SVN ist nur unwesentlich besser als in CVS. das war jenseits von schmerzhaft / fast unmöglich zu korrigieren. Dies ist der 99% -Workflow-Fall in 99% aller SVN-Shops, da die Tools und die Gruppe denken.
@ JarrodRoberson: Quatsch. Meine alten SVN-Benutzer waren Flüchtlinge von VSS :) Das Zusammenführen von SVN ist bei weitem nicht so schlimm, wie Sie denken. In diesem Fall beschwert er sich, dass seine Benutzer den Build abbrechen würden, indem sie defekten Code direkt in den Trunk einchecken - und dann, offen gesagt, den Code mit dem Ihres Kollegen zusammenführen müssen, ist keine optionale Sache, wenn Sie alle direkt daran arbeiten der gleiche Zweig.
gbjbaanb
4

Build-Server sind billig. Lassen Sie einfach Ihren CI-Server alle Zweigstellen abholen, die Sie kennen.

Jenkins hat Unterstützung, um mehrere Git-Repositories zu überprüfen und die 'neuesten' von denen in einem einzelnen Job zu erhalten. Ich bin sicher, dass es ähnliche Lösungen für andere Tools gibt.

ptyx
quelle
Und was passiert, wenn Sie etwas begehen möchten, das nicht funktioniert, headaber einem Kollegen hilft oder erforderlich ist, damit ein Kollege Ihnen helfen kann? Sie könnten ein Diff erstellen und dies per E-Mail an Ihren Kollegen senden, aber irgendwie fühlt sich das nicht richtig an.
Arjan
1
Team- / Feature-Zweig? Oder direkt aus dem Repository Ihres Kollegen ziehen? Wenn mehr als eine Person an etwas arbeitet, das den Kopf zerbrechen würde, aber dennoch eine Zeitachse / ein mehrstufiges Festschreiben erfordert, verdient es trotzdem seinen Zweig für Funktionen / Arbeiten. Zusammenführen, wenn es fertig ist.
Ptyx
Ein Teamzweig eines Feature-Zweigs funktioniert nicht, wenn Ihr CI-Tool alle Ihnen bekannten Zweige aufnimmt. Und wenn Ihr CI-Tool auch mehrere Repositorys verarbeitet, möchten Sie Entwickler-Repositorys trotzdem nicht einbeziehen, nur weil sie möglicherweise nicht vollständig getestet wurden.
Arjan
1
Dem CI-Server wird eine private Zweigstelle erst dann automatisch bekannt, wenn er darüber informiert wird. Es liegt an den Einzelpersonen zu entscheiden, ob sie ihre Filialen auf CI stellen möchten oder nicht. (Es gibt keine
Wunderlösung
Daher sollte CI nicht alle Branchen abrufen, die Sie kennen, sondern nur die, die Sie in CI benötigen. Für mich ist das ein Unterschied. Trotzdem glaube ich zu verstehen, was Sie sagen wollen, also +1
Arjan
4

Diese alte Frage wurde nur als Duplikat einer neuen Frage markiert, und da viele Antworten auf veraltete Ideen verweisen, dachte ich, ich würde eine aktualisierte Frage posten.

Eine Sache, die vor fünf Jahren anscheinend nicht sehr verbreitet war, war das Ausführen von CI-Tests für Pull-Request-Zweige, bevor diese in Master zusammengeführt wurden. Ich denke, dies spiegelt eine sich ändernde Haltung wider, die, obwohl ein häufiges Zusammenführen wünschenswert ist, nicht optimal ist, jede Änderung mit allen zu teilen , sobald Sie sie vornehmen .

DVCS hat eine hierarchischere Art der Integration Ihrer Commits hervorgebracht. Zum Beispiel arbeite ich oft sehr eng mit dem Entwickler zusammen, der neben mir sitzt. Wir werden mehrmals am Tag aus den Zweigen des anderen ziehen. Heute haben wir mit einem anderen Entwickler über Änderungen zusammengearbeitet, die alle paar Stunden auf eine Pull-Anfrage verschoben wurden.

Wir haben umfangreiche Änderungen an den Build-Skripten vorgenommen. Jenkins führt jede PR-Niederlassung lokal mit dem Master zusammen und führt Tests durch. Auf diese Weise erhielten wir automatisiertes Feedback, ohne andere Entwickler zu stören, die einen sauberen Build benötigten. Es wird wahrscheinlich einen weiteren Tag oder so dauern, bis PR zusammengeführt werden kann, um es außerhalb unserer Gruppe von drei Entwicklern zu meistern und weiterzugeben.

Wenn jedoch jemand nicht darauf warten kann, dass unsere Änderungen zum Master zusammengeführt werden, da ihre Änderung von unserer abhängig ist, kann er unseren Entwicklungszweig lokal zusammenführen und seine Arbeit fortsetzen. Dies ist, was viele Leute, die an CVCS gewöhnt sind, vermissen. Mit CVCS können Sie Ihre Änderungen nur gemeinsam nutzen, indem Sie sie in das zentrale Repository einfügen. Daher ist das Zusammenführen häufig kritischer. Mit DVCS haben Sie andere Möglichkeiten.

Karl Bielefeldt
quelle
3

Ich würde sagen, das DVCS fördert die kontinuierliche Integration. Verschmelzungen sind bei ihnen nicht so ärgerlich. Es erfordert jedoch mehr Disziplin. Sie sollten einem lokalen Commit mit einem Pull von der Basis zum Zusammenführen folgen und dann einen Push ausführen, wenn Ihre Aufgabe abgeschlossen ist (bevor Sie zur nächsten übergehen).

Michael Brown
quelle
2

Als mein Team zu Git wechselte, legten wir unseren Prozess explizit so fest, dass ein Push im älteren VCS genau wie ein Commit behandelt werden sollte und lokale Commits so häufig / selten durchgeführt werden konnten, wie es jeder Einzelne wollte. Damit gibt es keinen Unterschied zum CI-System, ob wir ein DVCS oder ein zentrales VCS verwenden.

Dan Lyons
quelle
1

Die Antwort lautet sowohl Ja als auch Nein.

Der Unterschied besteht darin, dass Sie das zentrale CI-Repo direkt übernehmen und Ihre Änderungen in das zentrale CI-Repo übernehmen. Das "Problem", das Sie möglicherweise finden, ist, dass DVCS-Benutzer diesen Push möglicherweise nicht regelmäßig ausführen.

Ich würde sagen, dies ist eine inhärente Konstruktionsfunktion eines DVCS. Sie ist nicht dafür ausgelegt, Ihre Änderungen ständig auf den zentralen Server zu übertragen. Wenn dies der Fall wäre, könnten Sie stattdessen auch ein CVCS verwenden. Die Antwort ist also, einen besseren Workflow unter Ihren Entwicklern durchzusetzen. Sagen Sie ihnen, sie sollen jede Nacht Änderungen vornehmen. Simples!

(Und wenn Ihre SVN-Benutzer nicht jede Nacht einen Commit durchführen, teilen Sie ihnen dies mit - es ist genau dasselbe Problem).

gbjbaanb
quelle
0

Git verhindert nicht die kontinuierliche Integration. Ihr stammbasierter Workflow ist.

Das hört sich vielleicht nicht intuitiv an, aber: Wenn die Entwickler an Feature-Zweigen arbeiten, können sie aufgefordert werden, diese häufig auf ihren eigenen Computern zu integrieren (und müssen dies tun, bevor sie ihr Feature zum Zusammenführen einreichen). Ein trunkbasierter Workflow hingegen begünstigt größere Commits und damit eine seltenere Integration.

Ich behaupte, dass ein stammbasierter Workflow im Google-Stil mit einem VCS wie Git, bei dem das Zusammenführen einfach ist, kontraproduktiv ist. Folgendes würde ich stattdessen empfehlen:

  • Brechen Sie die Funktionen so klein auf, dass für die Entwicklung keiner mehr als ein oder zwei Tage benötigt.
  • Jedes Feature wird in einer privaten Filiale entwickelt.
  • Entwickler integriert häufig auf privaten Zweig ( git fetch origin; git merge master). Normalerweise mache ich das mehrmals am Tag, wenn ich so arbeite.
  • Wenn der Entwickler einen Zweig zur Zusammenführung und Überprüfung einreicht, führt der CI-Server eine automatische Erstellung durch. Das Zusammenführen erfolgt nur, wenn dies erfolgreich ist.

Da haben Sie es also: kleine Commits, häufige Integration und eine nachvollziehbare Historie, welche Commits zu welchem ​​Feature gehörten. Ordnungsgemäß verwendete Zweige sind der Schlüssel zu allem, was sich bei Git lohnt. Daher ist es ein großer Fehler, sie zu vermeiden.

Marnen Laibow-Koser
quelle
-1

Es gibt großartige technische Lösungen wie @jdunay, aber für uns ist es ein Problem der Menschen - genauso wie es ein Problem der Menschen ist, ein Umfeld zu fördern, in dem sich die Menschen häufig für SVN engagieren.

Was für uns funktioniert hat, ist: (Ersetze 'master' durch den momentan aktiven Entwicklerzweig)

  1. Häufige Merges / Rebases vom Master
  2. Häufig genug drückt, um zu meistern
  3. Bewusstsein für Dinge, die die Hölle verschmelzen lassen, wie zum Beispiel bestimmte Umgestaltungen, und Milderung durch Kommunikation. Beispielsweise:

    • Stellen Sie sicher, dass alle vor dem Mittagessen pushen
    • Führen Sie das Refactoring während des Mittagessens durch und beschleunigen Sie es
    • Stellen Sie sicher, dass alle nach dem Mittagessen ziehen
Orip
quelle