WordPress Siteleriniz için Modern Dağıtımlar

Benim gibiyseniz, dosyaları bir web sunucusuna aktarma konusundaki ilk deneyiminiz ya cPanel gibi web tabanlı bir dosya yöneticisi ya da Transmit veya Filezilla gibi bir Dosya Aktarım Protokolü (FTP) istemcisi aracılığıyla oldu. Sunucuya bağlanın, dosya(lar)ınızı üzerine sürükleyin ve aktarımın tamamlanmasını bekleyin.

Kolay değil mi?

Ancak, statik HTML dosyalarından daha karmaşık herhangi bir şeyle çalışmaya başlar başlamaz, kodumu dağıtmak çok daha karmaşık hale geldi: Başkaları tarafından gerekli olan bir dosyayı veya genel bir eklemede bir noktalı virgülü kaçırırsam ve bu dosyayı beyaz ekranlarsa ne olur? tüm site? Ya işlem sırasında çok önemli bir adım atlanırsa?

Bu "kovboy kodlama" sorunları, işin içine daha fazla insan, ortam ve bağımlılık girdikçe daha da kötüleşir. Sonuç olarak, tüm bu hareketli parçalar arasında hokkabazlık yaparken ilerleme kaydetmeye devam etmek giderek zorlaşıyor. Hepsinden kötüsü, kodu serbest bırakmak büyük bir mesele ve sürekli bir endişe kaynağı haline gelir.

Uygulamalarımız, sitelerimiz ve mağazalarımız daha modern hale geldikçe dağıtımlarımızı da modernize etmemiz gerekiyor. Sürüm kontrolünden sürekli teslimata kadar, modern bir yayın süreci, dağıtımlarla ilgili endişeleri giderebilir.

Sürüm Kontrolü ile Değişiklikleri İzleme

Geçici güncellemelerden ve kovboy kodlamasından uzaklaşmanın ilk adımı, Git gibi bir araç kullanarak sitenizi sürüm kontrolü altına almaktır.

Sürüm kontrolünü kullanmak, neyin değiştiğini, değişiklikleri kimin yaptığını görebileceğiniz ve hatta dalları kullanarak aynı anda birden çok değişiklik kümesi üzerinde çalışabileceğiniz anlamına gelir. Sonuç olarak, işin üzerine yazılmaz ve dosyalar arasındaki herhangi bir çakışma açıkça vurgulanır.

Git ile daha önce çalışmadıysanız korkmayın: Hem Git'e bir giriş hem de daha gelişmiş Git iş akışları hakkında bir yazı yazdık.

Neyin İzleneceğine Karar Vermek

Sitemizi sürüm kontrolü altında taşırken, takip etmediklerimiz de neredeyse yaptıklarımız kadar önemlidir:

Genel olarak konuşursak, sürüm kontrolü, araçlar veya süreçler tarafından oluşturulan varlıkları değil, kaynak kodunu izlemek içindir . Bu, birleştirilmiş/küçültülmüş CSS ve JavaScript, dış bağımlılıklar vb. gibi şeyleri içerir. Toplu olarak, bu öğelere yapıtlar diyoruz.

Örneğin, Sass gibi bir CSS ön işlemcisi kullanıyorsanız, oluşturulan CSS dosyaları sürüm kontrolü altında izlenmemelidir . Yalnızca kolayca yeniden üretilebilir olmakla kalmaz, aynı zamanda okunması zordur ve birden fazla geliştirici söz konusu olduğunda ortak bir birleştirme çatışması kaynağıdır.

Bağımlılıklar (kütüphaneler, WordPress eklentileri vb.) söz konusu olduğunda, havuzunuzda sorumlu olmadığınız kodları paketlemek yerine Composer ve WPackagist gibi araçlardan yararlanın.

Ek olarak, Git deposu asla parolalar, özel SSH anahtarları veya sır olarak kabul edilebilecek diğer gizli bilgileri içermemelidir, çünkü havuzun bir kopyasına sahip her geliştirici bu hassas bilgileri bilgisayarlarında bulundurur.

Deponuzu Yapılandırma

Bir WordPress veya WooCommerce sitesi için bir Git deposu kurarken, genellikle bu dizinin üzerindeki dosyalara dokunmayacağınız için wp-content/ dosyasını deponun kökü olarak ele almak en iyisidir.

Sitenizin kullandığı ancak kodunu korumadığınız eklentiler ve temalar, harici bağımlılıklar oldukları için Composer aracılığıyla yüklenmelidir. Benzer şekilde, işlenmiş CSS ve JavaScript dosyaları .gitignore dosyası aracılığıyla hariç tutulmalıdır, çünkü bu eserler bizim için yayın sürecimizin bir parçası olarak oluşturulacaktır.

Başlamanız için GitHub'da ücretsiz bir depo şablonumuz var.

CI/CD'ye giriş

Yazılım dağıtma söz konusu olduğunda, anlaşılması gereken iki önemli terim vardır: Sürekli Entegrasyon (CI) ve Sürekli Teslimat (CD).

Bu iki terim yakından ilişkilidir, o kadar ki topluca “CI/CD” olarak anılırlar ve değişikliklerimizin aktığı yol böylece “CI/CD ardışık düzeni” olur. Bu boru hattı genellikle aşağıdaki formu alır:

1. Sürümü oluşturun: bağımlılıkları kurun (Besteci, npm, vb.), ardından eserler oluşturun (Webpack, Grunt, Sass, vb.)
2. Yapıyı test edin: birim testleri çalıştırın, kodlama standartlarını kontrol edin, statik kod analizi yapın, vb.
3. Sürümü bir veya daha fazla ortama dağıtın

Sürekli Entegrasyon , yeni değişikliklerimizin mevcut kod tabanıyla temiz bir şekilde bütünleşmesi için değişikliklerin mevcut işlevselliği bozmamasını sağlamak için kodumuzu sürekli olarak test etme sürecidir. Her yeni değişiklik yapıldığında, "yapıyı bozmadığımızdan" emin olmak için kontroller yapılır.

Sürekli entegrasyonun faydalı olması için bu kontrollerin otomatikleştirilmesi gerekir . Örneğin, bir birim testi paketiniz varsa, her yeni çekme isteği açıldığında bu test paketini çalıştırmayı seçebilir ve kod üretime geçmeden önce olası kırılmalara karşı sizi uyarabilirsiniz.

Bununla birlikte, aşağıdakiler dahil olmak üzere kodunuza karşı otomatik olarak çalıştırılabilen bir dizi "kodsuz" kontrol olduğundan, sürekli entegrasyon birim testleriyle sınırlı değildir:

• Kodlama standartları kontrolleri (PHP_CodeSniffer, PHP Kodlama Standartları Düzeltici)
• Statik kod analizi (PHPStan, Psalm)

Bu kontrollerin her basıldığında otomatik olarak çalıştırılması, tüm kodun aynı kontrollerden geçirilmesini sağlayarak, geçmeyen kodun serbest bırakılmasını önler.

Sürekli Teslimat ise, kodumuzu herhangi bir anda “teslim edebilmemiz” (dağıtabilmemiz) fikridir. Bunu başarmak için, bir düğmeye tıklama ile kodumuzu sorunsuz bir şekilde üretime taşıyacak bir komut dosyası dağıtım sürecimiz olmalıdır.

Dağıtımlarınızın komut dosyasının yazılması, hem düzenli hem de tutarlı bir şekilde dağıtabileceğiniz anlamına gelir; her dağıtım, bir öncekiyle aynı şekilde çalışmalıdır. Sonuç olarak, ekibiniz daha yüksek düzeyde bir güvenle ve birinin bu süreçte bir adımı atladığına dair daha az endişeyle daha düzenli bir şekilde konuşlandırabilir. Bazı ekipler için günde düzinelerce (hatta yüzlerce) kez konuşlandırmak alışılmadık bir durum değil!

Sitenize bağlı olarak, “diğer CD”ye, Sürekli Dağıtıma da bakmak isteyebilirsiniz; sürekli teslime çok benzer, ancak bu modelde bir şubeye yapılan her gönderme otomatik olarak dağıtılır. Bu, dallanmış bir sürüm kontrol şeması (Github Flow gibi) kullanırken son derece güçlü olabilir, ancak sürüm pencerelerini programlamanız veya tüm işleri ana dalda yapmanız gerekiyorsa istenmeyen bir durum olabilir.

CI/CD ile WordPress veya WooCommerce Sitesini Dağıtma

Artık temel terminolojiyi anladığımıza göre, tipik bir WordPress veya WooCommerce sitesini dağıtmaya bir göz atalım:

Bu alıştırma için, WP Pusher'ın arkasındaki aynı kişilerden WordPress geliştiricilerinin ihtiyaçları doğrultusunda tasarlanmış bir CI/CD aracı olan Branch'ı kullanacağız. Hepsinden iyisi, Branch, Nexcess'e dağıtım için yerleşik desteğe sahiptir!

Başlamak için GitHub, GitLab veya Bitbucket hesabınızı bağlayarak ve ardından ilk sitenizi oluşturarak Branch'e kaydolun.

Ardından, sitemizi oluşturmak için gerekli tüm adımları yapılandırmak isteyeceğiz. Branch, yaygın eylemler (Composer bağımlılıklarını yükleme, Webpack'i çalıştırma vb.) için bir dizi "tarifler" sunar, ancak aynı zamanda bize herhangi bir sayıda özel adım ekleme olanağı da sağlar.

Sitemizi oluşturmak için gerekli adımları belirledikten sonra, boru hattımızın bir sonraki aşamasına geçebiliriz: test etme.

Siteniz için zaten otomatik bir test paketiniz varsa, Branch'e gerekli komutları çalıştırmasını söyleyebilirsiniz. Halihazırda testleriniz olmasa bile Branch, linting, kodlama standartları ve uyumluluk kontrolleri eklemeyi çok kolay hale getirir.

Artık bağımlılıklarımızı kurduk, her şeyi oluşturduk ve testlerimizi geçtik, şimdi kodumuzu üretime alma zamanı!

Branch, Nexcess'e (diğer büyük barındırma sağlayıcılarının yanı sıra) dağıtmak için tarifler içerir ve iki platformu birbirine bağlamak zahmetsizdir:

1. Şube kontrol panelinde sitenizi seçin, “Ayarlar”a tıklayın, ardından Şube sitenizin genel SSH anahtarını alın
2. Bu ortak anahtarı Nexcess portalındaki anahtarlar listesine ekleyin

Branch, Nexcess sitenizle iletişim kurabildiğinde, "Nexcess" dağıtım tarifini seçip birkaç ayrıntıyı doldurabiliriz:

1. Sitenin ana bilgisayar adı ve kullanıcı adı (sitenizin “Erişim” ekranındaki Nexcess portalı aracılığıyla erişilebilir)
2. Dağıtım yaptığımız web kökü. Git depomuz wp-content/ dizini olarak hizmet edecekse, bu değer "public_html/wp-content" olmalıdır.
3. Dağıtmak istediğimiz dosyalar (genellikle varsayılan "*" yeterlidir)
4. Bu ortama dağıtılacak git dalı

"Git şubesi" ayarı, farklı şubeler için farklı dağıtımlar belirlemenize olanak tanıdığından özellikle önemlidir. Örneğin, hazırlama ortamınıza dağıtılan ve değişiklikleri canlı hale getirmeden önce test etmenize izin veren bir "hazırlama" şubeniz olabilir.

Branch'in varsayılan olarak sürekli dağıtım modelini kullandığını belirtmekte fayda var; burada işlem hattı, verilen şubeye yapılan her göndermede çalışır. Daha çok bir sürekli teslimat modelini tercih ederseniz (bazı manuel işlemlerin yapılması gerekir), yalnızca piyasaya sürmeye hazır olduğunuzda birleştirilen bir "üretim" dalını korumayı düşünebilirsiniz.

Bu noktada Branch, git deponuzu oluşturmak ve Nexcess'e dağıtmak için yapılandırılmalıdır! İlk dağıtımınızı, sitenizin "Boru Hatları" sayfasındaki "Dağıtımı Çalıştır" düğmesini tıklayarak veya Git deponuza iterek tetikleyebilirsiniz.

Yayın Sürecinizi Özelleştirme

Branch'in gerçekten güzel özelliklerinden biri, başarılı bir dağıtımdan sonra, bir dağıtımdan sonra sitenizin nesne önbelleğini otomatik olarak temizleme gibi ek adımları yapılandırma yeteneğidir. Bu, "Diğer" altındaki WP-CLI tarifi kullanılarak gerçekleştirilebilir.

Ana bilgisayar ve kullanıcı adı, genellikle dağıtım adımında kullandığımızla aynı olacaktır ve gerektiği kadar çok komutu zincirleyebilirsiniz.

Çözüm

Hâlâ kovboy kodlayan tuhaflıklar ve/veya endişe uyandıran yayınlarla mücadele ediyorsanız Branch'e bir göz atın ve konuşlandırmaları çok kolay hale getirin!