Bu soruyu bir yıl önce sordum ve bu süre zarfında ekibimize daha fazla kişi ekledik ve WordPress'te çok daha fazla sayıda site geliştirdik. Başkasına yardımcı olabileceği için sürecimizde dolaşmak istedim.
Git'teki her şey
Bu soruyu sorduğum halde yaptığım bir şeydi, ama bu noktayı söylemek güzel. Git'i kullanmak sadece daha üretken olmamıza yardımcı olmadı, aynı zamanda toplu kıçlarımızı da birkaç kez kurtardı.
Bir siteye büyük yapısal yenilemeler yapmanız, bir müşteriden bu yenilemeler için onay almanız ve bu süre zarfında yenilenmemiş sürümde küçük güncellemeler yapmanız gerekti mi? Yaptık ve Git yapmamıza izin verdi. Bu düzeneğin tanımlanması biraz uzun sürecektir, ancak temel hususlar yeni bir dal oluşturmamız, o dalı sunucuya çekmemiz ve bu dala bir alt etki alanı eklememizdir.
Ayrıca Git tarafından da kurtarıldık. Elbette ki değişiklikleri geri almamıza izin veriyor, ki bu harika, ama aynı zamanda dosyaların eski sürümlerini geri getirmemizi de sağlıyor. Bunun anlamı, bir müşteri "Sitenin bu bölümünün bir yıl önce nasıl çalıştığını hatırlayın? Bunu geri getirebilir miyiz?" Diye sorarsa, cevap evet - sorulan kişi bir yıl bu projede olmasa bile önce.
Bu noktaların yanı sıra, ihtiyacımız olan dosyalar olmadan asla sıkışıp kalmayacağımız anlamına da geliyor. Her zaman sitenin en yeni sürümünü herhangi bir makineden indirebilir ve değişiklik yapmaya başlayabiliriz.
Dağıtmak için Git'i kullanın
WordPress'imizi Media Temple'da barındırıyoruz ve gerçekten beğeniyoruz. En ucuz sağlayıcı değiller, ancak hizmetleri mükemmel ve sunucuları gerçekten iyi ayarlanmış. Ayrıca, varsayılan olarak Git özelliğini de sağlar. Bu, sunucuyu Git deposu olarak ayarlayabileceğimiz ve SFTP kullanmak yerine değişiklikleri bu şekilde çekebileceğimiz anlamına gelir. Ayrıca, sunucu üzerinde çalışma yapmanın üzerine yazılma tehlikesi olmadığı anlamına gelir (çünkü bu değişiklikler birleştirilebilir ve geriye itilebilir).
BitBucket'i Git sunucumuz olarak kullandığımız için, burada biraz daha fazla iş yapmanız gerekiyor. Öncelikle .ssh / config dosyalarını kullanıyoruz, böylece ssh sitenamesunucularımıza giriş yapmak gibi şeyler yazabiliriz (ayrıca bunu süper kolaylaştıran şifresiz SSH kullanıyoruz ). Ayrıca, her zaman ssh parolalarını kullandığınızdan emin oluruz (Mac OS X, parolanızı Keychain.app içerisinde saklamanıza izin vererek bunu çok kolaylaştırır ). Son olarak, ForwardAgent satırını, çekmek istediğimiz ana bilgisayarlardaki .ssh / config girişine ekleriz. Bu, her bir sunucunun ortak anahtarına değil, yalnızca BitBucket'teki SSH ortak anahtarına ihtiyacımız olduğu anlamına gelir. Ayrıca, .gitdizini herkese açık HTML dizininin üstünde tuttuğunuzdan da emin olun .
Otomatik veritabanı dökümleri
Sunucu üretim moduna geçtiğinde, veritabanımızı otomatik olarak yedeklediğinizden emin olabiliriz .
Herkesin kendi wp-config'si vardır
Hepimizin kendi yerel veritabanı kullanıcı adlarımız ve şifrelerimiz olduğu ve farklı isimler ve servis mekanizmaları kullanabileceğimiz için, her biri kendi wp-config dosyamızı tutuyor. Bunların her biri gibi bir isim ile Git saklanır wp-config-gavin.phpve biz o yapılandırma kullanmak istediğinizde, biz sembolik bir link bunu wp-config.php(kullanarak Git tarafından ihmal edildiği .gitignore ).
Bu aynı zamanda aşağıdaki gibi veritabanı tablosundaki siteurlseçeneği geçersiz kılmamızı sağlar wp_options:
define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');
Bu, WordPress'in sunucu konumu için veritabanına bakmasını önler ve yerel ve sunucu kurulumları arasında konum olarak garip farklılıklar olmadığı anlamına gelir.
Wp-config.php dosyalarıyla ilgili son bir not: bunları genel HTML dizininin üzerinde sakladığınızdan ve izinlerin yalnızca web kullanıcısı için okunmasını sağlayın . Bu, WordPress'in güvenliğini sağlamada büyük bir fark yaratıyor.
Veritabanı sorunu
Sonunda, maddenin et.
Kabul etmem gereken, WordPress kullanırken, veritabanı değişikliklerini "birleştirmek" için iyi bir yol yok. Bunun yerine, bunu çözmek için davranış kuralları geliştirmemiz gerekiyordu. Kurallar oldukça basit ve bize şu ana kadar iyi hizmet etti.
Geliştirme sırasında, sitenin "sahibi" olan tek bir kişi var. Bu kişi genellikle kurulumu yapar (barındırma paketini bir araya getirmek, Basecamp projesini başlatmak, tasarımı dilimlemek, bu tür şeyler). Bu kişi makul bir noktaya geldiğinde, WordPress kurulumu için veritabanını çöpe atıp Git'e koyun. Bu noktadan itibaren, geliştirme yapan herkes bu veritabanı dökümünü kullanır ve veritabanında değişiklik yapan yalnızca sahibi sahibidir.
Site oluşturma işlemi biraz daha ilerlediğinde, site bir sunucuya yerleştirilir. Bu noktadan itibaren, sunucunun veritabanı kurallıdır. Herkes (sahibi dahil) sunucudaki tüm veritabanı değişikliklerini yapmalı ve yerel geliştirme ve test için değişiklikleri aşağı çekmelidir.
Bu işlem mükemmel değil. Yine de birilerinin geliştirme sırasında yerel olarak WordPress'te değişiklik yapması gerekebilir ve daha sonra bu değişiklikleri üretimde yapması gerekebilir. Bununla birlikte, bu tür şeylerin nadir olduğunu bulduk ve bu süreç bizim için oldukça iyi çalışıyor.