Sollte der Entwickler warten, bis die CI-Pipeline abgeschlossen ist, oder die nächste Aufgabe nach dem Drücken starten?

8

Mein Unternehmen integriert CI / CD. Bisher haben wir CI nach meinem Verständnis implementiert. Derzeit wird die CI-Pipeline ausgeführt, wenn ein Entwickler Code in unser Git-Repo überträgt.

Derzeit umfasst unsere CI-Pipeline die Erstellung des Projekts und die statische Code-Analyse, um sicherzustellen, dass es unseren Codierungsstandards entspricht. Wir werden als nächstes Tests implementieren. Die Erstellung und statische Code-Analyse dauert derzeit ca. 3 Minuten. Nach dem, was ich gelesen habe, ist die sofortige Behebung von Problemen für CI / CD von entscheidender Bedeutung. Ich gehe davon aus, dass der Betrieb der Pipeline etwa 10 Minuten dauern kann, wenn wir Unit-Tests hinzufügen.

Meine Frage ist also, wann ein Entwickler eine Pull / Merge-Anfrage stellt, sollte er warten, bis die CI-Pipeline abgeschlossen ist, oder einfach mit der nächsten Aufgabe fortfahren und zurückkehren, um Pipeline-Probleme zu beheben, falls vorhanden? Oder sollten sie sitzen und zusehen, wie die Pipeline läuft?

continuous-integration git continuous-delivery

— iqueqiorio
quelle

7

Sitzen und die Pipeline laufen sehen?

Nein, so arbeiten Sie nicht effizient.

Entwickler senden ihre Commits an das Quellcodeverwaltungs-Repository, und dann wird die CI / CD-Pipeline ausgelöst.

Entwickler können jederzeit eine gut geschriebene Pull-Anfrage stellen. Normalerweise gibt es eine visuelle Markierung, die einen "laufenden Build" / "fehlgeschlagenen Build" / "erfolgreichen Build" darstellt.

In der Regel kann ein Brach zusammengeführt werden, wenn alle diese Kriterien erfüllt sind:

Mindestens ein Genehmiger / oder so viele, die zur Genehmigung erforderlich sind, haben genehmigt.
ein "erfolgreicher Build"
Keine ungelösten Zusammenführungskonflikte

Wenn eines dieser Kriterien nicht erfüllt ist, müssen sie behoben werden. Der Entwickler tut dies jedoch immer dann, wenn er Zeit oder Priorität hat, um diese Aufgabe auszuführen.

— Jonas
quelle

2

Gute Antwort. Vielen Menschen ist nicht bewusst, dass Sie mit GitHub SaaS Circle-CI oder ein anderes CI die vorgeschlagenen Änderungen in einer Pull-Anforderung erstellen lassen können, bevor die Änderung zusammengeführt wird. Ich habe gesehen, dass GitHub Enterprise On-Prem verwendet wird, ohne dass diese Funktion verwendet wird: Die On-Prem-Jenkins-Farm wird nur ausgeführt, wenn Sie die PR zusammenführen, die möglicherweise fehlerhaft ist, es sei denn, der Entwickler hat eine vollständige Zusammenführung und Erstellung durchgeführt. Das macht das Leben dann viel komplexer. Vor Jahren haben Sie mit teamcity einen ci-Build auf einer Farm erstellt, bevor Sie sich überhaupt dazu verpflichtet haben, das Brechen eines Zweigs zu verhindern. Erst wenn das Problem veröffentlicht wurde, ist es eine alte Arbeitsweise.

— simbo1905

@ simbo1905 alles gut, außer dass die PR-Überprüfung nicht 100% effektiv ist, es sei denn, sie ist vollständig serialisiert. Überlappende PRs bedeuten, dass sich die jeweiligen Änderungen nicht gegenseitig berücksichtigen und sich gegenseitig stören können, was zu einem Bruch führt, wenn sie im Integrationszweig landen. Auch wenn sie keine Zusammenführungskonflikte haben oder dieselben Dateien berühren, sind Funktionskonflikte weiterhin möglich.

— Dan Cornilescu

@DanCornilescu Vereinbarte PRs können unabhängige Builds übergeben, aber Konflikte verursachen. Man benennt eine Methode um, man fügt Code hinzu, der den alten Methodennamen verwendet. Beide PRs bestehen Builds parallel. Wenn sowohl genehmigt als auch zusammengeführt, wird der Code nicht kompiliert. Große Projekte verwenden einen Merge-Bot wie bors-ng. Der Rezensent führt es nicht zusammen, er fordert den Bot auf, es zu versuchen. Der Bot führt serielle Fusionen erst nach einem neuen Build durch, bei dem er das kombiniert hat, was sich in seiner Zusammenführungswarteschlange befindet. In unserem Beispiel wird ein zusammengeführter Build der kombinierten PRs versucht. Es schlägt fehl, also versuchen Sie nur das erste, das zu seiner Warteschlange hinzugefügt wurde, erfolgreich zu sein, zusammenzuführen, dann das andere zu erstellen und abzulehnen.

— Simbo1905

1

Ich empfehle, Ihr Bestes zu geben, um sicherzustellen, dass die Pipeline weniger als 10 Minuten dauert. Sie können Ihre Tests parallel ausführen, um dies zu ermöglichen. Wie Jonas antwortete, können sie Zeit damit verbringen, eine Pull-Anfrage zu erstellen (während die Pipeline läuft).

Das Wechseln des Kontexts ist schlecht für die Produktivität. Ich empfehle dem Entwickler, diese Zeit zu nutzen, um an anderen Dingen zu arbeiten, die mit der gerade vorgenommenen Änderung zusammenhängen. Möglicherweise gibt es eine Dokumentation, die diesbezüglich aktualisiert werden könnte. Wenn es eine bemerkenswerte Funktion ist, könnte er ein kurzes GIF erstellen, das zeigt, wie man damit arbeitet. Selbst wenn sie sich ihre Codeänderung noch einmal ansehen, können sie überlegen, wie sie sie beim nächsten Mal verbessern können. Diese Zeit kann auch zur Überprüfung von Pull-Anforderungen und Codeänderungen anderer Entwickler verwendet werden.

Wenn sie in diesen 10 Minuten ein anderes Feature entwickeln, wird es wahrscheinlich länger als 10 Minuten dauern, bis sie darauf zurückkommen, und die Arbeit wird in ihrem Kopf weniger frisch sein. Wenn das CI dann ausfällt, fällt es ihnen schwerer, sich daran zu erinnern, was möglicherweise schief gelaufen ist, und den Code zu reparieren.

— Samuel Garratt
quelle

Dies ist so wahr: CI sollte meiner Meinung nach niemals länger laufen als auf dem Computer des Entwicklers.

— Peter Muryshkin

0

Ok, nehmen wir an, Sie haben ein Versionskontroll-Tool als Git- und CI-Tool Jenkins. Also erstellt Dev einen Feature-Zweig für ein Problem. Sie haben eine Multibranch-Pipeline oder einen Workflow in Ihrem CI-Tool, der diesen Feature-Zweig beim nächsten Scan erkennt und die CI-Schritte ausführt.

Dinge, die sichergestellt werden müssen, sind:

Vor dem Erhöhen von PR / MR ist der CI-Job grün. Wenn es nicht grün ist, sollte PR / MR nicht angehoben werden. Offensichtlich kann der Entwickler andere Aufgaben ausführen und dann zurückkommen und das Problem bei dieser Aufgabe beheben. Dies ist seine Wahl, abhängig von der Aufgabenpriorität. Sie können sogar verhindern, dass PR ausgelöst wird, indem Sie die CI-Parameter überprüfen. (Wenn Sie Ihrem Entwickler nicht so sehr vertrauen und er PRs für fehlerhafte Builds kontinuierlich erhöht.)
Sobald PR ausgelöst wurde, überprüft ein Code-Prüfer und führt ihn zusammen, wenn alles in Ordnung ist. Code Reviewer kann jeder andere Entwickler sein. Es liegt in seiner Verantwortung, den Code zu überprüfen, um festzustellen, ob er den Kriterien von "Definition of Done" entspricht. DoD ist hauptsächlich ein agiler Begriff, aber agil und DevOps gehen Hand in Hand.
Nach dem Zusammenführen des Codes sollte das CI für den Hauptzweig grün sein. Wenn nicht, sollte der Code zurückgesetzt und das Problem behoben werden, da der Hauptzweig im Allgemeinen auch in Umgebungen bereitgestellt wird und ein Nicht-Rollback bedeutet, dass die gesamte Umgebung beschädigt wird.

Offensichtlich werden Post-Build-Aktionen den Committer darüber informieren, dass Hey, Sie haben den Build abgebrochen, damit Entwickler ihre anderen Aufgaben ausführen können. Sie erhalten trotzdem E-Mails.

— Deosha
quelle