GitHub Actions ile PHP Projesinde Otomatik Test Nasıl Çalıştırılır?

PHP projesinde testleri yalnızca kendi bilgisayarımda çalıştırdığımda, aceleyle açılan bir pull requestte kontrolü unutmak kolay oluyor. GitHub Actions ile her push ve pull requestte aynı test komutlarını otomatik çalıştırmak bu riski azaltıyor.

Proje içinde `.github/workflows/tests.yml` dosyası oluşturulabilir:

name: PHP Tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: PHP kurulumu
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          coverage: none

      - name: Composer cache
        uses: actions/cache@v4
        with:
          path: ~/.cache/composer/files
          key: composer-${{ runner.os }}-${{ hashFiles('**/composer.lock') }}

      - name: Bağımlılıkları kur
        run: composer install --no-interaction --prefer-dist

      - name: Testleri çalıştır
        run: vendor/bin/phpunit

Workflow’daki action sürümlerini güncel resmî sürümlerle takip etmek gerekiyor. Üçüncü taraf action kullanırken yayıncısını, izinlerini ve mümkünse sabit commit SHA kullanımını değerlendirmek güvenlik açısından önemli.

Laravel projesinde test için `.env.testing`, uygulama anahtarı ve veritabanı servisi gerekebilir. Basit testlerde SQLite kullanmak kurulumu hızlandırabilir. MySQL davranışına bağımlı sorgular varsa workflow’a service container eklemek daha doğru olur.

Dikkat ettiğim noktalar:

- Gerçek `.env` dosyasını repoya koymamak
- Hassas değerleri GitHub Secrets içinde saklamak
- Pull requestlerden gelen güvenilmeyen kodun secret erişimini sınırlamak
- `composer.lock` dosyasını uygulama projelerinde commit etmek
- Test yanında kod stili ve statik analiz adımları eklemek
- Cache bozulduğunda cache olmadan da kurulumun çalışmasını sağlamak

CI başarısızken merge’i engellemek için branch protection kuralı eklenebilir. Böylece test workflow’u zorunlu status check olur. Ancak testler çok yavaşsa ekip zamanla sistemi atlatmaya çalışır; hızlı unit testleri ve daha ağır entegrasyon testlerini ayırmak faydalı.

İlk aşamada onlarca karmaşık job yerine yerelde kullandığınız tek güvenilir komutu CI’a taşımak daha iyi sonuç veriyor.

Workflow dosyasını değiştiren pull requestlerin de dikkatli incelenmesi gerekiyor; CI yapılandırması secret ve yayın yetkilerine dokunabilir. Job izinlerini varsayılan olarak sınırlı tutmak, yalnızca gereken `contents`, `packages` veya deployment izinlerini açmak daha güvenlidir. Bağımlılık kurulumunun tekrarlanabilir olması için PHP extension listesini ve Composer sürüm beklentisini de workflow içinde açıkça tanımlamak yararlı olur.

Siz PHP projelerinde PHPUnit, Pest veya başka bir araç mı kullanıyorsunuz? GitHub Actions’ta en çok cache, veritabanı servisi veya secret yönetiminde mi zorlandınız?