SFTP ve manuel deploy'ların sorunu
Dosyaları SFTP üzerinden sürükleyerek deploy etmek, sitelerin yarı bozuk kalmasının tipik yoludur: bir dosya atlanır, composer çalıştırılmaz, bir migration unutulur ve cache hâlâ eski bundle'ı sunar. Neyin yayınlandığına dair bir kayıt ve bunu tekrar üretmenin temiz bir yolu yoktur. GitHub Deploy bunun yerine deponuza bağlı, tanımlı bir pipeline getirir; böylece bir release, bir commit artı sabit bir adımlar setinin belirleyici sonucu olur — her seferinde, ekipteki herkes için aynı.
Build adımlarınız, tutarlı bir şekilde çalışır
Gerçek bir deploy, dosyaları kopyalamaktan fazlasıdır: bağımlılıklar kurulmalı, assetler derlenmeli ve veritabanı migration'ları doğru sırada uygulanmalıdır. Bu adımları bir kez tanımlarsınız — örneğin composer install, bir npm ya da asset build'i ve bir migration komutu — ve bunlar her deploy'da yayınlanan tam commit'e karşı çalışır. Bu, üretim ortamının, birinin adımları farklı bir sırada çalıştırması ya da baskı altında birini atlaması yüzünden farklı davrandığı tüm bir hata sınıfını ortadan kaldırır.
Manuel deploy'lar ve webhook otomatik deploy
Farklı ekipler farklı tetikleyiciler ister. Temkinli bir ekip deploy'ları manuel tutar, review sonrası panelde deploy'a tıklayarak bir release'i kasıtlı bir eylem haline getirir. Hızlı hareket eden bir ekip webhook'u etkinleştirir; böylece production branch'ine yapılan her push otomatik olarak yayınlanır ve git push'u bir deploy'a dönüştürür. İkisi de aynı pipeline'ı çalıştırır; tek fark tetikleyicidir, ve manuel başlayıp akışa güvendiğinizde webhook'u açabilirsiniz.
Private depolar ve güvenli token'lar
Gerçek kodun çoğu private depolardadır, bu yüzden platform kodun public olmasını zorunlu kılmak yerine sağladığınız bir token ile kimlik doğrular. Token bir secret olarak saklanır ve yalnızca deploy anında clone yapmak için kullanılır; kaydedildikten sonra loglarda ya da arayüzde görünmez, ve kodunuzdan ayrı olduğu için bağımsız olarak döndürebilir ya da iptal edebilirsiniz. Webhook teslimleri imzalı bir secret ile doğrulanır, bu yüzden rastgele bir POST bir release başlatamaz.
Otomatik purge son boşluğu kapatır
Deploy sonrası en yaygın hata, bayat bir edge cache'in arkasında saklanan taze bir release'tir — yeni CSS ya da JS yayınlanmıştır, ama ziyaretçiler hâlâ eski, cache'lenmiş bundle'ı yükler. GitHub Deploy, edge cache'i release'in bir parçası olarak purge eder; böylece cache yeni dosyaları yansıtana kadar deploy tamamlanmış sayılmaz. Bu, insanların unuttuğu manuel flush adımını ortadan kaldırır ve yayınladığınız şeyin ziyaretçilerin gerçekten aldığı şey olmasını sağlar.
Ekipler ve ajanslar için tekrarlanabilir teslimat
Her proje aynı şekilde deploy edildiğinde, işe alım ve devir teslim artık kabile bilgisi olmaktan çıkar. Deploy durumu, son deploy zamanı ve yapılandırılmış adımlar panelde görünür; böylece herkes son push'un production'a ulaşıp ulaşmadığını ve neyin çalıştığını görebilir. Ajanslar için bu, müşteri projeleri arasında standart bir teslimat modeli anlamına gelir; bir siteyi başka bir geliştiriciye devretmek, onun özel, belgelenmemiş bir deploy ritüelini tersine mühendislik yapmasını gerektirmez.
Adım adım nasıl deploy edilir
Depoyu ve branch'i bağlayın
Panelde uygulamanızı açın, GitHub Deploy'a gidin, depo URL'sini ve deploy edeceğiniz branch'i girin — genellikle main ya da production. Seçtiğiniz branch canlıya alınan branch olur, bu yüzden feature branch'ler asla yanlışlıkla yayınlanmaz.
Private bir depoyu yetkilendirin
Depo private ise, platformun clone edebilmesi için bir personal access ya da deploy token ekleyin. Token bir secret olarak saklanır, yalnızca deploy anında kodu çekmek için kullanılır ve uygulamanıza dokunmadan iptal edilebilir ya da döndürülebilir.
Build ve migration adımlarını tanımlayın
Bir checkout'u çalışan bir release'e dönüştüren komutları belirleyin — bir PHP uygulaması için bu genellikle composer install --no-dev, bir ön yüz asset build'i ve bir veritabanı migration'ıdır. Bu adımlar uygulamayla birlikte kaydedilir; böylece her deploy, birinin hatırlayıp yazdığı bir şey yerine aynı pipeline'ı çalıştırır.
Manuel ya da webhook otomatik deploy'u seçin
Panelde bir düğmeyle talep üzerine deploy edin, ya da bağlı branch'e yapılan bir push'un deploy'u otomatik tetiklemesi için webhook'u etkinleştirin. Webhook imzalı bir secret kullanır, bu yüzden bir release'i yalnızca deponuzdan gelen gerçek push'lar başlatabilir.
Yayınlayın, purge edin ve doğrulayın
Deploy sırasında platform branch'i çeker, adımlarınızı çalıştırır ve yeni release'i etkinleştirir; değişen assetler için edge cache otomatik olarak purge edilir, böylece ziyaretçilere bayat dosyalar sunulmaz. Panel, deploy durumunu ve son deploy zamanını gösterir; böylece release'in canlı olduğunu doğrulayabilirsiniz.
Örnek senaryolar
main'e yapılan bir push composer install, bir asset build ve migration'ları tetikler, ardından release yayınlanır ve edge cache otomatik olarak purge edilir.
Bir ajans, kapsamı sınırlı bir deploy token ile private bir GitHub deposu bağlar; kod kapalı kalırken platform yine de onu çeker ve deploy eder.
Bir ekip otomatik deploy'u kapalı tutar ve kod review'undan sonra panelde deploy'a tıklar; böylece her production release'i kasıtlı, kayıtlı bir eylem olur.
Sıkça sorulan sorular
GitHub Deploy bir Docker image'ı mı build eder, yoksa kaynak kodu mu deploy eder?
Uygulama kaynağını platform çalışma zamanına deploy eder — branch'inizi çeker ve build ile migration adımlarınızı kodun kendisi üzerinde çalıştırır. Bu, PHP ve framework uygulamaları için doğal bir uyumdur. Özellikle build edilip çalıştırılan bir container image istiyorsanız, önceden build edilmiş bir image ile Container Apps'i ya da Docker Compose Instant Deploy'u kullanın.
Bir webhook push'unda tam olarak ne oluyor?
Bağlı branch'e yapılan bir push, platforma imzalı bir webhook gönderir; platform imzayı doğrular, o commit'i clone eder ya da fetch eder, tanımladığınız build ve migration adımlarını çalıştırır, yeni release'i etkinleştirir ve edge cache'i purge eder. Panel daha sonra deploy durumunu ve son deploy zamanını günceller, böylece işlemin gerçekleştiğini doğrulayabilirsiniz.
Access token'ım nasıl korunuyor?
Token bir secret olarak saklanır ve yalnızca deploy anında depoyu clone etmek için kullanılır. Kaydedildikten sonra gösterilmez ve build loglarında görünmez; kodunuzdan ayrı yaşadığı için GitHub'da uygulamada hiçbir şeyi değiştirmeden döndürebilir ya da iptal edebilirsiniz.
Bir deploy ters giderse geri alabilir miyim?
Deploy'lar commit'lere ve tanımlı adımlara bağlı olduğundan, kurtarmak bilinen iyi bir commit'i deploy etmek meselesidir — deploy'u önceki çalışan commit'e yönlendirir ya da branch'te revert eder ve pipeline'ın onu yayınlamasına izin verirsiniz. Deploy'ları tekrar üretilebilir tutmak, geri dönmeyi bir telaş yerine güvenilir kılan tam olarak budur.
Hangi branch canlıya alınır, birden fazlasından deploy edebilir miyim?
Deploy edeceğiniz branch'i siz seçersiniz, genellikle main ya da özel bir production branch'i, ve yalnızca o branch yayınlanır — feature branch'lere yapılan push'lar deploy etmez. Bu, work-in-progress'i production'ın dışında tutarken, release branch'ine merge eder etmez deploy edebilmenizi de sağlar.
GitLab ya da başka Git host'larıyla çalışır mı, yoksa yalnızca GitHub'la mı?
İş akışı bir Git depo URL'si, bir branch ve bir token etrafında kuruludur, bu yüzden özellikle GitHub'la sınırlı değildir — bir URL ve bir access token ile ulaşabileceğiniz herhangi bir depo aynı modele uyar. GitHub yaygın durum olduğu için bu isim kullanılır, ama mekanizma standart Git'tir.