Gibt es ein CI-Tool, das keine Regressionen in der Branchenqualitätsstufe garantiert?

10

Herkömmlicherweise führen CI-Systeme nur eine Überwachung der Qualitätsstufen in einem Integrationszweig durch, indem sie QS-Überprüfungen in der Codebasis durchführen, in der die Änderungen bereits festgeschrieben sind, auf Regressionen achten und Benachrichtigungen für menschliches Eingreifen senden.

Wenn diese Regressionen jedoch erkannt werden, ist die Niederlassung zumindest seit Beginn der jeweiligen QS-Überprüfung bereits in Schwierigkeiten und bleibt in diesem Zustand (oder wird sogar noch schlimmer!), Bis alle Schuldigen identifiziert, Reparaturen für sie begangen und eine neue QS-Überprüfung durchgeführt wurden bestätigt, dass das Qualitätsniveau der Niederlassung wiederhergestellt wurde. Der Zweig kann während dieser ganzen Zeit als für die normale Entwicklung blockiert betrachtet werden.

Gibt es ein CI Werkzeug, das eigentlich verhindern solche Regressionen nicht passiert, die funktionieren würde pre-commit QA Prüfungen und ermöglicht Commits nur , wenn die Code - Basis mit den entsprechenden Commits aktualisiert sein würde , wie auch diejenigen , pre-commit QA Prüfungen vorbei, so dass ein Minimum garantiert Branchenqualitätsniveau?

Update: Es wird davon ausgegangen, dass geeignete automatisierte QS-Überprüfungen mit angemessener Abdeckung, um die jeweiligen Regressionen erkennen zu können, von den CI-Tools aufgerufen werden können.

continuous-integration software-recommendation

— Dan Cornilescu
quelle

Ich frage mich immer wieder, wie ich diese Frage richtig verstehen kann (und Ihre eigene Empfehlung in Ihrer eigenen Antwort). Wenn ich "Überwachung" durch "Nach den Tatsachen" ersetzen und "Verhindern" durch "Verhindern, dass sie eintreten" würde, wäre das dann mehr oder weniger dieselbe Frage? Vielleicht können Sie auch ein Beispielszenario hinzufügen, um den Unterschied zu erklären?

— Pierre.Vriens

@ Pierre.Vriens Ist das besser?

— Dan Cornilescu

6

Soweit ich das beurteilen kann, suchen Sie nach einem Tool, das Commits ablehnt , die den Build beschädigen. Ein CI-Tool kann Regressionen wahrscheinlich nicht verhindern, indem es Ihren Code tatsächlich repariert, aber es kann Sie davon abhalten, fehlerhaften Code hinzuzufügen zum Repository.

Atlassian hat einige interessante Anwendungen von Git-Hooks :

Serverseitige Pre-Receive-Hooks sind ein besonders leistungsfähiges Kompliment für die kontinuierliche Integration, da sie verhindern können, dass Entwickler Code an den Master senden, es sei denn, der Code erfüllt bestimmte Bedingungen - wie z. B. Elite-Ninja-Wächter, die ihn vor schlechtem Code schützen.

Wenn Sie Git verwenden, sind die Hooks sehr leistungsfähig (und es gibt ähnliche Hooks für SVN , Mercurial und andere Versionskontrollsysteme), und es kann hilfreich sein, sie zum Ausführen von Pre-Commit-Prüfungen zu verwenden.

Die Git-Dokumentation enthält eine Seite zum Erstellen eines Hooks zum Ablehnen von Pushs, wenn diese bestimmte Kriterien nicht erfüllen, die leicht an diesen Anwendungsfall angepasst werden können.

Viele Leute würden jedoch argumentieren, dass das Ablehnen von Commits eine schlechte Idee für einen featureZweig ist - Sie werden nur Zeit damit verschwenden, gegen Ihr CI-System zu kämpfen, wenn der Build aus irgendeinem Grund unterbrochen wird, anstatt den Fehler tatsächlich zu beheben.

In der masterVerzweigung kann es sinnvoll sein, fehlerhafte Zusammenführungen abzulehnen, da Sie möglicherweise sicherstellen möchten, dass sie immer erstellt werden. Für einen featureZweig, Sie werden unweigerlich Dinge brechen, und da der Code nicht in Produktion geht jetzt , macht es mehr Sinn , nur um dich zu warnen , als tatsächlich Ihre ganz ablehnen begehen.

— Aurora0001
quelle

Nun, was nützt ein SW-Image, das sich aufbaut, aber ist DOA vom Testen prospektiv? Entwickler können ihre Codeänderungen nicht testen, selbst wenn sie erstellt werden, sodass sie genauso blockiert sind. Im Allgemeinen würde ich die Ablehnung eines Commits auf alles ausdehnen, was eine Mindest-QS-Prüfung nicht besteht. Dies wird durch Abwägen von zwei widersprüchlichen Anforderungen ausgewählt: so hoch wie möglich, um die Anzahl der vor Blockierung geschützten Entwickler zu maximieren, und so niedrig wie möglich, damit sich die QA-Überprüfung nicht verzögert Verlangsamen Sie den Prozess nicht zu sehr.

— Dan Cornilescu

Ein Beispiel hierfür ist das Pull-Anforderungsmodell, bei dem Sie bestimmte Einschränkungen festlegen können, ob eine Pull-Anforderung zusammengeführt werden kann oder nicht. Zum Beispiel verwenden wir (meine Firma) Atlassian Bitbucket Server und es gibt Optionen, bei denen mindestens N Genehmigungen und X übergebene Builds für den angegebenen Zweig erforderlich sind, bevor eine Pull-Anforderung zusammengeführt werden darf. Dies lehnt es nicht sofort ab. Verhindert jedoch ein versehentliches Zusammenführen, wenn Tests fehlschlagen oder andere Augen den Code noch nicht gesehen haben.

— Andy Shinn

@AndyShinn: Ja, ich finde das sehr nützlich - GitHub bietet auch geschützte Zweige und Überprüfungen von Pull-Anfragen an , die oft hilfreich sind.

— Aurora0001

1

Ein Argument für das Zulassen von fehlerhaftem Code in Feature-Zweigen ist, dass Entwickler Code, an dem sie arbeiten, an das Repo senden können, auch wenn er noch nicht ganz fertig ist. Dies kann nützlich sein, um Code für frühe Code- / Architekturüberprüfungen mit anderen zu teilen, bevor die Dinge einsatzbereit sind, um Probleme zu beheben oder um jemanden, der in den Urlaub fährt, teilweise erledigte Arbeiten dort zu platzieren, wo andere darauf zugreifen können. Für Feature-Zweige würde ich nur Dinge wie Linters und Pre-Commit-Hooks einsetzen.

— Bradym

2

Kein Tool kann möglicherweise keine Regressionen garantieren - das hängt viel mehr von Ihren Tests ab als von dem Tool, das sie ausführt. Sie können jedoch verhindern, dass Regressionen, die abgefangen werden, in den Integrationszweig gelangen. Sie können dies mit Pre-Commit-Hooks tun, aber es ist oft einfacher mit Pull-Anfragen (die Sie hoffentlich bereits für die Peer-Code-Überprüfung verwenden).

Wenn eine Niederlassung mit ihrem Upstream (zu dem die PR zusammengeführt wird) auf dem neuesten Stand ist und ihre Tests bestanden wurden, werden sie nach der Zusammenführung weiterhin bestanden. Der Status des Zielzweigs nach dem Zusammenführen stimmt mit dem Status des Quellzweigs vor dem Zusammenführen überein.

Es ist im Allgemeinen nicht besonders schwierig (abhängig von den verwendeten Tools) anzugeben, ob der Quellzweig in einem PR mit dem Ziel auf dem neuesten Stand ist und ob er einen passierenden CI-Build hat. Sie können dies als Voraussetzung (nach Richtlinie und / oder in Software erzwungen) zum Zusammenführen der Pull-Anforderung verwenden.

— Adrian
quelle

"Wenn eine Niederlassung mit ihrem Upstream (wo die PR zusammengeführt wird) auf dem neuesten Stand ist und ihre Tests bestanden werden, werden sie nach der Zusammenführung immer noch bestanden" - Warum? Eine Verschmelzung ist eine Diskontinuität, sie bringt Unbekanntes. Wie bei Konflikten wird der Code möglicherweise erst erstellt, wenn sie gelöst sind. Sie müssen die Tests ausführen und bestätigen, dass sie für eine Zweigzusammenführung erfolgreich sind. Ich würde sogar für einen schnellen Vorlauf sagen, wenn Sie auf Nummer sicher gehen wollen. Siehe Apartsw.com/insights/2016/11/16/…

— Dan Cornilescu

Ähm, ja, eine solche Garantie ist möglich, überprüfen Sie meine Antwort. Nun, vielleicht sollte ich klarstellen: Mit Regression meine ich Ergebnisse, die schlechter sind als die Ergebnisse der Verzweigungsbasislinie (und wenn die Möglichkeit falsch positiver Ergebnisse ignoriert wird, müssen diese angegangen werden, da sie die Basislinie verzerren können, das Ganze entgleisen lassen und menschliches Eingreifen erfordern). Intermittierende falsche Negative sind nur ein Ärgernis, das die Dinge verlangsamt, aber behandelt werden kann.

— Dan Cornilescu

Sie können keine Regressionen garantieren, Sie können nur keine erkannten Regressionen garantieren. Wenn eine Änderung eine Regression verursacht, die nicht von einem Test erfasst wird, ist dies eine Regression, für die ein CI-Tool keine Garantie übernehmen kann. Während das Zusammenführen von zwei Änderungssätzen Unbekannte mit sich bringt, können Sie dies im Feature-Zweig (durch Zusammenführen des Upstreams in) tun, bevor Sie die andere Richtung zusammenführen. Wenn die Quelle mit dem Ziel auf dem neuesten Stand ist, handelt es sich um eine einfache Zusammenführung (schneller Vorlauf). Danach ist der Zielstatus mit dem Quellstatus vor der Zusammenführung identisch. Wenn also Tests zuvor bestanden wurden, werden sie danach bestanden.

— Adrian

Haarspalterei. Das CI-Tool kann mit einem Test konfiguriert werden, um zu erkennen und somit vor jeder Regression zu schützen, die Sie interessiert. Ich werde nicht zu viel über die Zusammenschlüsse streiten - mein Ziel ist es, sie so weit wie möglich zu vermeiden, sie sind insgesamt nur Ärger :)

— Dan Cornilescu

Mein Punkt ist, dass es nicht das CI-Tool ist, das diesen Schutz bietet, sondern Sie, indem Sie die Tests schreiben. Das CI-Tool kann keine Garantien bieten, die über die von Ihnen bereitgestellten Tests hinausgehen.

— Adrian

1

Echte Tools für die kontinuierliche Integration (im Gegensatz zu nur kontinuierlichen Tests) wie Reitveld und Zuul können helfen, obwohl sie nur so gut sind wie die Tests, die Sie schreiben und die Sie überprüfen.

— Codierer
quelle

Aber Reitveld scheint ein kollaboratives Tool zur Codeüberprüfung zu sein, kein CI-Tool. Fehlt mir etwas? Dies ist, was ich sah: github.com/rietveld-codereview/rietveld

— Dan Cornilescu

Zuul scheint tatsächlich verwandt zu sein, ich werde es genauer untersuchen.

— Dan Cornilescu

Es werden keine Tests durchgeführt, es werden jedoch einige Aspekte der Zweigstellenverwaltung behandelt, die als Gatekeeper-System fungieren. Dies ist die beste Möglichkeit, um zu verhindern, dass fehlerhafter Code durch Blockieren der Zusammenführung eingeht.

— Coderanger

Ich verstehe was du meinst. Nun, es kann bei der gesamten Codequalität helfen, bringt aber an sich keine Garantie. Zwei vollkommen gute Änderungen, die alle QS-Überprüfungen unabhängig voneinander bestehen, können immer noch zu Brüchen führen, wenn sie sich in der Niederlassung treffen.

— Dan Cornilescu

1

Mit GitLAB können Sie in den Projekteinstellungen festlegen, dass eine Zusammenführung nur dann zulässig ist, wenn die Pipeline erfolgreich ist. Sie können also eine wirklich kontinuierliche Integration durchführen. Kombinieren Sie dies mit dem Hinzufügen Ihrer Qualitätssicherung zur Liste der Zusammenführungsgenehmigungen, und mit Dynamic Environments können Sie eine Qualitätssicherung durchführen bevor Sie zum Master verschmelzen.

— Danny Goossen
quelle

Dies funktioniert jedoch nur, wenn Sie nicht zulassen, dass eine zweite Zusammenführung QA-Prüfungen startet, bevor die vorherige Zusammenführung abgeschlossen ist. Andernfalls wird bei der zweiten Zusammenführung die erste nicht angezeigt, sodass Raum für Regressionen bleibt. Mit anderen Worten, die Zusammenführungen (einschließlich ihrer QS-Prüfungen) müssen vollständig serialisiert werden, was für große Teams nicht skalierbar ist.

— Dan Cornilescu

0

ApartCI ist ein CI-System, das genau darauf ausgelegt ist, Regressionen zu verhindern und so ein flaches oder steigendes Qualitätsniveau der Niederlassung zu gewährleisten. Noch in der Beta.

Es koordiniert zentralisierte Überprüfungen vor dem Festschreiben so, dass sichergestellt ist, dass eine Änderung erst festgeschrieben wird, nachdem sie zusammen mit allen anderen zuvor festgeschriebenen Änderungen überprüft wurde, um das neueste Qualitätsniveau der Zweigstelle zu erreichen oder zu übertreffen.

Dies ist der Hauptunterschied zu herkömmlichen entwicklergesteuerten Pre-Commit-Überprüfungen, die häufig parallel durchgeführt werden. Dies lässt Raum für Regressionen, die durch störende Änderungen verursacht werden, die nie zusammen getestet wurden.

Das Tool ist auch einfach zu skalieren - es kann sehr hohe Raten eingehender Kandidatenänderungen aufrechterhalten und 100/1000 Entwickler unterstützen, die in derselben Integrationsbranche arbeiten.

Haftungsausschluss: Ich bin der Autor des Tools und Gründer des Unternehmens, das es anbietet. Entschuldigung für die Anzeige.

— Dan Cornilescu
quelle

Es ist gut, dass Sie den Haftungsausschluss hinzugefügt haben, aber ich persönlich denke darüber nach, eine Frage zu stellen und sie selbst zu beantworten, indem Sie Ihr eigenes Unternehmen oder Ihre Produkte als Spam bewerben.

— THelper

Ich habe eine Frage zu Meta gestellt, ob dies erlaubt ist oder nicht: meta.devops.stackexchange.com/q/59

— THelper

SnapCI hat das auch getan. RUHE IN FRIEDEN.

— Paul_h

@paul_h, es sei denn, ich vermisse etwas SnapCI und die empfohlene Ersatz-GoCD basieren beide auf Überprüfungen nach dem Festschreiben (ausgelöst durch Abfragen des SCM), sodass sie weiterhin nur überwacht werden. Außer vielleicht für PR-Prüfungen, aber wenn diese Prüfungen nicht vollständig serialisiert sind, können sie die Häufigkeit von Regressionsereignissen nur reduzieren, aber nicht vollständig beseitigen.

— Dan Cornilescu

Dan, der nicht nein fragt, hakt. Und zu einem kurzlebigen PR-Zweig, der noch nicht in Trunk / Master zusammengeführt wurde - trunkbaseddevelopment.com/game-changers/…

— paul_h