Verzweigung unterbricht kontinuierliche Integration?

Ich denke, dieser Artikel, A Successful Git Branching Model , ist unter erfahrenen DVCS-Anwendern sehr bekannt.

Ich benutze hgmeistens, aber ich würde argumentieren, dass diese Diskussion für jedes DVCS in Ordnung ist.

Unser aktueller Workflow ist, dass jeder Entwickler das Master-Repo klont. Wir schreiben Code in unserem eigenen lokalen Repository, führen Tests durch und wenn alles gut geht, senden wir ihn an den Master.

Daher möchten wir CI-Server wie Jenkins einrichten und unseren Workflow mit dem zukünftigen Bereitstellungssystem (Chefkoch, Marionette, Ansible usw.) verbessern.

Realteil

Nun, das Modell oben präsentiert funktioniert gut, aber Zweige können CI brechen. Die Feature-Verzweigung sollte mit dem Ursprung synchronisiert werden (laut Artikel wäre es eine developmentVerzweigung), um CI und Zusammenführung reibungslos zu gestalten, oder?

Angenommen, Alice und Bob arbeiten an zwei Funktionen. Aber Alice ist am nächsten Tag fertig. Bobs Feature dauert eine Woche. Bis Bob fertig ist, sind seine Änderungen veraltet (vielleicht hat Alice einige Klassen überarbeitet / umbenannt).

Eine Lösung besteht darin, dass Entwickler jeden Morgen master/originprüfen müssen, ob Änderungen vorliegen . Wenn Alice sich dazu verpflichtet hat, sollte Bob auf seinen Arbeitsbereich zugreifen und diesen zusammenführen, damit sein Feature-Zweig auf dem neuesten Stand ist.

1. Ist das ein guter Weg?
2. Sollten diese Zweige im Master-Repo vorhanden sein (nicht im lokalen Klon?). Sollte jeder Entwickler das Privileg haben, das Master-Repo auf GitHub / Bitbucket zu verwenden, damit er einen neuen Zweig erstellen kann? Oder wird das vor Ort gemacht?
3. Schließlich sollte das in dem Artikel vorgestellte Modell das CI unterbrechen, wenn die Verzweigungen nicht mit dem CI synchronisiert sind origin/master. Sollen Entwickler, da wir nächtliche Builds durchführen möchten, vor dem Verlassen der Arbeit die Dateien ziehen und zusammenführen und CI auch für jeden Feature-Zweig ausführen?

Erstens sind die Verwendung von Feature-Zweigen (um die Arbeit an einem Feature zu isolieren) und von CI (um Integrationsprobleme zu finden, sobald sie festgeschrieben sind) leicht uneinheitlich.

Meiner Meinung nach ist das Ausführen von CI für Feature-Zweige Zeitverschwendung. Da Feature-Verzweigungen häufig wechseln, muss das CI-Tooling immer wieder neu konfiguriert werden. Und das für einen Zweig, der höchstwahrscheinlich nur Updates von einer oder zwei Quellen erhält, die ihre Eincheckvorgänge koordinieren, um die Probleme zu vermeiden, die ein CI-System erkennen soll.
Daher macht es auch keinen Sinn, die Feature-Zweige auf dem Master-Repository-Server zu haben.

Zu Frage 1 und 3: Es liegt in der Verantwortung des Entwicklers, sicherzustellen, dass der Build auf dem Hauptentwicklungszweig nicht unterbrochen wird, wenn er seinen Feature-Zweig in diesen Zweig einfügt. Wie sie das machen, ist ihr Problem, aber zwei Möglichkeiten sind:

• Änderungen, die am Hauptentwicklungszweig vorgenommen wurden, regelmäßig (z. B. täglich) in den Feature-Zweig ziehen
• Wenn das Feature fertig ist, führen Sie den Hauptentwicklungszweig in dem Feature-Zweig zusammen und verschieben Sie das Zusammenführungsergebnis in den Hauptentwicklungszweig.

In beiden Fällen werden die offensichtlichen Integrationsprobleme (z. B. umbenannte Klassen / Dateien) zuerst im Feature-Zweig gefunden und behoben. Die subtileren Probleme treten höchstwahrscheinlich nur auf, wenn der nächtliche Build ausgeführt wird, und sollten dort und dann behoben werden.

Als Antwort auf 1)

Jeder Weg, der funktioniert, ist ein guter Weg. Die Grundvoraussetzung für die kontinuierliche Integration ist jedoch die kontinuierliche Integration . Die Idee ist, Integrationsfehler nicht nur so früh wie möglich zu erkennen, sondern auch innerhalb des Entwicklungs-Feedback-Zyklus - dh während sich alle Details für den zu testenden Code im Kurzzeitgedächtnis des Entwicklers befinden, der die Änderungen vornimmt. Dies bedeutet, dass unter normalen, alltäglichen Umständen die Arbeit bei jedem Commit über die Feature-Zweige hinweg integriert werden muss - etwa alle 15 Minuten. Nochmals: Der Hauptzweck der kontinuierlichen Integration besteht darin, Integrationsfehler aufzudecken, während sich alle Details im Kurzzeitgedächtnis der Entwickler befinden, die die Änderungen vornehmen.

2)

Meist werden Zweige in Mercurial durch Klonen von Repositorys erstellt, sodass Sie nicht jedem Entwickler Commit-Berechtigungen für das Master-Repository erteilen müssen. Sie möchten Entwicklern jedoch wahrscheinlich die Möglichkeit geben, geklonte Repos auf dem Continuous Integration Server zu erstellen, da es nicht immer möglich ist, Tests lokal auszuführen. (Ich hatte einmal ein CI-System, bei dem die Unit-Tests auf einem 128-Core-Cluster 8 Stunden dauerten.) - Die Entwickler konnten natürlich keine Tests lokal ausführen.

3)

Wenn Sie über die Rechenressourcen dafür verfügen, sollten Entwickler zu jeder Zeit, insbesondere bevor sie die Arbeit verlassen, mit der Hauptentwicklungslinie auf dem neuesten Stand sein, und Sie sollten über Nacht Tests in allen Entwicklungslinien durchführen (obwohl die meisten CI - Systeme dies tun) mach es dir nicht leicht).

Das geht so: Verzweigen von Features.

1. Starten Sie für jede neue Aufgabe (Bugfix, Feature usw.) einen neuen Zweig (z. B. bugfix-ticket123-the_thingie_breaks).
2. Während Sie arbeiten, aktualisieren Sie fortlaufend Ihren Feature-Zweig und führen Sie ihn zusammen (oder führen Sie ihn in Git zusammen) . Auf diese Weise können Sie Ihren Zweig aktualisieren, ohne im Standardzweig arbeiten zu müssen
3. Wenn Ihre Funktion fertig ist und Ihre Komponententests bestanden wurden , ziehen Sie den Zweig erneut und führen Sie ihn zusammen, schließen Sie ihn und drücken Sie ihn, ohne ihn zusammenzuführen . Ihr Integrator wird den neuen Kopf bemerken und feststellen, dass es sich um einen geschlossenen Zweig handelt kümmert sich um die Integration. Wenn Sie keinen Integrator haben, wechseln Sie zum Standard und führen Sie Ihren Feature-Zweig zum Standard zusammen .

Wichtig hierbei ist, dass der Standardzweig 0 Konflikte enthält, wenn Sie den Feature-Zweig darin zusammenführen, und alle Ihre Tests erfolgreich sind .

Mit diesem einfachen Workflow verfügen Sie immer über einen makellosen und stabilen Standardzweig. Dies gilt nun auch für Release-Zweige, die Integration erfolgt jedoch standardmäßig . Wenn Sie Hotfixes direkt in die Versionszweige integrieren müssen, können Sie dies dennoch tun, indem Sie den Standardzweig überspringen. Sie können jedoch auch hier nur die Zweige auswählen, die gerade aus dem Zielzweig aktualisiert wurden und keine Konflikte aufweisen, und ihre Komponententests bestehen.