Verhindern DVCSs eine kontinuierliche Integration?

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?

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".

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.

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.

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.

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.

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.

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.

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).

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.

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).

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.

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