Amp'te Service Accounts: workspace'a ait, tek bir kullanıcıya bağlı olmayan hesaplar
Amp, tek bir kullanıcıya bağlı olmayan, workspace'a ait hesaplar olan Service Accounts özelliğini duyurdu. Bu hesapların kendi API key'leri ve üçüncü taraf kimlik bilgileri var; oluşturdukları thread'ler tüm workspace üyeleri tarafından görülebiliyor ve birden fazla kişi bu thread'lerde mesaj gönderebiliyor. Özellikle PR review, dokümantasyon bakımı ve CI job'larından tetiklenen otomasyonlar için tasarlanmış.
Kilit noktalar
- Service Accounts workspace admin'leri tarafından oluşturuluyor ve tek bir kullanıcıya bağlı değil.
- Her service account'ın kendi API key'leri ve üçüncü taraf kimlik bilgileri var.
- Service account altında açılan thread'ler workspace üyelerince görülebiliyor ve herkes mesaj gönderebiliyor.
- CI'da `amp -ox` çağrısını service account API key'i ile başlatınca thread takıma ait oluyor.
- PR review ve dokümantasyon taraması gibi sürekli bakım işleri Puck üzerinden workspace'e ait thread'lere dönüştürülebiliyor.
Amp, takıma ait işleri tek bir kişinin hesabına bağlamak yerine workspace'a devretmek için Service Accounts özelliğini ekledi. Workspace admin'leri tarafından oluşturulan bu hesapların kendi API key'leri ve üçüncü taraf kimlik bilgileri var; altında açılan thread'ler workspace üyelerinin tamamı tarafından görülebiliyor ve herkes bu thread'lerde mesaj yazabiliyor, yani thread'ler multiplayer çalışıyor. Bu yüzden hesaba yalnızca tüm workspace üyelerine vermekten çekinmeyeceğiniz kimlik bilgilerini atamak gerekiyor.
İki kullanım örneği öne çıkıyor: yeni GitHub PR'larını karşılayıp review eden ya da public dokümantasyonu düzenli aralıklarla tarayan workspace'e ait thread'ler (Amp bunları Puck üzerinden kuruyor) ve build başarısız olduğunda `amp -ox` çağrısını service account'ın API key'i ile başlatan CI job'ları. Böylece pipeline'ı kuran kişi işten ayrılsa da thread'ler takımda kalıyor. Kurulum yaparken service account'ın kimlik bilgilerinin erişim kapsamını dar tutmak en önemli nokta.
Gerçek dünyada kullanımı
- Her yeni GitHub PR'ında otomatik review başlatan ve thread'i takımın erişiminde tutan bir otomasyon.
- Dokümantasyonu 24 saatte bir tarayıp eskimiş bölümler için sorumluyu @ mention ile uyaran workspace'e ait thread.
- Build kırıldığında `amp -ox` ile regresyon mu yoksa flaky test mi olduğunu araştıran CI review bot'u.
- Otomasyonu kuran geliştirici izinde ya da ekipten ayrılmış olsa bile takımın devam ettirebildiği bakım işleri.
Neden önemli
Otomasyonlar ve review akışları kişisel hesaplara bağlı kalmaktan çıkıp takıma ait hale geliyor; böylece bir çalışanın izni ya da ayrılması bu işleri durdurmuyor.