Yeni Başlayanlar için Laravel Dağıtımı: Dağıtım Butonuna Tıkladığınızda Gerçekte Ne Olur

Laravel uygulamanızı haftalarca dizüstü bilgisayarınızda geliştiriyorsunuz. Her şey localhost‘ta mükemmel çalışıyor. Özellikler tamam, sayfalar harika görünüyor ve testler geçiyor. Şimdi, uygulamanızı internete taşıma zamanı geldi, gerçek kullanıcıların kullanabilmesi için. “Deploy” butonuna tıklıyorsunuz, bir ilerleme çubuğu doluyor ve 60 saniye sonra uygulamanız yayında.

Peki, bu 60 saniye içinde ne oldu? Deploynix, kodunuzu GitHub reposundan alıp gerçek bir web sitesine dönüştürmek için ne yaptı? Dağıtım sürecini anlamak, web geliştirme alanındaki en korkutucu kısımlardan birini çözmenin yoludur. Neler olup bittiğini öğrendikten sonra, dağıtımlar sıklıkla yapılan bir işlem haline gelir ve korkutucu olmaktan çıkar.

Bu kılavuz, bir Laravel dağıtımının her adımını sade bir dille ele alıyor. Hiçbir teknik jargon yok, deneyim seviyenizle ilgili varsayımlar yok. Eğer bir Laravel uygulaması geliştirebiliyorsanız, dağıtım sürecini de anlayabilirsiniz.

Dağıtımdan Önce: Sunucunuzun Görünümü

Uygulamanızı dağıtmadan önce, Deploynix sunucunuzu Laravel’in çalışması için gerekli şekilde ayarlamıştır. Sunucunuzu, her zaman açık, internete bağlı olan ve web sitenizi sunmayı bekleyen bir veri merkezindeki bilgisayar olarak düşünebilirsiniz.

Deploynix sunucuyu provision ederken, şunları kurar ve yapılandırır:

• İşletim sistemi: Web sunucuları için en yaygın olan Ubuntu Linux.
• PHP: Laravel’in yazıldığı programlama dili. Deploynix, uygulamanızın ihtiyaç duyduğu kesin sürümü kurar.
• Web sunucusu (Nginx): Gelen web isteklerini dinleyip Laravel uygulamanıza yönlendiren yazılım. Birisi tarayıcısına alan adınızı yazdığında, Nginx yanıt veren ilk yazılımdır.
• Veritabanı (MySQL, MariaDB veya PostgreSQL): Uygulamanızın kullanıcı hesapları, gönderiler, siparişler gibi verileri sakladığı yerdir.
• Composer: PHP bağımlılıklarınızı yöneten araç; Laravel uygulamanızda kullanılan paketler ve kütüphaneler.
• Node.js ve npm: Ön uç varlıklarınızın derlenmesi için kullanılan araçlar, tarayıcının sayfalarınızı görüntüleyebilmesi için gerekli CSS ve JavaScript gibi.

Bütün bu yapılandırmalar bir kez, sunucu ilk kez provision edildiğinde gerçekleşir. Sonrasında, uygulamanızı dağıtmak, kodunuzu bu sunucuya aktarıp çalışacak şekilde yapılandırmaktır.

Adım 1: Kodunuzu GitHub’dan Alma

Deploy butonuna tıkladığınızda ilk olarak olan şey, Deploynix’in uygulamanızın kodunu Git deposundan (GitHub, GitLab veya Bitbucket) sunucunuza kopyalamasıdır.

Her seferinde değişiklik yaptığınızda kodunuzu repoya gönderiyorsunuz. Reponuz, uygulamanızın tüm bileşenlerini içerir: PHP dosyaları, Blade şablonları, JavaScript, yapılandırma dosyaları ve migration dosyaları. Bu, uygulamanızın herhangi bir anda neye benzediğinin tek gerçek kaynağıdır.

Deploynix, reposunuza bağlanır ve kodunuzun en son sürümünü sunucuya indirir. Bu, dizüstü bilgisayarınızda git clone komutunu çalıştırmaya benzer; tek fark, Deploynix bunu sunucuda yapıyor.

Fakat burada önemli bir ayrıntı var: Deploynix, her seferinde kodu aynı klasöre yerleştirmiyor. Her dağıtım için tamamen yeni bir klasör oluşturur. Eğer bugün beşinci dağıtımınızsa, sunucunuzda her biri kodunuzun ayrı bir sürümüne karşılık gelen beş ayrı klasör olacaktır. Bunu neden önemli olduğunu daha sonraki adımda açıklayacağız.

Adım 2: PHP Bağımlılıklarını Kurma

Laravel uygulamanız, diğer geliştiriciler tarafından yazılan onlarca pakete bağımlıdır. Laravel çerçevesi, veritabanı sürücüsü, kimlik doğrulama sistemi ve composer require ile eklediğiniz diğer paketler gibi şeylerdir. Bu bağımlılıklar composer.json dosyanızda listelenir ancak Git reposunda saklanmaz ( vendor klasörü .gitignore‘dadır).

Kodunuzu indirdikten sonra, Deploynix sunucuda composer install komutunu çalıştırır. Bu, composer.json ve composer.lock dosyalarınızı okuyarak, uygulamanızın ihtiyaç duyduğu her paketi indirir ve bunları vendor klasörüne yerleştirir.

Bu adım, composer.lock dosyasını kullanır; sadece composer.json‘yu değil. Lock dosyası, geliştirme makinenizde kurulu olan her paketin tam sürümünü kaydeder. Bu, sunucunun denediğiniz sürümlerin aynısını kurmasını garanti eder; daha yeni sürümler farklı davranabilir. Geliştirme ortamı ve üretim arasındaki tutarlılık kritik önem taşır.

Üretimde, Deploynix Composer’a --no-dev bayrağını geçirir. Bu, geliştirme için gerekli olan bağımlılıkların atlanmasını sağlar. Örneğin, Pest (test çerçeveniz) ve Laravel Pint (kod biçimlendiriciniz) üretim sunucusunda gerekli değildir, bu yüzden atlamak, kurulumu daha hızlı ve uygulamayı daha hafif hale getirir.

Adım 3: Ön Uç Varlıkları Kurma ve Derleme

Eğer uygulamanız Tailwind CSS, Alpine.js veya npm aracılığıyla yönetilen diğer ön uç araçlarını kullanıyorsa, bir sonraki adım bu JavaScript bağımlılıklarını kurmak ve varlıklarınızı derlemek olacaktır.

Deploynix, npm install (veya npm ci) komutunu çalıştırarak package.json dosyanızda listelenen JavaScript paketlerini indirir. Ardından, her şeyi tarayıcıların anlayabileceği son CSS ve JavaScript dosyalarına dönüştürmek için npm run build komutunu çalıştırır.

Geliştirme sırasında npm run dev komutunu çalıştırıyor olabilirsiniz; bu, dosya değişikliklerini izler ve anlık derleme yapar. Üretimde, npm run build optimizasyon ve minifikasyon yaparak varlıklarınızın son versiyonlarını oluşturur. Minifikasyon, boşlukları kaldırır, değişken adlarını kısaltır ve dosyaları mümkün olduğunca küçük hale getirir. Daha küçük dosyalar, kullanıcılarınız için daha hızlı sayfa yüklemeleri anlamına gelir.

Derlenmiş dosyalar genellikle public/build klasörüne yerleştirilir. Bu, Nginx’in tarayıcılara CSS ve JavaScript dosyalarını doğrudan sunacağı dosyalardır.

Adım 4: Ortam Dosyasını Ayarlama

Laravel uygulamanız bir .env dosyası kullanır; bu dosya, ortamlar arasında değişkenlik gösteren yapılandırmaları saklar. Dizüstü bilgisayarınızda, .env dosyası yerel veritabanınıza işaret eder, local uygulama ortamını kullanır ve ayrıntılı hata mesajları gösterir. Üretimde, yapılandırma farklıdır.

Deploynix, üretim ortamı değişkenlerinizi kontrol paneli aracılığıyla yönetir. Veritabanı kimlik bilgileri, uygulama anahtarları, mail sunucusu ayarları ve uygulamanızın ihtiyaç duyduğu API anahtarları gibi değerleri belirlersiniz. Deploynix bunları güvenli bir biçimde saklar ve bunları sunucudaki .env dosyasına ulaştırır.

Sizin yerel .env dosyanız ile üretim .env dosyanız arasındaki bazı önemli farklılıklar:

• APP_ENV değeri production olarak ayarlıdır, local değil.
• APP_DEBUG değeri false olarak ayarlanmıştır, böylece hata ayrıntıları kullanıcılara gösterilmez. Geliştirmede, tam hata izini görmek faydalıdır, ancak üretimde hassas bilgileri açığa çıkarmak istemezsiniz.
• APP_URL gerçek alan adınıza işaret eder, localhost değil.
• Veritabanı kimlik bilgileri üretim veritabanı sunucunuza işaret eder.
• APP_KEY Laravel’in çerezleri, oturumları ve diğer hassas verileri şifrelemesi için kullandığı benzersiz bir anahtardır.

.env dosyası asla Git reposunda saklanmaz ( .gitignore‘dadır). Bu kasıtlıdır. Üretim veritabanı parolalarının kod repolarınızda bulunmasını istemezsiniz.

Adım 5: Veritabanı Migrations’larını Çalıştırma

Uygulamanızın veritabanı başlangıçta boştur. Veritabanınızın yapısı (tablolar, sütunlar, indeksler) migration dosyalarında tanımlanır. Migrations’lar, database/migrations klasöründeki her bir veritabanı şeması değişikliğini açıklayan PHP dosyalarıdır.

Deploynix uygulamanızı dağıttığında, php artisan migrate komutunu çalıştırarak yeni migration’ları uygular. Bu komut, hangi migration’ların henüz çalıştırıldığını kontrol eder (Laravel, bunu veritabanınızdaki özel bir migrations tablosunda takip eder) ve sadece yeni olanları çalıştırır.

Örneğin, önceki dağıtımınızda 15 migration varsa ve 16. bir migration eklediyseniz (kullanıcılar tablosuna phone_number sütunu ekleyebilirsiniz), migrate komutu yalnızca o 16. migration’ı çalıştıracaktır. Diğer 15’i zaten veritabanında bulunmaktadır.

Migrations, dosya adlarındaki zaman damgalarına göre sırayla çalıştırılır. Bu, veritabanı yapısının öngörülebilir ve tutarlı bir şekilde evrimleşmesini garanti eder, ister ilk kez dağıtım yapıyor olun, ister yüzüncü kez.

Bu adım, hatalar meydana gelirse sorun yaratabilecek ender dağıtım süreçlerinden biridir. Bir migration yarıda kalırsa, veritabanınızı tutarsız bir durumda bırakabilir. Bu nedenle, dağıtım öncesi migration’larınızı iyice test etmek önemlidir.

Adım 6: Yapılandırma, Yollar ve Görünümleri Önbelleğe Alma

Laravel, özelliklerle dolu bir çerçeve olduğundan, her istekte tüm yapılandırma, yollar ve görünümleri sıfırdan yüklemek zaman alır. Uygulamanızı üretimde daha hızlı hale getirmek için, Deploynix birkaç önbellekleme komutunu çalıştırır:

• php artisan config:cache komutu, tüm yapılandırma dosyalarınızı tek bir önbelleğe alınmış dosyaya derler. Laravel, her istekte onlarca yapılandırma dosyası okumak yerine bir dosya okur.
• php artisan route:cache komutu, rota tanımlarınızı daha hızlı yüklenebilen bir formata dönüştürür. Eğer birden fazla rota varsa, bu belirgin bir fark yaratır.
• php artisan view:cache komutu, Blade şablonlarınızı önceden derler. Normalde, Laravel Blade şablonlarını ilk kez talep edildiğinde derler. Onları önceden önbelleğe almak, herhangi bir sayfayı ziyaret eden ilk ziyaretçinin, bininci ziyaretçiyle aynı hızlı yanıtı almasını sağlar.

Bu önbellekler her dağıtımda yeniden oluşturulur, böylece her zaman en son kodunuzu yansıtır.

Adım 7: Symlink Değişimi (Sıfır Duraklama Sihri)

Deploynix’in her dağıtım için yeni bir klasör oluşturduğunu söyledik, işte burada bunun nedenini anlamış oluyorsunuz.

Web sunucunuz (Nginx), uygulamanızı belirli bir yol üzerinden sunacak şekilde yapılandırılmıştır; örneğin, /home/deploynix/yoursite.com/current. Ancak current sıradan bir klasör değildir. O bir symlink (sembolik bağlantı) olup, başka bir klasöre işaret eden bir kısayoldur.

Şu anda current, önceki dağıtımınızın kodunun bulunduğu klasöre işaret eder. Daha önce tartıştığımız adımlar (kod indirme, bağımlılıkları kurma, migration’ları çalıştırma) tamamen yeni bir klasörde gerçekleşmiştir. Uygulamanızın önceki sürümü, tüm zaman dilimi boyunca, kullanıcılarınıza kesintisiz bir şekilde hizmet vermektedir.

Yeni klasördeki her şey hazır olduğunda, Deploynix current symlink’ini yeni klasöre işaret edecek şekilde günceller. Bu değişim atomik bir işlem olup, tek bir anda gerçekleşir. Bir anda, Nginx eski kodu sunmakta. Bir sonraki anda, yeni kodu sunmaya başlamaktadır. Kesintisiz bir süreç vardır; uygulamanızın kapalı olduğu bir an ya da kısmi eski-yeni durum yoktur.

Bu, “sıfır duraklama ile dağıtım” demektir. Kullanıcılarınız, dağıtım sırasında bir hata sayfası ya da yüklenme işareti görmeyecek. Yeni uygulama sürümünüzü sorunsuz bir şekilde görmeye başlayacaklar.

Eski dağıtım klasörleri bir süre saklanır ki gerekirse geri dönmek mümkün olsun. Yeni dağıtımla ilgili bir sorun çıkarsa, Deploynix symlink’i anında önceki klasöre geri döndürebilir.

Adım 8: İşçi ve Servisleri Yeniden Başlatma

Laravel uygulamanızın bazı bölümleri, yalnızca bir kullanıcı sayfayı ziyaret ettiğinde değil, arka planda sürekli olarak çalışır.

Queue workers arka planda çalıştırmak için sıraya alınmış işleri işlemektedir. Örneğin, e-postalar göndermek, yüklenen görüntüleri işlemek ya da raporlar oluşturmak gibi işlerdir. Bu işçiler, başladıklarında uygulama kodunuzu belleğe yükler ve durduruluncaya kadar çalışmaya devam ederler.

Dağıtım sonrası, kuyruk işçileriniz hâlâ eski kodun sürümünü çalıştırmaktadır. Deploynix, yeni kodu alabilmeleri için bunları yeniden başlatır. Bu yeniden başlatma, mevcut işi tamamladıktan sonra yapılır; herhangi bir iş kaybolmaz veya kesintiye uğramaz.

Cron işleri (zamanlanmış görevler), Laravel’in görev zamanlayıcısı tarafından yönetilmektedir. Uygulamanızda tanımlı zamanlanmış komutlar varsa, bunlar sunucunun düzenine göre devam eder. Bir sonraki zamanlanmış görev çalıştığında, otomatik olarak yeni kodu kullanır, çünkü current symlink’i üzerinden çalışır.

Adım 9: Uygulamanız Yayında

Tüm bu adımlar tamamlandıktan sonra, uygulamanız yayında ve kodunuzun en son sürümünü sunmaya hazır. Tüm süreç genelde 30 ile 90 saniye arasında sürer, bu süre uygulamanızın boyutuna ve bağımlılık sayısına bağlıdır.

İşte olanların özeti:

1. Kodunuz GitHub’dan sunucuya yeni bir klasöre indirildi.
2. PHP bağımlılıkları Composer ile kuruldu.
3. Ön uç varlıkları npm ile derlendi.
4. Ortam yapılandırması uygulandı.
5. Yeni veritabanı migration’ları çalıştırıldı.
6. Yapılandırma, yollar ve görünümler önbelleğe alındı.
7. Symlink yeni koda işaret edecek şekilde değiştirildi.
8. Arka plan işçileri yeniden başlatıldı.

Her sonraki dağıtım aynı adımları takip eder. Süreç, bu ikinci dağıtımınız mı yoksa iki yüzüncü dağıtımınız mı olduğuna bakılmaksızın aynıdır.

Bir Şeyler Yanlış Gittiğinde Ne Olur?

Dağıtımlar başarısız olabilir. Bir migration hatası meydana gelebilir. Bir Composer bağımlılığı düzgün kurulmayabilir. Derleme aşamasında bir hata olabilir. Bu durumlarda, Deploynix symlink değişimini gerçekleştirmeden önce dağıtımı durdurur.

Burada, versiyonlama yaklaşımının güzelliği ortaya çıkar. Eğer bir hata adım 1 ile 6 arasında meydana gelirse, symlink değişmez. Önceki dağıtım hâlâ çalışır, kullanıcılarınıza hizmet vermeye devam eder, tamamen etkilenmemiştir. Başarısız olan dağıtım klasörü orada durur ve neyin yanlış gittiğini inceleme fırsatı bulursunuz; çünkü uygulamanız hâlâ yayındadır.

Symlink değişimi sonrası bir sorun keşfedilirse (örneğin, test sırasında yakalanmamış bir sayfa hatası), Deploynix’in geri alma özelliğini kullanabilirsiniz. Geri alma, symlink’i önceki dağıtım klasörüne döndürecektir. Bu işlem birkaç saniye sürer ve uygulamanız son bilinen çalışır sürüme geri döner.

Güncellemeleri Dağıtma

İlk dağıtımınızdan sonra, her sonraki dağıtım aynı süreçtir. Dizüstü bilgisayarınızdaki kodda değişiklikler yapar, bunları Git’e kaydeder, GitHub’a gönderir ve Deploynix aracılığıyla deploy edersiniz. Kontrol panelinde “Deploy” butonuna tıklayarak manuel olarak dağıtım yapabilir veya belirli bir dalga gönderildiğinde otomatik dağıtımlar ayarlayabilirsiniz.

Çoğu ekip ana dal için otomatik dağıtımlar ayarlamaktadır. İş akışı şöyle olur: kodu yaz, bir pull request aç, inceleme yap, birleştir ve dağıtım otomatik olarak gerçekleşir. Ayrıca, düşük trafik saatlerinde yayımlanması gereken değişiklikler için Deploynix’in zamanlı dağıtım özelliğini kullanarak belirli zamanlarda dağıtım yapabilirsiniz.

Büyük Resim

Dağıtım, uygulamanızı geliştirmenin ve onu dünyayla paylaşmanın köprüsüdür. Dağıtım sırasında neler olduğunu anlamak, sizi daha kendine güvenen bir geliştirici yapar. SymLink değişimi, kesintisiz dağıtım sağlar; bu nedenle bunu ekibinize açıklayabilirsiniz. Migrations’ın sırayla çalıştığını bildiğinizde, onlara güvenle yazabilirsiniz. .env dosyasının kodunuzdan ayrı olduğunu bildiğinizde, kodunuzu herkese açık bir reposuna göndermenin güvenli olduğunu anlarsınız.

Deploynix, bu adımların tümünü otomatikleştirerek, sunucuları yönetmek yerine uygulamanızı geliştirmeye odaklanmanıza olanak tanır. Ancak, otomasyon en iyi nasıl çalıştığını anladığınızda işler. Şimdi bunu biliyorsunuz. Hadi bir şey dağıtın.