GTA: Erkennung betroffener abhängiger Go-Pakete

Heute kündigen wir das Open Sourcing von gta an, das wir verwenden, um die Downstream-Abhängigkeiten von Go-Paketen zu verstehen, die in Pull-Requests an unser Monorepo cthulhu geändert wurden. Technisch gesehen steht gta für Go Test Auto, aber ein treffenderer Name könnte Go Transitive Analysis sein.

In diesem Artikel werden wir den primären Anwendungsfall für gta, seine Optionen und wie es die Build-Zeiten für Feature-Zweigs verbessern kann, indem wir nur Pakete ansprechen, die von den Änderungen im Feature-Zweig betroffen sind, durchgehen.

Matt Layher stellte gta zum ersten Mal in seinem Blog-Artikel über cthulhu vor, in dem er die Motivation und den positiven Einfluss diskutierte, den gta auf die Build-Zeiten von Monorepo-Pull-Requests bei DigitalOcean hatte. Kurz gesagt vergleicht gta den aktuellen Branch mit seiner Merge-Basis des Ziel-Branchs, um festzustellen, was in dem Branch geändert wurde. Anschließend berechnet es alle Abhängigkeiten dieser Änderungen und gibt die Importpfade aller betroffenen Pakete aus.

Nach langsamen und unzuverlässigen Builds machte sich einer unserer Ingenieure, Justin Hines, daran, das Problem ein für alle Mal zu lösen. Nach ein paar Stunden Arbeit entwickelte er ein Build-Tool namens gta, das den Git-Verlauf untersuchen sollte, um festzustellen, welche Dateien sich zwischen der Merge-Basis des Ziel-Zweigs und einem Feature-Zweig geändert haben. Es verwendet diese Informationen, um zu bestimmen, welche Pakete für einen bestimmten Build getestet werden müssen, einschließlich Pakete, die das geänderte Paket importieren.

Nehmen wir als Beispiel an, dass eine Änderung festgeschrieben wird, die ein Paket modifiziert, wie zum Beispiel: do/teams/example/droplet. Angenommen, dieses Paket wird von einem anderen Paket importiert: do/teams/example/hypervisor. Gta wird verwendet, um die Git-Historie zu überprüfen und festzustellen, dass diese beiden Pakete getestet werden müssen, obwohl nur das erste Paket geändert wurde.

Die Einführung von gta in unseren CI-Buildprozess hat die Zeit für Builds drastisch reduziert. Als gta Anfang 2016 eingeführt wurde, sank die durchschnittliche Bauzeit von 20 Minuten auf 2-3 Minuten! Dieses Tool wird jetzt fast überall in unserer Build-Pipeline verwendet, einschließlich statischer Analyseprüfungen, Codekompilierung und -tests sowie Artefakt-Builds und -Bereitstellung.

About the Author

Leave a Reply

Your email address will not be published. Required fields are marked *

You may also like these