Küçük Ekipler İçin CI/CD: GitHub Actions ile Laravel ve Flutter Hattı

Küçük ekiplerde dağıtım çoğu zaman bir kişinin hafızasında yaşar: "önce şu komutu çalıştır, sonra sunucuya bağlan, cache'i temizlemeyi unutma." O kişi izne çıktığında ya da bir adımı atladığında canlıya hatalı sürüm gider. Bu yazıda, ekibi büyütmeden ve pahalı araçlara girmeden GitHub Actions ile Laravel backend ve Flutter mobil uygulama için nasıl sade bir dağıtım hattı kurduğumuzu anlatıyoruz.

Önce hattın amacını küçük tutun

İlk hedef her şeyi otomatikleştirmek değil, hatalı kodun ana dala girmesini engellemek. Bunun için iki aşama yeter: her pull request'te test ve statik analiz, ana dala birleşince dağıtım. İş akışı dosyalarınız .github/workflows/ klasöründe durur ve on: pull_request ile on: push tetikleyicileriyle ayrılır. Hat sade başlarsa ekip onu benimser; ilk günden karmaşık kurulan hat ise "bozuk" diye devre dışı bırakılır.

Laravel tarafı: test, derleme, dağıtım

PHP ortamını kurmak için shivammathur/setup-php, kodu almak için actions/checkout kullanıyoruz. Bağımlılıkları composer install --no-interaction --prefer-dist ile kurup php artisan test çalıştırıyoruz; testlerde veritabanı için SQLite bellek içi ya da hat içinde ayağa kalkan bir MySQL servisi seçilebilir. Composer önbelleğini actions/cache ile saklamak süreyi belirgin biçimde kısaltır.

Dağıtımda en güvenilir yöntem, sürüm klasörleri ve sembolik bağdır. Yeni sürüm ayrı bir klasöre açılır, composer install --no-dev --optimize-autoloader çalıştırılır, ardından php artisan migrate --force ve php artisan config:cache adımları uygulanır. Hepsi hazır olunca current bağı yeni klasöre çevrilir ve php artisan queue:restart ile kuyruk işçileri yeni kodu yükler. Bir sorun çıkarsa bağı eski klasöre geri çevirmek saniyeler sürer.

Flutter tarafı: analiz, test, imzalı derleme

Flutter için subosito/flutter-action ile SDK kurulur. Her pull request'te flutter analyze ve flutter test çalışır. Ana dala birleşen sürümlerde ise flutter build appbundle ile Android paketi üretilir. İmzalama anahtarını depoya koymak yerine base64'e çevirip bir secret olarak saklıyor, hat içinde dosyaya geri çözüyoruz. iOS tarafında flutter build ipa macOS runner ister ve sertifika yönetimi ayrı bir konudur; küçük ekipler için önce Android hattını oturtmayı, iOS'u sonra eklemeyi öneriyoruz.

Sırlar, ortamlar ve onay

• Sunucu SSH anahtarı, imza anahtarı ve API anahtarlarını depo ya da ortam secrets alanında tutun, iş akışı dosyasına yazmayın.
• Canlı dağıtımı bir environment tanımına bağlayın ve gerekirse zorunlu onaylayıcı ekleyin.
• Aynı anda iki dağıtımın çakışmaması için concurrency grubu kullanın.
• Dağıtım kullanıcısına sunucuda yalnızca gereken klasörlere yazma yetkisi verin.
• Başarısız adımda hattın durmasını sağlayın; hatayı yutan || true alışkanlığından kaçının.

Sahada öğrendiklerimiz

En sık yaşadığımız sorun hattın yavaşlaması oldu. Çözümü genellikle önbellek, gereksiz adımların kaldırılması ve testlerin paralel çalıştırılması. İkinci sorun, hattın "yeşil" olduğu hâlde canlının bozuk olması. Bunu dağıtım sonrası basit bir sağlık kontrolüyle yakalıyoruz: dağıtımdan sonra bir /health ucuna istek atıp beklenen yanıt gelmezse bağı eski sürüme çeviriyoruz. Üçüncüsü veritabanı göçleri: geri alınması zor bir migration'ı dağıtım hattına bırakmak yerine, önce geriye uyumlu hâle getirip iki aşamada uygulamak çok daha güvenli. Son olarak hattı belgeleyin: iş akışı dosyası zaten bir belgedir, ama hangi secret'ın ne için olduğunu ve geri dönüşün nasıl yapıldığını kısa bir not olarak depoya eklemek, yeni gelen geliştiricinin ilk gününü kurtarır.

Ekibiniz için bir dağıtım hattı kurmak, mevcut elle dağıtım sürecini otomatiğe taşımak ya da Laravel ve Flutter projelerinizi güvenle yayına almak isterseniz iletişim sayfamızdan bize yazın. Yıllardır yürüttüğümüz projelerde şunu gördük: iyi kurulmuş küçük bir hat, ekibin cuma akşamı yayın yapma korkusunu gerçekten ortadan kaldırıyor.