Quante schede sono aperte accanto alla pull request?
Immaginate di affrontare un nuovo issue nel flusso di onboarding della prova gratuita del vostro prodotto: rendere facoltativo il passaggio “invite your teammates”. Man mano che aumentano le registrazioni, il team di supporto continua a indicare questo passaggio come un punto di attrito. Una vittoria rapida, no?
Dalla definizione dell’ambito fino al deployment, avete bisogno di rispondere a queste quattro domande:
È davvero la modifica giusta?
Le dipendenze che ho toccato sono pulite?
Come posso rilasciarla in modo sicuro?
È sicuro effettuare il deployment in questo momento?
Ogni risposta si trova in uno strumento diverso; lavorare sulla pull request significa quindi trasferire lo stesso contesto tra quattro luoghi diversi.
Le app agent di GitHub portano direttamente nel luogo in cui state già lavorando gli strumenti di cui avete bisogno per rispondere a queste domande, utilizzando la stessa piattaforma e lo stesso harness del nostro Copilot cloud agent.
L’esempio seguente mostra come utilizzare, senza mai lasciare GitHub, servizi da cui già dipendete, come Amplitude, Endor Labs, LaunchDarkly e PagerDuty, per rispondere a queste domande e completare questa richiesta.
1. Prima di iniziare lo sviluppo
Il team di supporto afferma che il passaggio “invite your teammates” è frustrante per i clienti che iniziano il processo di onboarding con il vostro prodotto; tuttavia, non ha fornito alcuna informazione su chi si lamenta né sul fatto che queste lamentele portino alla perdita di clienti. È giusto essere scettici. Per questo, invece di aprire Amplitude e creare una query per verificare la vostra ipotesi, chiedete direttamente all’Amplitude agent dalla scheda Agents:
@amplitude[agent] Il completamento del passaggio relativo all’invito del team è correlato al successo nelle fasi successive del funnel? Suddividi i risultati in base ai segmenti che misuriamo.
La distinzione è netta: gli utenti dei team che completano il passaggio hanno maggiori probabilità di essere trattenuti in seguito, mentre per gli utenti singoli non esiste una relazione analoga. Ora abbiamo una motivazione per ridefinire l’ambito: rimandate questo passaggio per chi si registra da solo, mantenetelo per i team.
Gli insight sul prodotto sono ora accessibili all’interno di GitHub; in questo modo è possibile correggere la direzione prima ancora di scrivere codice.
2. Durante lo sviluppo
Copilot apre una pull request preliminare per la modifica. L’applicazione aggiorna anche le dipendenze utilizzate nel flusso di onboarding. Invece di aspettare che una scansione CI fallisca in un secondo momento, chiedete all’Endor Labs agent nel commento:
@endor-labs-github-agenthq[agent] C’è qualcosa a cui devo prestare attenzione nelle dipendenze interessate da questa pull request?
L’agent individua le dipendenze modificate, le controlla alla ricerca di vulnerabilità note e di rischi più ampi legati ai pacchetti, quindi presenta un report nella pull request. Questa volta sembra essere tutto a posto. Non c’è nulla da correggere.
La revisione delle dipendenze diventa un controllo proattivo mentre la modifica è ancora davanti a voi. È molto meglio che correggere il problema dopo il fallimento di una scansione CI.
3. Messa in produzione
Il risultato precedente viene ora trasferito nell’applicazione: chi si registra da solo utilizza il percorso facoltativo, mentre i team mantengono quello esistente. Poiché questi segmenti vengono determinati durante la registrazione, un feature flag può indirizzarli direttamente. Chiedete al LaunchDarkly agent di configurarlo per voi, come fareste con un collega del team:
@launchdarkly-agent[agent] crea un feature flag per questa pull request e collegalo al codice.
- key: defer-team-invite
- type: boolean
- default: false
- target: registrazioni con intenzione individuale
- rollout: interno > 5% > 25% > 100%
L’agent crea il flag in LaunchDarkly e aggiunge l’implementazione nel codice come commit, affinché possiate esaminarla. Se l’ambiente di destinazione richiede un’approvazione, crea una richiesta di approvazione invece di applicare direttamente la modifica al targeting. Spetta comunque a una persona decidere se la messa in produzione debba proseguire.
La configurazione del flag non è più un processo che richiede un secondo strumento, un trasferimento manuale del codice e il coordinamento su Slack: diventa un unico commento nella pull request e un commit da esaminare.
4. Prima della messa in produzione
La revisione conferma che il codice è corretto; tuttavia, stabilire se il servizio sia in buone condizioni per una distribuzione è una questione diversa.