Kod Kalite Kontrolleri: Laravel Pint ve PHPStan’ın Sürekli Entegrasyonda Kullanımı

Bir kod kalitesi kontrol mekanizması CI’ya eklendiğinde, ekibinizde sessiz bir değişim gerçekleşir. Geliştiriciler kod stili üzerine tartışmaktan vazgeçer, çünkü bu iş artık bir robot tarafından yapılmaktadır. Statik analiz hataları, kapıyı geçemedikleri için üretime ulaşamaz. Yeni hatalar hemen bloke edildiği için başkalarının teknik borçlarını miras almak da durur.

Son noktaya gelecek olursak, bu PHPStan alt seviye sihirbazlığı ile ilgilidir. Buna birazdan değineceğiz.

Kod Kalitesi Görevi

Bu görev her itme sırasında çalıştırılır ve dikkate değer şekilde hızlıdır — veritabanı yok, migrasyon yok, sadece PHP ve bir vendor klasörü:

  quality:
    name: Code Quality
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP 8.4
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.4'
          extensions: mbstring, pdo, bcmath, zip, intl
          coverage: none
          tools: composer:v2

      - name: Cache Composer dependencies
        uses: actions/cache@v4
        with:
          path: api/vendor
          key: php-8.4-composer-${{ hashFiles('api/composer.lock') }}
          restore-keys: php-8.4-composer-

      - name: Install dependencies
        run: composer install --no-interaction --prefer-dist --no-progress

      - name: Check formatting (Laravel Pint)
        run: ./vendor/bin/pint --test

      - name: Static analysis (PHPStan)
        run: ./vendor/bin/phpstan analyse --memory-limit=2G --no-progress

pint --test sadece okuma modunda çalışır — dosyaları değiştirmeden kontrol eder. Eğer herhangi bir dosya stil uyumsuzluğu varsa çıkış kodu 1 olur. Dosyaları otomatik olarak düzeltmek için ./vendor/bin/pint komutunu yerel ortamda (ve --test olmadan) çalıştırın.

PHPStan Yapılandırması

API kök dizininize bir phpstan.neon dosyası ekleyin:

parameters:
    level: 8
    paths:
        - app
        - Modules
    excludePaths:
        - vendor
    ignoreErrors:
        - identifier: missingType.iterableValue
        - identifier: missingType.generics

Seviye 8 katıdır. Yeni bir projede, ilk günden itibaren bu hedefle ilerleyin. Mevcut bir kod tabanında ise, seviye 4 ile başlayabilir ve kademeli olarak artırabilirsiniz.

Hafıza Problemi

Büyük bir kod tabanında PHPStan seviye 8 için 512MB’dan fazla RAM gerekir. CI’da --memory-limit=2G kullanın. Yerel ortamda, composer.json dosyanıza bir kısayol ekleyin:

"scripts": {
    "analyse": "php -d memory_limit=2G vendor/bin/phpstan analyse --no-progress"
}

Eski Kod Tabanları için Alt Seviye Hilesi

Karşılaştığım durumlardan biri: PHPStan seviye 8, 2.600 mevcut hatayı rapor ediyor. Hepsini tek bir PR içinde düzeltemezsiniz. Ancak seviye 8’i yoksayamazsınız — yeni hataları yakalamak için buna ihtiyacınız var.

Çözüm bir alt seviye dosyasıdır. Bu dosyayı bir kez oluşturursunuz. Mevcut hataları “kabul edildi” olarak kaydeder. Bu noktadan itibaren, herhangi bir yeni hata CI’yi başarısız kılarken, mevcut hatalar göz ardı edilir:

# Bir kez yerel olarak çalıştırın, sonucu işleyeceğinizi onaylayın
php -d memory_limit=2G vendor/bin/phpstan analyse --generate-baseline phpstan-baseline.neon

Daha sonra bunu phpstan.neon dosyanıza dahil edin:

includes:
    - phpstan-baseline.neon

parameters:
    level: 8
    paths:
        - app
        - Modules

phpstan-baseline.neon dosyasını işleyin. Artık: CI mevcut borçlar üzerinde geçer, yeni borçlar üzerinde başarısız olur. Eski hataları düzelttikçe, daha az girişle alt seviye dosyasını yeniden oluşturun. Sonunda buna ihtiyacınız kalmayacak.

Görevleri Sıralama: Kalite Önce Testler

needs: kullanarak sıralamayı zorunlu hale getirin:

  tests:
    name: Tests (PHP 8.4, MySQL 8.4)
    needs: quality   # bu satır
    runs-on: ubuntu-latest

Artık test görevi yalnızca kalite testi başarılıysa başlayacaktır. Bu CI için dakikalar kazandırır — stil kontrollerini geçemeyen bir kodun üzerinde 3 dakikalık bir test setini çalıştırmanın anlamı yoktur.

Bu Kapılar ile Geliştirici İş Akışı

Herhangi bir itmeden önceki yeni rutin:

# Stildeki sorunları otomatik olarak düzelt
./vendor/bin/pint

# Tip hatalarını kontrol et
php -d memory_limit=2G vendor/bin/phpstan analyse --no-progress

# Yerel olarak testleri çalıştır
php artisan test

# Artık itme yapabilirsiniz — CI bunu onaylayacaktır
git push origin feature/my-feature

Birkaç hafta sonra bu, kas hafızası haline gelir. Kalite kapısı, sizi yakalayan bir şey olmaktan çıkar ve bununla proaktif bir şekilde çalışmaya başlarsınız.

Bir sonraki yazıda, API anahtarları, veritabanı parolaları ve OAuth anahtarlarını CI içinde doğru bir şekilde nasıl kullanacağınızı ve hassas değerleri YAML dosyalarınıza asla koymadan nasıl yöneteceğinizi ele alacağız.

Orijinal yazı dineshstack.com‘da yayımlandı — kod örnekleri ve güncellemelerle tam sürümünü oradan okuyabilirsiniz.