PHP otomasyon sistemleri geliştirirken en sık karşılaşılan sorunlardan biri, sürekli değişen kod tabanını güvenilir şekilde canlıya almak ve mevcut işleyişi bozmamaktır. Manuel adımlarla yapılan dağıtımlar, yavaş ilerler ve insan hatasına açıktır. CI/CD süreçleri tam da bu noktada devreye girer: kodun her değişikliğinde otomatik test çalıştırma, derleme ve dağıtma imkânı sunar.

Bu yazıda, PHP otomasyon projelerinde CI/CD kurarken nelere dikkat etmeniz gerektiğini, hangi araçları seçebileceğinizi ve sık yapılan hatalardan nasıl kaçınacağınızı ele alacağız. Amacımız, yalnızca teorik bir çerçeve değil, gerçek hayatta işinize yarayacak pratik öneriler sunmak.

PHP Otomasyon Sistemlerinde CI/CD Neden Farklıdır?

PHP otomasyon sistemleri, tipik bir web uygulamasından farklı özellikler taşır. Çoğu zaman zamanlanmış görevler, kuyruk sistemleri veya arka planda çalışan süreçler içerirler. Bu süreçlerin doğru şekilde test edilmesi ve dağıtılması, normal bir web uygulamasından daha karmaşıktır.

Örneğin, bir e-posta pazarlama otomasyon aracı düşünün. Sistem, belirli saatlerde toplu e-posta gönderebilir, abonelikleri yönetebilir veya kullanıcı davranışlarını izleyebilir. Bu tür bir sistemdeki bir hata, sadece ekranda görünen bir hatadan çok daha büyük sonuçlar doğurabilir: yanlış e-posta gönderimi, veri kaybı veya zamanlanmış görevlerin çalışmaması gibi.

Bu yüzden CI/CD süreçlerini tasarlarken, PHP otomasyon sistemlerinin özel gereksinimlerini göz önünde bulundurmak gerekiyor. Sadece "herkes için geçerli" bir pipeline kurmak yerine, projenizin doğasına uygun çözümler üretmelisiniz.

Zamanlanmış Görevler ve Kuyruklar

Otomasyon sistemlerinin temelinde, zamanlanmış görevler (cron job) ve kuyruk tabanlı işlemler yer alır. CI/CD pipeline’ınızı kurarken bu bileşenlerin test ortamında da düzgün çalışıp çalışmadığını doğrulamanız gerekir. Örneğin, bir kuyruk işleyicisinin süpervisor ile yönetildiğini varsayalım. Bu durumda, pipeline’ınızda süpervisor yapılandırmasının test edilmesi ve dağıtım sonrası yeniden başlatılması gerekebilir.

Ayrıca, zamanlanmış görevlerin zaman dilimleri (timezone) hassas olabilir. CI/CD sürecinde bu ayarların doğru taşındığından emin olmak önemlidir. Aksi takdirde, test ortamında her şey çalışıyor gibi görünse de canlıda görevler yanlış saatlerde tetiklenebilir.

Ortam Yapılandırması ve Bağımlılıklar

PHP otomasyon sistemleri, farklı servislere bağımlı olabilir: veritabanı, Redis, Elasticsearch, üçüncü parti API’ler vb. Bu bağımlılıkların her ortamda benzer şekilde yapılandırılması, CI/CD sürecinin en kritik adımlarından biridir. Yapılandırma dosyalarını (örneğin .env) pipeline içinde güvenli şekilde yönetmek, sürprizleri önler.

Unutmayın: Bir otomasyon sistemi, bir web sitesine göre daha fazla arka plan işlemi içerdiği için, ortam farklılıkları çok daha hızlı kendini gösterir. Bu yüzden Docker ve docker-compose gibi araçlarla ortamın tekrarlanabilirliğini sağlamak sıklıkla tercih edilir. Örneğin, pipeline’ın test aşamasında Docker konteynerleri kullanarak tüm bağımlılıkları ayağa kaldırabilir, testlerinizi izole bir ortamda çalıştırabilirsiniz.

PHP İçin CI/CD Pipeline Kurulumunda Dikkat Edilmesi Gerekenler

CI/CD pipeline’ınızı kurarken birkaç temel aşamayı geçmeniz gerekir. Bu aşamaların her biri PHP otomasyon sistemleri özelinde farklı anlamlar taşır. İşte olmazsa olmaz adımlar:

• Kod Kalitesi Analizi: PHPStan veya Psalm gibi statik analiz araçlarıyla olası hataları erkenden yakalayın. Otomasyon projelerinde bu, çalışma zamanında ortaya çıkabilecek hataları minimize eder.
• Otomatik Testler: Birim testler, entegrasyon testleri ve uçtan uca testler ekleyin. Özellikle zamanlanmış görevlerin doğru tetiklendiğini test eden senaryolar yazın.
• Build ve Paketleme: Uygulamanızı, bağımlılıklarıyla birlikte dağıtılabilir bir pakete dönüştürün. Örneğin, Docker imajı oluşturmak, bağımlılıkların sürüm tutarlılığını sağlar.
• Dağıtım: Otomatik dağıtımı, önce staging ortamına yapın. Testler geçtikten sonra canlıya alın. Bu, canlıda sürpriz yaşanma ihtimalini azaltır.

Test Stratejisi Oluşturma

PHP otomasyon sistemlerinde test stratejisi, yalnızca "birim testleri yaz" demekten ibaret değildir. Öncelikle, otomasyon akışlarınızın hangi parçalarının kritik olduğunu belirlemelisiniz. Örneğin, bir entegrasyonun düzgün çalışıp çalışmadığını test etmek için sahte servisler (mock) kullanabilirsiniz. Ancak zamanlanmış görevlerin tam olarak doğru çalıştığını doğrulamak için bir entegrasyon testi gerekebilir.

Örnek vereyim: Bir otomasyon sisteminiz, her gece yarısı müşterilere rapor e-postası gönderiyor olsun. Bu görevi test etmek için, e-posta gönderimini sahte bir SMTP sunucusuna yönlendirecek bir yapı kurabilirsiniz. CI/CD pipeline’ında bu testi çalıştırarak, e-postanın doğru şablonda ve doğru alıcılara gittiğini doğrulayabilirsiniz. Ayrıca, kuyruk işleyicisinin belirli bir sayıda mesajı işleyip işlemediğini kontrol eden testler eklemek de faydalı olacaktır.

Dağıtım Sonrası Doğrulama (Post-Deployment Verification)

Canlıya aldıktan sonra her şeyin gerçekten çalıştığını doğrulamanız gerekir. Otomasyon sistemlerinde bu, bir web sayfasının yüklenmesinden daha karmaşıktır. Örneğin, sistemin kuyrukları işlemeye devam edip etmediğini, zamanlanmış görevlerin tetiklenip tetiklenmediğini kontrol etmelisiniz.

Bu nedenle pipeline’ınıza, dağıtım sonrası bir doğrulama adımı ekleyin. Basit bir örnek: sistemde bir health check endpoint’i tanımlayın ve bu endpoint üzerinden otomasyon durumunu sorgulayın. Ayrıca, logları izleyerek anormal bir durum olup olmadığını tespit edebilirsiniz. Eğer sisteminizde uyarılar (alerting) mekanizması varsa, bu adımı doğrulamak için kullanabilirsiniz.

PHP Otomasyon İçin Popüler CI/CD Araçları ve Seçim Kriterleri

Piyasada birçok CI/CD aracı bulunuyor. Hangisini seçeceğiniz, projenizin büyüklüğüne, ekibinizin deneyimine ve bütçenize bağlı. İşte PHP otomasyon sistemleri için en yaygın kullanılan araçlar:

Bu tablo, araçları kıyaslamak için size bir başlangıç noktası sağlar. Ancak en iyi araç, sizin ekosisteminize en uygun olanıdır. Örneğin, zaten GitLab kullanıyorsanız GitLab CI doğal bir tercih olabilir. GitHub üzerinde aktif olarak geliştirme yapıyorsanız GitHub Actions çok daha entegre çalışabilir.

Kendi Sunucunuza mı, Bulut Tabanlı Araç mı?

Kendi sunucunuzda Jenkins kurmak, tam kontrol sağlar ancak bakım yükü getirir. Bulut tabanlı araçlar, altyapı yönetimini üstlenir ve genellikle daha hızlı başlamanızı sağlar. PHP otomasyon projeleri için, özellikle zamanlanmış görevlerin yoğun olduğu sistemlerde, kendi sunucunuzda Jenkins kullanmak isteyebilirsiniz. Böylece pipeline içinde sunucunuza SSH ile bağlanıp dağıtım adımlarını daha esnek şekillendirebilirsiniz.

Öte yandan, bulut tabanlı araçlar çoğunlukla sınırlı erişim izinleri sunar. Örneğin, GitHub Actions’ta dağıtım yapmak için SSH anahtarlarını secrets olarak eklemeniz gerekir. Bu da güvenlik açısından iyi bir uygulamadır, ancak bazı özel durumlarda kendi sunucunuzdan çalışmak daha pratik olabilir.

Sık Yapılan Hatalar ve Kaçınma Yolları

PHP otomasyon sistemleri için CI/CD kurarken birçok ekip aynı hatalara düşer. Bu hataları bilmek, size zaman ve itibar kaybettirecek durumları önlemenize yardımcı olur.

Ortam Değişkenlerini Pipeline İçinde Doğrulamak

En sık yapılan hatalardan biri, ortam değişkenlerinin test ortamında doğru ayarlanmamasıdır. Örneğin, canlıda kullanılan API anahtarlarının test ortamında geçersiz olması, testlerin başarısız olmasına yol açar. Bu yüzden pipeline’da her aşama için ayrı ortam değişkenleri tanımlayın ve bunların doğru şekilde aktarıldığından emin olun.

Ayrıca, ortam değişkenlerini depolarken güvenliğe dikkat edin. CI/CD aracınızın secret yönetimini kullanın ve hassas bilgileri doğrudan pipeline dosyasına yazmayın.

Zamanlanmış Görevler İçin Gerçek Zamanlama Testleri Yapmak

Zamanlanmış görevler, test edilmesi en zor kısımlardan biridir. Bir cron ifadesinin doğru olduğunu düşünebilirsiniz, ancak saat dilimi veya gün ışığı tasarrufu gibi faktörler yüzünden yanlış çalışabilir. CI/CD pipeline’ına, zamanlanmış görevleri belirli bir zaman aralığında tetikleyerek doğrulayan bir test eklemek faydalı olacaktır. Örneğin, bir test ortamında gerçek zamanlı ayarlarla görevin bir kez çalışmasını sağlayın ve loglarını kontrol edin.

Bağımlılık Sürümlerini Dondurmak

PHP projelerinde Composer, bağımlılıkları yönetmek için standarttır. Ancak composer install komutu, composer.lock dosyasındaki sürümleri kullandığı için, bu dosyayı pipeline içinde korumalısınız. Bazı ekipler, pipeline’da composer update çalıştırarak bağımlılıkları sürekli günceller. Bu, beklenmeyen davranış değişikliklerine yol açabilir. Bu yüzden daima composer.lock dosyasını sürüm kontrolüne alın ve pipeline’da composer install kullanın.

Veritabanı Migrasyonlarını Güvenli Yönetmek

Otomasyon sistemleri, veritabanı yapısındaki değişikliklere bağlı olarak çalışabilir. Bu yüzden migrasyonları CI/CD sürecinin bir parçası yapmalısınız. Ancak dikkatli olmanız gereken nokta, migrasyon işlemleri sırasında veri kaybını önlemektir. Örneğin, canlıya almadan önce migrasyon işlemini staging ortamında test edin. Ayrıca migrasyonları geri almak (rollback) için bir planınız olsun.

PHP Otomasyon Sistemleri için Pipeline Örneği

Şimdi, somut bir örnek üzerinden ilerleyelim. Varsayalım ki bir PHP tabanlı raporlama otomasyonunuz var. Bu sistem, her gece yarısı müşterilerine özet raporlar gönderiyor. Ayrıca bir de kuyruk sistemi kullanıyor ve görevleri asenkron olarak işliyor. İşte bu sistem için bir GitLab CI pipeline örneği:

stages:
  - test
  - build
  - deploy

variables:
  MYSQL_ROOT_PASSWORD: "test"
  DB_HOST: "mysql"
  DB_DATABASE: "automation_db"

services:
  - mysql:8.0

before_script:
  - apt-get update -yqq
  - apt-get install -yqq git curl libmcrypt-dev libjpeg-dev libpng-dev libfreetype6-dev libxml2-dev
      zlib1g-dev libzip-dev unzip openssl
  - docker-php-ext-install pdo_mysql mysqli zip
  - curl -sS https://getcomposer.org/installer | php
  - mv composer.phar /usr/local/bin/composer
  - composer install --no-interaction --prefer-dist

test:unit:
  stage: test
  script:
    - php vendor/bin/phpunit --testsuite Unit
  only:
    - merge_requests
    - main

test:integration:
  stage: test
  script:
    - php artisan migrate --database=mysql_test
    - php vendor/bin/phpunit --testsuite Integration
  services:
    - mysql:8.0
  variables:
    DB_DATABASE: "automation_test"

deploy:staging:
  stage: deploy
  script:
    - echo "Deploying to staging server..."
    - ssh user@staging 'cd /var/www/automation && git pull origin main && composer install --no-dev --optimize-autoloader && php artisan migrate --force && php artisan queue:restart'
  environment:
    name: staging
  only:
    - main
  when: delayed
  start_in: 1 minute

deploy:production:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - ssh user@production 'cd /var/www/automation && git pull origin main && composer install --no-dev --optimize-autoloader && php artisan migrate --force && php artisan queue:restart'
  environment:
    name: production
  only:
    - main
  when: manual

Bu örnekte dikkat edilmesi gereken bazı noktalar var:

• Unit ve integration testleri ayrı aşamalarda çalıştırılıyor. Integration testleri için ayrı bir veritabanı kullanılıyor.
• Staging dağıtımı, main branch’e push sonrası 1 dakika gecikmeli tetikleniyor. Bu, pipeline’ı gözlemleme fırsatı verir.
• Production dağıtımı manuel tetikleniyor. Böylece ekip üyeleri onay vermeden canlıya alınmaz.
• Dağıtım sonrası queue:restart komutu ile kuyruk işleyicileri yeniden başlatılıyor. Bu sayede yeni kod anında çalışmaya başlıyor.

Bu örnek, kendi projenize uyarlayabileceğiniz bir başlangıç noktasıdır. Kullanılan komutlar, projenizin yapısına göre değişir. Önemli olan, sürecin otomatik ve tekrarlanabilir olmasıdır.

Sonraki Adım: Pipeline’ınızı Sürekli İyileştirmek

CI/CD süreci bir kez kurulduktan sonra bitmez; sürekli iyileştirilmesi gerekir. İlk kapsamınız temel testler ve dağıtımdan ibaret olsa da, zamanla daha fazla adım ekleyerek süreci zenginleştirebilirsiniz.

Örneğin, güvenlik taraması (security scan) adımı ekleyebilir, Composer bağımlılıklarınızdaki bilinen açıkları kontrol edebilirsiniz. Ayrıca, kod formatını kontrol eden ve sürekli entegrasyonun bir parçası olan bir adım da ekleyebilirsiniz.

Bunun yanında, dağıtım sonrası doğrulama adımlarınızı genişletmek de faydalı olur. Örneğin, canlıya aldıktan sonra otomatik olarak bazı senaryoları çalıştıran bir smoke test ekleyebilirsiniz. Bu, sistemin temel işlevlerinin bozulmadığını hızlıca doğrular.

Unutmayın: CI/CD’nin asıl amacı, yazılım geliştirme sürecini hızlandırmak ve hataları erkenden yakalamaktır. Bu yüzden pipeline’ınızı sadeleştirin ve gereksiz adımlardan kaçının. Her eklediğiniz adım, ekstra bir bakım yükü getirir. Bu dengeyi kurmak, uzun vadede başarılı bir otomasyon sürecinin anahtarıdır.