pull request’in yanında kaç sekme açık?
Ürününüzün ücretsiz deneme onboarding akışında yeni bir issue ele aldığınızı düşünün: “invite your teammates” adımını isteğe bağlı hâle getirin. Kayıtlar arttıkça destek ekibi bu adımı bir sürtünme noktası olarak işaretlemeye devam ediyor. Hızlı bir kazanım, değil mi?
Kapsam belirlemeden deployment’a kadar şu dört sorunun yanıtına ihtiyacınız var:
Bu gerçekten doğru değişiklik mi?
Dokunduğum bağımlılıklar temiz mi?
Bunu güvenli bir şekilde nasıl kullanıma sunarım?
Şu anda deployment yapmak güvenli mi?
Her yanıt farklı bir araçta bulunuyor; dolayısıyla pull request üzerinde çalışmak, aynı bağlamı dört farklı yer arasında taşımak anlamına geliyor.
GitHub agent uygulamaları, bu soruları yanıtlamak için ihtiyaç duyduğunuz araçları zaten çalıştığınız yere getiriyor; bunu da kendi Copilot cloud agent’ımızla aynı platform ve harness üzerinde yapıyor.
Aşağıdaki örnek üzerinden ilerleme, GitHub’dan hiç ayrılmadan bu soruları yanıtlamak ve bu talebi tamamlamak için Amplitude, Endor Labs, LaunchDarkly ve PagerDuty gibi hâlihazırda bağımlı olduğunuz hizmetleri nasıl kullanabileceğinizi gösteriyor.
1. Geliştirmeye başlamadan önce
Destek ekibi, “invite your teammates” adımının ürününüzle onboarding sürecine giren müşteriler için can sıkıcı olduğunu söylüyor; ancak kimlerin şikâyet ettiğine veya bu şikâyetlerin müşteri kaybına yol açıp açmadığına dair herhangi bir bilgi vermediler. Şüpheci olmanız yerinde. Bu yüzden Amplitude’ı açıp tahmininizi doğrulamak için bir sorgu oluşturmak yerine, doğrudan Agents sekmesinden Amplitude agent’ına soruyorsunuz:
@amplitude[agent] Takım daveti adımının tamamlanması, funnel’ın ilerleyen aşamalarındaki başarıyla ilişkili mi? Ölçtüğümüz segmentlere göre kır.
Ayrım net: Adımı tamamlayan ekip kullanıcılarının daha sonra elde tutulma olasılığı daha yüksekken solo kullanıcılar için böyle bir ilişki yok. Artık kapsamı yeniden belirlemek için gerekçe var: solo kayıt olanlar için bu adımı erteleyin, ekipler için koruyun.
Ürün içgörülerine erişim artık GitHub’ın içinde; böylece herhangi bir kod yazılmadan önce yön düzeltilebiliyor.
2. Geliştirirken
Copilot, değişiklik için bir taslak pull request açıyor. Uygulama, onboarding akışında kullanılan bağımlılıkları da güncelliyor. Daha sonra bir CI taramasının başarısız olmasını beklemek yerine, yorumda Endor Labs agent’ına soruyorsunuz:
@endor-labs-github-agenthq[agent] Bu pull request’in dokunduğu bağımlılıklarda dikkat etmem gereken bir şey var mı?
Agent, değiştirilen bağımlılıkları belirliyor, bilinen güvenlik açıkları ve paketle ilgili daha geniş kapsamlı riskler açısından kontrol ediyor, ardından pull request’te rapor sunuyor. Bu kez her şey temiz görünüyor. Giderilmesi gereken hiçbir şey yok.
Bağımlılık incelemesi, değişiklik hâlâ önünüzdeyken proaktif bir kontrole dönüşüyor. Bir CI taraması başarısız olduktan sonra düzeltme yapmaktan çok daha iyi.
3. Yayına alma
Önceki bulgu artık uygulamaya taşınıyor: solo kayıt olanlar isteğe bağlı yolu kullanırken ekipler mevcut yolu koruyor. Bu segmentler kayıt sırasında belirlendiği için bir feature flag bunları doğrudan hedefleyebilir. Bir ekip arkadaşınızdan ister gibi LaunchDarkly agent’ından bunu sizin için kurmasını isteyin:
@launchdarkly-agent[agent] lütfen bu pull request için bir feature flag oluştur ve bunu koda bağla.
– key: defer-team-invite
– type: boolean
– default: false
– target: solo-intent signups
– rollout: internal > 5% > 25% > 100%
Agent, LaunchDarkly’de flag’i oluşturur ve kod uygulamasını incelemeniz için bir commit olarak ekler. Hedef ortam onay gerektiriyorsa, hedefleme değişikliğini doğrudan uygulamak yerine bir onay isteği oluşturur. Yayına almanın ilerleyip ilerlemeyeceğine yine bir insan karar verir.
Flag kurulumu; ikinci bir araç, manuel bir kod aktarımı ve Slack koordinasyonu gerektiren bir süreç olmaktan çıkar, tek bir pull request yorumu ve incelemeniz için bir commit hâline gelir.
4. Yayına almadan önce
İnceleme, kodun doğru olduğunu söyler; ancak hizmetin bir dağıtım için iyi durumda olup olmadığı farklı bir sorudur.