Kendi Planlama Pokeri Araçımı Neden Geliştirdim (ve Arkasında Ne Var)

TL;DR

Ben, dağınık mühendislik ekipleri için gerçek zamanlı bir planning poker aracı olan Pokor‘u geliştirdim. Mevcut araçlardan hiçbirinin katılımcıları, hikayeleri veya oturum sayısını sınırlamadan veri saklama konusunu açıkça ortaya koymadığını gördüm. Temel yapı ücretsiz ve sınırsız. Aşağıda merak uyandırıcı olan bazı konular: gerçek zamanlı katman, dağıtım akışı, Docker yapılandırması ve birkaç entegrasyon hikayesi (bir acı verici, bir ise lanetli).

Neden Bunu Geliştirdim

Denediğim her planning poker aracı bir sınırlama taşıyordu. Ücretsiz olanlar katılımcıları, hikayeleri ya da oturumları sınırlarken, diğerleri veri nerede saklanıyor ve nasıl kullanılabilir sorularına gerçek bir cevap vermedi. Bu nedenle kendi şartlarımla kendi aracımı geliştirmeye karar verdim.

Ne Yapıyor?

Temel yapı gerçekten sınırsız ve ücretsiz: oturumlar, katılımcılar, hikayeler, N gün sonra otomatik silme yok.

İlk olarak geliştirdiğim bazı özellikler:

• Gerçek zamanlı oylama ile açığa çıkarma, yeniden oylama ve güven seviyeleri
• Asenkron oturumlar böylece insanlar sadece canlı değil, kendi zamanlarında da oy verebilirler
• Hikaye içe aktarma GitHub Issues, Jira, Notion ve CSV’den
• Slack ve Discord botları ile /pokor slash komutunu kullanarak oturumları sohbetten başlatma

Ücretli Organizatör planı, GitHub, Jira ve Notion ile iki yönlü senkronizasyon açar. Çoğu ekip ödemek zorunda kalmaz.

Teknoloji Yığını ve Sebepleri

Yığın yapısını basit tutmaya çalıştım. İlginç kısım, listedeki isimler değil, her bir parçanın işlevini tam anlamıyla yerine getirmesi.

• Laravel + Vue (Inertia, SSR ile). Inertia, backend’in yönlendirme ve kimlik doğrulama işlemlerini yönetmeye devam etmesini sağlıyor; frontend ise gerçek bir Vue SPA olarak kalıyor. Ayrı bir API katmanı yok, tekrarlanan DTO’lar yok, ancak planlama odası için normal bir SFC’ye geçiş yapabiliyorum. Sunucu tarafı render işlemi, aynı Docker görüntüsünden bir Node işlemi olarak çalışıyor, böylece her genel sayfanın ilk yüklemesi gerçek HTML olarak gerçekleşiyor. Bu, ilk yükleme hızı ve botlar için iyidir. Ayrıca, PHP yönlendirme tanımlarından TypeScript yönlendirme yardımcıları oluşturmak için Wayfinder kullanıyorum, böylece backend’de bir rotayı yeniden adlandırdığımda, her frontend çağrısı yapım zamanı hatası veriyor.

• FrankenPHP + Laravel Octane. Uygulama, istekler arasında bellekte kalıyor. Birisi “Açığa Çıkar” butonuna tıkladığında, her tarayıcının hemen güncellenmesini bekliyor. Klasik PHP-FPM’nin soğuk başlatma gecikmesi, “gerçek zamanlı” ile “yarı gerçek zamanlı” arasındaki farkı meydana getiriyor. Octane, hızlı yolları hızda tutar ve her kanal aboneliği için tetiklenen WebSocket kimlik doğrulama noktası darboğaz yaşamaz.

• Laravel Reverb WebSocket’ler için. Birinci taraf sunucu, Pusher uyumlu protokol. Yönetilen Pusher ve Soketi’yi değerlendirdim ve Reverb’i seçtim çünkü Pusher ile aynı protokolü kullanıyor, bu nedenle geçiş yapmak Bir ortam değişikliği ile mümkün. Ayrıca, uygulamanın veri kurumumdan çıkmaması anlamına geliyor. Planning poker aracı için, ürünün tamamı “insanların yazdığı şeyler ve oy verdikleri” olduğu için, bu benim için önemliydi.

• PostgreSQL. Amaçlı sıkıcı. İlginç sorgu desenleri, hikaye sıralaması ve açığa çıkarma geçmişi etrafında dönüyor ve Postgres’in pencere fonksiyonları, uygulama tarafında sıralama yapmadan her ikisini de kabul ediliyor.

• Redis, her ikisi de yük taşıyan iki işlemi yerine getiriyor:

  1. Laravel kuyruk, önbellek ve yayın arka planı (standart rol).
  2. Katılma talep onay kuyruk. Organizatör “katılmak için onay gerektir” seçeneğini etkinleştirdiğinde, misafir katılma talepleri hiç Postgres’e gitmiyor. Kısa bir TTL ile Redis’te yaşıyor ve her oturum için bir bekleyen küme var. Onayla veya reddetme bir yayın olayı tetikliyor ve talep kayboluyor. Schema migrasyonları yok, temizlik cron’u yok, oturum sona erdikten sonra kalan satırlar yok. Redis’in gerçekten en iyi olduğu durum bu ve Postgres kullanarak bunu başaramazdım.

Oturum Sayfası WebSocketlerle Dolu

Planlama odası, uygulamanın kalbi ve üzerindeki hemen hemen her etkileşim bir yayındır. Bir Reverb katılım kanalı üzerinden akışta birçok farklı olay türü var. Bunlar arasından bazıları:

• oy kullanıldı (herkes katıldığında açığa çıkarma tetikleyen bir işaretle)
• kartlar açığa çıkarıldı (her oyu, hesaplanan ortalamayı ve mantıkları içerir)
• oylama başlatıldı ve durduruldu
• hikaye değiştirildi
• katılımcı katıldı, ayrıldı, atıldı veya yeniden adlandırıldı
• rol değişti (terfi veya görevden alma)
• katılma talebi oluşturuldu ve çözüldü (yalnızca organizatör)
• emoji atıldı (evet, insanlara emoji atabilirsiniz)
• tahmin GitHub, Jira veya Notion’a senkronize edildi
• oturum modu ve ayarları değiştirildi

Frontend’de tek bir bileşen, varlık kanalına abone olup her olaya ismine göre dinliyor ve Pinia depolamasını güncelliyor, böylece planlama odasındaki her bileşen, prop geçişi ya da poling olmadan tepki veriyor. “Açığa çıkarma” işlemi, iki organizatörün aynı milisaniyede “Açığa çıkar” butonuna basmasını engellemek için satır düzeyi bir Postgres kilidi ile sarılı.

Dağıtım Akışı: Mavi-Yeşil ile Cerrahi Kesim

En çok gurur duyduğum şey dağıtım. Pokor, prodüksiyonda iki FrankenPHP Octane konteyneri (mavi ve yeşil) ile çalışıyor. Her dağıtımda:

1. Dağıtım script’i aktif slotu tespit eder.
2. Yeni bir Docker imajı oluşturur, kod, bağımlılıklar ve inşa edilmiş frontend varlıklarını içine alır. Yayımlama etiketi, slot harfi ve zaman damgası ile damgalanır böylece hangi slotun aktif olduğunu hemen görebilirim.
3. Composer kurulumları, migrasyonlar ve config önbelleklemesi, yedek konteynır içinde çalışır.
4. Yedek sağlık kontrolünden geçirilir.
5. Kesim işlemi, Caddy’nin admin API’sine yapılan tek bir çağrı ile gerçekleşir, eski slot ile yeni slot arasındaki geçiş gerçekleştirilir. Aktif istekler için kısa bir bekleme penceresi vardır.
6. Eski konteynır durur. Kuyruk, zamanlayıcı ve Reverb işçi süreçleri yeni görüntü üzerinde yeniden başlatılır.
7. Yeni yayımlama etiketi kaydedilir, bu da geriye dönük olarak bir önceki görüntüye karşı geri dönüş yapmayı bir komutla yapmamı sağlar.

Gerçekte sıfır duraklama. Yönetilen bir dağıtım hizmeti yok, üçüncü taraf bir orkestratör yok. Sadece Caddy’nin admin API’si ve bir bash script’i tek bir belirgin şeyi iyi yapan.

Docker: Başka Bir Sunucuya Dakikalar İçinde Geçiş

Pokor’un ihtiyaç duyduğu her şey tek bir compose dosyasında yaşıyor: Caddy, iki uygulama konteyneri, Reverb, kuyruk işçileri, zamanlayıcı, Postgres, Redis, hata takip aracı. Postgres ve Redis yalnızca localhost’a bağlanıyor, stack içinde gömülü durumda ve dışarıya açılmış değil. Yönetilen hiçbir şey yok, dış bağlantı yok, AWS konsolunda “önce bunu tıklayın” adımı yok.

Bu benim için somut olarak, başka bir sunucuya geçiş yapmam gerektiğinde, veri hacimlerini kopyalamak, ortam dosyalarını kopyalamak ve stack’i başlatmak demek. DNS’i yeniden yönlendirmek yok, beklemek yok – Cloudflare tüneli (aşağıda daha fazla bilgi) konteyneri takip ediyor, IP değil. Dakikalar, hafta sonu projesi değil. O taşınabilirlik kaza değildi; baştan itibaren tasarladığım bir kısıtlamaydı.

Cloudflare, Kenarda Ağır Yükleri Üstleniyor

Cloudflare, her şeyin önündedir ve üç şekilde fayda sağlıyor:

• TLS ve WAF. Caddy dahili olarak düz HTTP ile çalışır ve Cloudflare’ın IP aralıklarına güvenir. Tüm TLS, kenarda sonlanır ve dolayısıyla bot trafiği, konteynerlerime ulaşmadan önce durdurulur.
• Turnstile (Cloudflare’ın görünmez captcha işlevi) herkese açık formlarda – iletişim, bülten kaydı, herhangi bir kötüye kullanıma geçit açabilecek yerlerde çalışmaktadır. Her gönderim, sunucu tarafında yeniden kullanılabilir bir Laravel doğrulama kuralı aracılığıyla doğruladığım bir Turnstile belirteci ile gelir. “Bu bir insan mı?” sorusunu kendim yanıtlamak istemiyorum ve Turnstile çoğu zaman görünmez, bu benim istediğim tam olarak bu.
• cloudflared tünelleri herkese açık erişim yerine. Sunucuda internete bakan hiç açık port yok. İçeride bir cloudflared daemon’ı Cloudflare’a bağlanıyor ve trafiği bu tünel üzerinden geri hizmet veriyor. Bu da sunucu geçişini oldukça kolaylaştırıyor: tünel, Cloudflare hesabıma bağlı, sunucunun IP’sine değil, bu nedenle sunucu taşındığında DNS değişikliği yok, propagasyon yok, yeniden yönlendirme yok. Yeni sunucu başlatılır, tünel yeniden bağlanır, trafik devam eder.

Entegrasyon Hikayeleri

GitHub Issues: Kolay, genelde. GitHub’ın uygulaması ve OAuth modeli oldukça bilindik. İki aşamalı “uygulamayı yükleyin, ardından kullanıcıyı yetkilendirin” dansı bir kez rahatsız edici, sonra çalışır. Geri yazma ya bir yorum ya da etiket ön eki olarak gerçekleşiyor.

Notion: Ayrıca kolay. OAuth, veritabanlarını keşfetme, kullanıcıya tahmin alanını seçtirin, geri yazma. Notion API’si iyi tasarlanmış ve belgeler gerçeği yansıtıyor.

Slack ve Discord: “Organizatör olarak katıl” düğmesi ile geçici bir mesaj döndüren bir slash komutu. Her iki sağlayıcı da uygulama tarafında neredeyse birbirinin kopyası oldu, bu da hoş bir sürprizdi.

Jira / Atlassian: can sıkıcı. Dürüst olayım, Atlassian ile geçirdiğim zaman, sonraki üç entegrasyondan daha fazlaydı. OAuth akışı belki teoride iyi görünüyordu ama gerçek problemleri keşfetmeye başlayınca…

• Bir kullanıcı birden fazla Jira sitesine erişime sahip olabilir, bu nedenle yetkilendirme sonrası erişilebilir kaynakları almak, bir tane seçmesini sağlamak ve bu seçimi kalıcı hale getirmek gerekiyor.
• Story Points, sabit bir alan ID’sine sahip değil. Bu bir özel alan. Her Jira örneğinde ID farklıdır. “Bana hikaye puanı alanını ver” gibi bir son nokta yoktur.
• Doğru alanı bulsam bile, bağlanılan kullanıcı her issue türünde bu alana yazma iznine sahip olmayabilir.

Elde ettiğim şey, her projenin özel sayısal alanlarını puanlayan küçük bir sezgi sıralama sistemi oldu. Bilinen kanonik ID’ler üzerinden, tam ad eşleşmeleri ile “Hikaye Puanları” gibi ve puanlar veya tahminler gibi görünen her şeyden ağırlık katıldı. İkinci bir geçiş ise seçilen alanın yalnızca okunabilir değil, yazılabilir olup olmadığını kontrol ediyor. Ardından bir “bağlantıyı test et” düğmesi ile kullanıcı ayarları kaydetmeden önce görsün. Oraya ulaşmam bir süre aldı ama şimdi çalışıyor ve bunu denediğim her Jira kiracısında çalışıyor.

Microsoft Teams: Bunu eklemeyi gerçekten planladım. Slack ve Discord tamamlandı, Teams yine mantıklı bir sonraki adım. Azure portalını açtım ve… bunu nazikçe nasıl ifade ederim? Azure portalı, beni “Aktif Dizin”e götürecek her biri farklı bir şekle sahip, iç içe geçmiş kanatlardan oluşan bir fraktaldır. Birkaç saat boyunca tıkladım, doğru “Uygulama kayıtları” sayfasını bulmak için üç farklı şey buldum, hiçbiri değildi ve sonunda sekmeyi kapattım. Teams desteği, “Azure ile bir daha savaşmak için duygusal dayanıklılığım olduğunda” yol haritasında. Eğer bir Teams kullanıcısıysanız ve buna ihtiyacınız varsa, bana bildirin ve bir kahve demleyeceğim.

Sırada Ne Var?

Şu anda ilk kullanıcıları elde etmeye ve geri bildirim almaya odaklandım. Deneyimini yaşadıysanız ve bir şey normal gelmiyorsa (kırık akış, eksik entegrasyon, kafa karıştırıcı kopya) duyduğuma gerçekten çok sevinirim.

👉 pokor.dev

Okuduğunuz için teşekkürler.