CI/CD ile Standart Denetimi
phpcs'yi yalnızca bir geliştiricinin kendi makinesinde çalıştırmak, sürecin önemli bir kısmını o geliştiricinin inisiyatifine bırakır — aynı kontrolleri CI/CD'ye taşımak, onları bir ekip genelinde gerçekten tutarlı hale getiren şeydir.
1. Lokal Kontroller Neden Yetmiyor
Lokal bir kontrol atlanması, unutulması ya da yanlışlıkla yanlış kural setine karşı çalıştırılması kolay bir şeydir. Her merge request'te CI/CD içinde otomatik olarak çalışan bir kontrolde bu sorun yoktur. Kodu kimin push ettiğinden ya da önce ne yapmayı hatırladığından bağımsız olarak hep aynı şekilde çalışır.
2. Örnek Bir Pipeline
Minimal bir pipeline aşaması, lokalde kullanılanla aynı standartlara karşı phpcs'yi çalıştırır ve bir ihlal bulursa build'i başarısız kılar.
phpcs:
stage: test
script:
- vendor/bin/phpcs --standard=Drupal,DrupalPractice web/modules/custom3. PHPStan ve Testleri Eklemek
Aynı pipeline, PHPStan'in ve projenin otomatik testlerinin de çalışması için doğal bir yerdir — her biri kendi aşaması olarak, her biri build'i bağımsız olarak başarısız kılabilecek şekilde; bu da belirli bir çalıştırmayı hangi problem kategorisinin bozduğunu bir bakışta anlaşılır kılar.
stages:
- test
phpcs:
stage: test
script:
- vendor/bin/phpcs --standard=Drupal,DrupalPractice web/modules/custom
phpstan:
stage: test
script:
- vendor/bin/phpstan analyse web/modules/custom
phpunit:
stage: test
script:
- vendor/bin/phpunit4. Merge'ü Engellemek
Pipeline işini yalnızca başarısız bir aşama merge'ü gerçekten engellediğinde yapar — bilgilendirici değil, zorunlu bir status check olarak yapılandırılmış olması gerekir, öyle ki üzerinden geçilerek merge edilemesin. Bu bir kez yerine oturduğunda, standarda uymayan kod ana branch'e en başta hiç ulaşmaz; bu, sorunu review sırasında yakalamaktan çok farklı bir garantidir.
5. Daha Erken Bir Katman Olarak Pre-commit Hook'ları
Yalnızca staged dosyalara karşı phpcs'yi çalıştıran bir pre-commit hook, CI/CD değişikliği görmeden önce bir katman daha ekler — bir ihlali commit edildiği anda yakalamak, bir pipeline çalıştırmasını beklemekten daha kısa bir geri bildirim döngüsüdür, ama CI/CD'nin yerini tutmaz, çünkü bir hook lokalde her zaman --no-verify ile atlanabilir.