4 GitHub Actions Deseni: Monorepo ETL
Tek bir monorepo üzerinden üç site çalıştırmak sorunlar yaratır. Karşınıza üç ayrı ETL işi, üç içerik yeniden oluşturma (rebuild) işlemi ve üç dağıtım (deployment) hattı çıkar. Eğer bunları koordine etmezseniz, birbirleriyle çakışırlar.
Bu kurulumu stabilize etmek için programları test ederek altı hafta harcadım. İşte kullandığım dört yöntem.
- Cron İşleri İçin Zaman Kaydırmaları (Time Offsets) Kullanın
Tüm ETL işlerini aynı anda çalıştırmak hatalara neden olur. İşler, API hız sınırları (rate limits) için yarışır. HuggingFace veya GitHub 429 hatası döndürdüğünde, çalışma başarısız olur.
Bunu önlemek için 30 dakikalık zaman kaydırmaları kullanıyorum.
- Birinci iş 02:00'de başlar
- İkinci iş 02:30'da başlar
- Üçüncü iş 03:00'te başlar
Otuz dakika, bir sonraki iş başlamadan önce ağır bir veri çekme (pull) işlemini bitirmek için yeterli bir süredir. Bu, günlüklerinizi (logs) temiz tutar ve API çakışmalarını önler.
- Gereksiz Yeniden Oluşturmaları Durdurmak İçin Atlama Bayrakları (Skip Flags) Kullanın
Her ETL işi bir Vercel dağıtımı ile sona erer. Makale commit'lerinin de yeniden oluşturmaları tetiklemesi bir sorun yaratır. Bir planınız yoksa, her makale güncellemesi üç sitenin de yeniden oluşturulmasını zorunlu kılar. Bu da derleme (build) dakikalarını boşa harcar.
ETL commit mesajlarında [skip publish-articles] etiketi kullanıyorum.
İş akışıma (workflow) bu bayrağı kontrol eden bir adım ekledim. Eğer etiket mevcutsa, iş akışı derleme ve dağıtım adımını atlar. Bu, ETL hatlarını makale hatlarından ayrı tutar.
- Belirli Siteleri Hedeflemek İçin Yol Filtreleri (Path Filters) Kullanın
Bir sitenin güncellemesinin üç dağıtımı tetiklemesini istemezsiniz. Her sitenin iş akışını, yalnızca kendi klasörünü ve paylaşılan paketler (shared packages) klasörünü izleyecek şekilde yapılandırıyorum.
Örnek mantık:
- AI araçları sitesi yalnızca apps/ai-tools/ klasörünü izler
- OSS sitesi yalnızca apps/oss-alternatives/ klasörünü izler
Paylaşılan dizindeki kodu değiştirirseniz, tüm siteler yeniden oluşturulacaktır. Paylaşılan kod değişiklikleri nadir olduğu için bu ödünlemi (trade-off) kabul ediyorum.
- Kontrol İçin Manuel Tetikleme (Manual Dispatch) Ekleyin
Cron günlük rutini yönetir. Manuel tetikleme ise geri kalan her şeyi halleder. Şunları yapabilmek için workflow_dispatch kullanıyorum:
- Başarısız olan bir ETL işini yeniden çalıştırmak
- Veri ekledikten sonra yenilemeyi zorlamak
- Veritabanına yazmadan verileri test etmek için bir kuru çalışma (dry run) gerçekleştirmek
GitHub arayüzü (UI) bu seçimler için bir açılır menü gösterir. Bu, yazım hatalarını önler ve hata ayıklamayı (debugging) kolaylaştırır.
Özet
Bu yöntemler karmaşık değildir; belirgindirler. Bu kuralları belgelemek için depomda (repository) basit bir markdown dosyası tutuyorum. Bu, yeni iş akışları eklediğimde sistemi bozmamamı sağlar.