Bitbucket ile WordPress Sürekli Dağıtım ve Sürüm Kontrolü

Tamam millet. Nefret etme zamanı.

Benim gibiyseniz, WordPress geliştirme yıllarınızın ilk ayağını “kovboy kodlaması” ile geçirdiniz; yani, canlı sitelerde çılgınca değişiklikler yaparak, bunları FTP ile acilen test edip ateşleyerek, genellikle 500 Dahili Sunucu Hatası mesajı ve Site genelindeki tüm aralar, değerli ziyaretçileriniz tarafından görülebilir.

Bu, adrenalin parmaklarınızın arasından pompalanırken, o unutulmuş noktalı virgülle çarparken kesinlikle heyecan verici olsa da, 0'dan fazla ziyaretçisi olan (hatta kesinti süresini gerçekten fark eden) sitelerde bu bir sorun olmaya başlayacaktı. Bir ağaç devrilirse ve onu duyacak kimse yoksa, ses çıkarır mı? Abone olduğunuz insanlık teorisine bağlıdır.

Ancak, bir site çökerse ve onu görecek biri varsa, kesinlikle bir ses çıkarırlar.

WordPress Sürekli Dağıtımı Yanlış Yapıldı

Hazırlık sitelerine girin, değişikliklerin yapılabileceği (en azından teoride) WordPress kurulumlarını çoğaltın, ardından her şeyin çalıştığı onaylandıktan sonra canlı sitede tekrar yapın. Bu, ziyaretçileri sakinleştirirken, biz geliştiricilerin biraz gürültü yapmasına neden olmaya başladı. Birden iki siteyi takip etmemiz, kodun aralarında manuel olarak senkronize edildiğinden emin olmamız ve canlı sitede çalıştığından emin olmak için her şeyi tekrar test etmemiz gerekiyordu. "Bunu canlı yayında değiştirdiğinizden emin olun" ve "kodu kopyalamadan önce bunu hazırlama sitesinde değiştirdiğinizden emin olun" uzun, dağınık listeleri, en azından söylemek gerekirse, sinir bozucuydu. Bu sistemin yedekleri de bir kabustu - "my-theme-staging-1" ve "my-theme-live-before-menu-restyle-3" vb. adlı bir dizi klasör.

Daha iyi bir yol olmalıydı ve vardı.

Geliştiricilere mükemmel kaynak kontrolü ve diğer özellikler sağlayan Git vardı. WordPress kurulumları için sürüm kontrolünün kullanılması, geliştirmeyi anında hızlandırdı ve temizledi, çünkü saatler artık geliştirici başına bir sistemde yedeklemeye değil, aslında kodlamaya harcandı. Değişiklikler kaydedildi ve sonunda işime anlamlı mesajlar ekleyebildim, “my-theme-4-v2”den dünyalar kadar fark vardı.

Kod tabanı çok daha temiz olsa da, sorun hala gerçek dağıtımlarla ve söz konusu sitenin en son kodu kullanmasını sağlamakla ilgiliydi - insan hatası için fırsat girin. Hala manuel FTP yüklemelerine güvenmek, önceki kodun üzerine yazmak pek iyi hissettirmedi. Diğer CI/CD hizmetleri varken, birçoğu önemli bir fiyat etiketi ve büyük miktarda kurulum ile geldi - sunucu yeniden yapılandırma, en basit web sitesi için bile başka bir hizmete güvenme, diğer hizmetin tüm “işleri yapma biçimini” öğrenme ve tüm onunla birlikte gelen tuhaflıklar.

Bu öğreticiye benzer kurulumlar GitHub/GitLab ve diğer hizmetlerle yapılabilirken, yumurtalarımı ücretsiz özel depoları nedeniyle (sadece GitHub'dan yeni bir teklif olan) Atlassian sepetine erken koymuştum. Bitbucket, Pipelines ve Deployments hizmetlerini tanıttığında, yeni kodun FTP aracılığıyla yeniden yüklemeden veya harici bir hizmet kullanmadan hazırlama veya üretim sitelerine (veya aradaki herhangi bir siteye) otomatik olarak dağıtılmasına izin verdi. Geliştiriciler artık WordPress geliştirmelerinde kaynak denetiminin tüm değerlerini kullanabilir ve bu değişiklikleri ek bir tıklama veya tuş vuruşu olmadan anında uygun hedeflere gönderebilir ve her şeyin durumu tek bir gösterge panosu aracılığıyla görülebilir. Bu, her şeyin senkronize kalmasını sağlar ve bir bakışta her sitenin tam olarak hangi kodu çalıştırdığını bilmenizi sağlar. Ayrıca, Bitbucket'in derleme dakikalarının fiyatlandırması inanılmaz derecede uygun - ayda 50 dakika ücretsiz ve "Ücretsiz ve Fazla Kullanım" planı seçeneği.

Bu yeni modelde dalların ve kaynak denetiminin diğer özelliklerinin en iyi şekilde nasıl kullanılacağını ve Bitbucket Pipelines kurulumunun ayrıntılarını bulmak, başlangıçta biraz zaman aldı. İşte yeni WordPress projelerine başlamak için kullandığım süreç. Bunun için harika kaynaklar yalnızca bir Google araması uzağınızda olduğundan, git ve WordPress kurulumunun kurulumuyla ilgili tüm ayrıntılara girmeyeceğim. Sonunda, içerik akışı şöyle bir şey olacaktır:

Alexa Green WordPress Para Yatırma Rutini

Burada özetlenen adımlar gerektiği gibi gerçekleştirilmelidir:

İstemci Sunucusunda

Canlı site (ör. clientsite.com) için bir etki alanı ve hazırlama için alt etki alanı (ör., staging.clientsite.com) ayarlayın.

WordPress'i hem canlı siteye hem de hazırlama alt alanına yükleyin. Bu, cPanel/Softaculous üzerinden (eğer müşterinin hostinginde bu varsa) veya wordpress.org'dan indirilerek yapılabilir. Sırasıyla canlı ve sahneleme için ayrı veritabanları olduğundan emin olun.

Bitbucket.com'da

Yeni bir depo oluşturun. Bizi ayağa kaldırmak için bir .README ekleyin.

Depoda, Settings > Pipelines > Settings ardından Enable Pipelines öğesini işaretleyin.

Ayarlar > İşlem Hatları > Depo değişkenleri içinde aşağıdakileri girin:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Pipelines > Settings'e geri dönün ve Configure bitbucket-pipelines.yml düğmesini tıklayın. Sonraki sayfada dil olarak PHP'yi seçin. Aşağıdaki kod gibi bir şey kullanmak isteyeceksiniz. PHP sürümünü, istemcinin sunucusunda ne kullanıyorsanız kullanın ve URL'leri/FTP sunucularını gerçek istemci sitesi (üretim ve hazırlama) URL'leri/FTP sunucularıyla değiştirdiğinizden emin olun.

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Dosyayı taahhüt et'i tıklayın. Pipelines kurulumu şimdi taahhüt edilecek ve çalıştırılacaktır.

Her şey başarıyla dağıtılırsa, geri dönün ve bitbucket-pipelines.yml dosyasını düzenleyin (oraya Pipelines > Settings ve View bitbucket-pipelines.yml aracılığıyla ulaşabilirsiniz). git ftp init yazan her iki yeri de git ftp push ve save/commit ile değiştirmek isteyeceksiniz. Bu, yalnızca değiştirilen dosyaların yüklenmesini sağlayarak derleme dakikalarından tasarruf etmenizi sağlar. bitbucket-pipelines.yml dosyanız şimdi şunu okumalı:

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

main-dev adlı bir dal ekleyin.

Yerel Makinenizde

Depoyu, yerel kurulum için kullanmak istediğiniz boş bir dizine klonlayın. main-dev şubesine bakın.

Bu dizinde yerel bir WP kurulumu kurun. Bunun için pek çok araç vardır: Volan, MAMP, Docker, vb. Tarafından Yerel. Her şeyin istemcinin sunucusunda çalışmakta olanla aynı olduğundan (WordPress sürümü, PHP sürümü, Apache/Nginx, vb.) emin olun.

Şuna benzeyen bir .gitignore ekleyin. Esasen Git'in wp içeriği dışındaki her şeyi yok saymasını istiyoruz (kurulumlar arasında kurulum sorunlarını önlemek için). Büyük yedekleme dosyalarını ve sistem tarafından oluşturulan simgeyi ve DS_Store dosyalarını yok saymak için kendi kurallarınızı da eklemek isteyebilirsiniz.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

.gitignore kaydedin ve kaydedin.

Değişiklikler yapın ve buna göre taahhütte bulunun.

Main-dev'i her taahhüt ettiğinizde, hazırlama sitesine bir FTP yüklemesi başlatır. Master yapmayı her taahhüt ettiğinizde, üretim sitesine bir FTP yüklemesi başlatır. Bunun derleme dakikalarını kullanacağını unutmayın, bu nedenle çoğu yerel değişikliği ana-dev'in bir dalında yapmak isteyebilirsiniz, ardından günlük işiniz bittiğinde ana-dev ile birleştirin.

Main-dev'i master ile birleştirmek, tüm evreleme değişikliklerini canlı hale getirecektir. Bitbucket.org'daki depoda Pipelines ve Deployments'ın durumunu kontrol edebilirsiniz.

Kurulumlar Arasında WordPress Veritabanlarını Senkronize Etme

Yukarıdakilerin yalnızca dosyaları (temalar, eklentiler, vb.) senkronize edeceğini unutmayın. Müşteriler genellikle canlı sitede hazırlık sitesine yansıtılmayan değişiklikler yaptığından ve bunun tersi de geçerli olduğundan, veritabanını üretim ve hazırlama arasında senkronize etmek farklı bir konu haline gelir.

Veritabanlarını WordPress kurulumları arasında senkronize etmek için çeşitli seçenekler mevcuttur. Geleneksel olarak, veritabanlarını phpmyadmin aracılığıyla içe/dışa aktararak güncelleyebilirsiniz. Ancak bu, gönderi içeriğindeki kalıcı bağlantılar gibi güncellenmesi gereken bazı şeyleri güncelleyemediği için zor. Bu yöntemi kullanarak, favori bir araç Velvet Blues Güncelleme URL'leri eklentisidir ve daha sonra eski site URL'sinin (örneğin, https://staging.clientsite.com) herhangi bir örneğini yeni site URL'sinde aramak/değiştirmek için kullanabilirsiniz ( örneğin, https://clientsite.com). Bunu, göreli yollar ve dizelerle de kullanabilirsiniz. Bu yöntem, insan hatası için çok fazla alan bırakır; değiştirilen bir dize yanlış yazılırsa, tüm sitenin bozulmasına ve eklentiyi kullanamamasına/panoya erişememesine neden olabilir.

All-in-One WP Migration gibi bir eklenti, kullanıma hazır bir arama/değiştirme özelliği sunarken ve inanılmaz derecede kullanıcı dostu olsa da, dosyaları da getirir ve böylece tüm Pipelines iş akışımızın değerlerini geri alır. Ayrıca, tüm wp yüklemelerini yeniden içe aktardığından, çok büyük dosyalara ve yükleme sürelerine neden olabilir (bu nedenle, değişiklikleri kurulumlar arasında taşımak için uygun değildir). Bunun gibi bir eklenti, arşivleme/güvenlik amacıyla tüm sitenin yedekleri için en iyi şekilde ayrılmıştır.

VersionPress ilginç bir çözüm gibi görünüyor, ancak henüz birçok üretim ortamında kanıtlanmış değil. Şimdilik, WP Sync DB veya WP Migrate DB Pro gibi eklentiler, veritabanı yönetimi için en iyi çözümler gibi görünüyor. URL'leri ve yolları otomatik olarak güncelleme seçeneği sunarken, kurulumlar arasında veritabanlarını çekmeye/itmeye izin verirler. Yalnızca gönderi içeriği için wp_posts gibi belirli tabloları taşıyabilirler, kullanıcıları ve site genelindeki ayarları yeniden içe aktarmak için zaman kaybetmezler. Hiçbir üretim verisinin üzerine yazılmadığından emin olmak için her zaman canlı yayından çekmeyi seviyorum. İşte WP Sync DB kullanıyorsanız örnek bir kurulum (WP Sync DB github'da daha fazla izlenecek yol):

1. Canlı sitede: WP Sync DB'yi "Bu depodan çekmeye izin ver" ayarı etkin olarak ayarlayın.
2. Hazırlama sitesinde: Canlıdan Çekme ayarlarıyla WP Sync DB'yi kurun. “Canlı sahneleme” olarak adlandırın.
3. Yerel geliştirici kurulumunuzda: Canlıdan Çekme ayarlarıyla WP Sync DB'yi kurun. Buna "canlıdan geliştiriciye" adını verin.

Ayrıca, "geliştirmeden hazırlamaya" zorlayan bir kural ayarlamak ve veritabanının üzerine yazılmasına izin vermek için hazırlama sitesi ayarını kontrol etmek isteyebilirsiniz.

Toplama

Bu yöntemlerin, hem yeni bir WordPress web sitesi geliştirmede hem de zaten yayında olan bir siteyi yeniden tasarlama/yeniden yapılandırma gibi çoğu kullanım durumunda işe yaradığını gördüm.

Ek geliştirme zamanı/çabası olmadan ve siteler arasında çalışmak için kasıtlı, güvenli veritabanı geçiş mantığı olmadan tüm site sürümlerini güncel tutan kod dağıtımlarına izin verir. Eklentilerin güncellenmesi kaynak kontrolü içinde de yapılır, böylece eklenti güncellemeleri, canlı siteye bağlanmadan önce hazırlama sırasında güvenli bir şekilde kontrol edilebilir, böylece üretim sitesi kesintilerini en aza indirir.

Veritabanı yönetimine daha fazla kaynak kontrol iş akışı getirmek için kesinlikle iyileştirmeye yer olsa da, VersionPress gibi bir araç üretim ortamlarında daha fazla kullanılana kadar, WP Sync DB veya WP Migrate DB Pro aracılığıyla veritabanının bu seçici çekme/itme yöntemi gibi görünüyor. bununla başa çıkmanın en güvenli yöntemi olmak. WordPress iş akışınız için neyin işe yaradığını merak ediyor veya tüm bunlardan sonra kementinizi ve kovboy kodunuzu almayı tercih ediyorsanız!