Wie viele Tabs sind neben dem Pull Request geöffnet?
Stellen Sie sich vor, Sie bearbeiten ein neues Issue im kostenlosen Onboarding-Ablauf Ihres Produkts: Machen Sie den Schritt „invite your teammates“ optional. Während die Zahl der Anmeldungen steigt, markiert das Supportteam diesen Schritt weiterhin als Reibungspunkt. Ein schneller Erfolg, oder?
Vom Festlegen des Umfangs bis zum Deployment benötigen Sie Antworten auf diese vier Fragen:
Ist das wirklich die richtige Änderung?
Sind die Abhängigkeiten, die ich berühre, sauber?
Wie kann ich das sicher ausrollen?
Ist es jetzt sicher, ein Deployment durchzuführen?
Jede Antwort findet sich in einem anderen Tool. An einem Pull Request zu arbeiten bedeutet daher, denselben Kontext zwischen vier verschiedenen Orten hin- und herzubewegen.
GitHub-Agent-Anwendungen bringen die Tools, die Sie zur Beantwortung dieser Fragen benötigen, dorthin, wo Sie bereits arbeiten – auf derselben Plattform und im selben Harness wie unser eigener Copilot cloud agent.
Das folgende Beispiel zeigt, wie Sie die Dienste, von denen Sie bereits abhängig sind – etwa Amplitude, Endor Labs, LaunchDarkly und PagerDuty –, nutzen können, um diese Fragen zu beantworten und diese Anfrage abzuschließen, ohne GitHub zu verlassen.
1. Bevor Sie mit der Entwicklung beginnen
Das Supportteam sagt, dass der Schritt „invite your teammates“ für Kunden, die mit Ihrem Produkt den Onboarding-Prozess durchlaufen, ärgerlich ist. Es hat jedoch keine Angaben dazu gemacht, wer sich beschwert oder ob diese Beschwerden zum Verlust von Kunden führen. Skeptisch zu sein, ist daher angebracht. Statt Amplitude zu öffnen und eine Abfrage zu erstellen, um Ihre Vermutung zu überprüfen, fragen Sie den Amplitude-Agenten direkt über den Tab „Agents“:
@amplitude[agent] Hängt der Abschluss des Schritts zur Einladung des Teams mit dem Erfolg in den späteren Phasen des Funnels zusammen? Schlüssle dies nach den von uns gemessenen Segmenten auf.
Die Unterscheidung ist eindeutig: Teamnutzer, die den Schritt abschließen, werden später mit höherer Wahrscheinlichkeit gehalten, während es bei Solonutzern keinen solchen Zusammenhang gibt. Jetzt gibt es eine Begründung dafür, den Umfang neu festzulegen: Verschieben Sie diesen Schritt für Nutzer, die sich allein registrieren, und behalten Sie ihn für Teams bei.
Der Zugriff auf Produkteinblicke ist jetzt innerhalb von GitHub möglich, sodass die Richtung korrigiert werden kann, bevor überhaupt Code geschrieben wird.
2. Während der Entwicklung
Copilot eröffnet für die Änderung einen Entwurf für einen Pull Request. Die Anwendung aktualisiert außerdem die im Onboarding-Ablauf verwendeten Abhängigkeiten. Statt später auf den Fehlschlag eines CI-Scans zu warten, fragen Sie den Endor Labs agent im Kommentar:
@endor-labs-github-agenthq[agent] Gibt es bei den Abhängigkeiten, die von diesem Pull Request betroffen sind, etwas, worauf ich achten sollte?
Der Agent identifiziert die geänderten Abhängigkeiten, prüft sie auf bekannte Sicherheitslücken und umfassendere Risiken im Zusammenhang mit den Paketen und veröffentlicht anschließend einen Bericht im Pull Request. Dieses Mal sieht alles sauber aus. Es gibt nichts zu beheben.
Die Überprüfung der Abhängigkeiten wird zu einer proaktiven Kontrolle, solange die Änderung noch vor Ihnen liegt. Das ist deutlich besser, als erst nach dem Fehlschlag eines CI-Scans eine Korrektur vorzunehmen.
3. Bereitstellung
Die vorherige Erkenntnis wird nun in die Anwendung übertragen: Solonutzer verwenden den optionalen Pfad, während Teams den bestehenden Pfad beibehalten. Da diese Segmente bei der Registrierung bestimmt werden, kann ein Feature-Flag sie direkt ansprechen. Bitten Sie den LaunchDarkly agent, dies für Sie einzurichten, so als würden Sie einen Teamkollegen darum bitten:
@launchdarkly-agent[agent] Bitte erstelle für diesen Pull Request ein Feature-Flag und verknüpfe es mit dem Code.
- key: defer-team-invite
- type: boolean
- default: false
- target: Registrierungen mit Solo-Intent
- rollout: intern > 5 % > 25 % > 100 %
Der Agent erstellt das Flag in LaunchDarkly und fügt die Code-Implementierung als Commit hinzu, damit Sie sie überprüfen können. Erfordert die Zielumgebung eine Genehmigung, erstellt er stattdessen eine Genehmigungsanfrage, anstatt die Änderung der Zielgruppe direkt anzuwenden. Ob die Bereitstellung fortgesetzt wird, entscheidet weiterhin ein Mensch.
Die Einrichtung des Flags ist kein Prozess mehr, der ein zweites Tool, eine manuelle Codeübertragung und die Koordination über Slack erfordert, sondern wird zu einem einzigen Pull-Request-Kommentar und einem Commit für Ihre Überprüfung.
4. Vor der Bereitstellung
Die Überprüfung zeigt, dass der Code korrekt ist; ob der Dienst für eine Bereitstellung in einem guten Zustand ist, ist jedoch eine andere Frage.